ExtraHop Website Migration Part 2: Backup Arrives

This blog series will document our process as we migrate the marketing website to a different tool. We'll dig into why things were set up the way they were, walk through the process of choosing new tools, explore the challenges of scheduling migrations, and more. Come with us on part 2 of this journey as we take you through what it's like to migrate a marketing website.

When I joined the Marketing Communications team at ExtraHop in March of 2018, I was beginning my first foray into the world of working full-time. I'd just graduated with a degree in Business and a focus in information systems, having taken a single web programming class as an elective, and aside from some other solo projects, that's where my experience in web development ended. In short, I'd never been paid to code.

I had no idea how a large, professionally constructed site was structured. My basic aptitude in HTML, CSS, JavaScript, and jQuery allowed me to get around, but I was unfamiliar with templating structures, configuration files, and generally how to build a site of this size and complexity.

I noticed some issues from the get-go but didn't recognize them as fixable problems specific to our site structure. Coming in directly to the marketing team, I did not have visibility into the initial project requirements that led to our website getting built the way it was. Because I only had the current state of the site in front of me, I couldn't always tell what seemed obtuse to me because of my lack of experience, and what was a remnant of a Web Properties team's foundations long since abandoned.

For starters, the run time for local development work, especially our content/templates watch task, could take multiple minutes. This only got worse as we added more and more pages to the site, topping out at 5-7 minutes for each and every local rebuild. As I discovered, the task runs a full site rebuild every time we change even a single file as opposed to updating only the affected files and building the rest from cache. Changes to stylesheets also took far longer than they should, in the 30-60 seconds range. We could develop, and these task times were greatly reduced on Zach's more powerful machine, but iteration took far longer than necessary.

On a similar note, as Zach mentioned last time, running a build to our hosting server took 20+ minutes and occasionally failed altogether, requiring a rerun equally as lengthy.

Back then, new builds to server would run automatically whenever we committed anything. They would cycle through a draft version of our site before building a version omitting draft content, causing the total time to run half an hour or longer. The advantage of this system was that content writers not well-versed in code could have "immediate" visibility on changes they committed to content files. They could mark a file as only a draft, and it would build to a version of the site that included those files but which would not yet go to production.

I did not have the ability to cancel a build to server or manually start one, so I'd be waiting for one to finish if multiple commits came in quick succession. Maybe once upon a time, when this system was put in place, all build times were much shorter. But by now, the advantage given to content writers was far outweighed by the wait time involved.

To me, all of this meant an extra layer of stress. I was learning the fundamentals of how to be a web developer while Zach and I were also dealing with legacy issues. No pressure.

Come June, I was three months and change into working at ExtraHop. By then, I had gained some aptitude at the core skills of web engineering. That was good, because I would need it for our upcoming task: redesigning and rearchitecting the entire "Solutions" section of the site, the navigation, and the home page. To follow up on page mockups from our marketing design team, I learned basic skills for animation, dynamic page elements, and more complex page layouts. In the midst of all this, the site hit a tipping point.

After adding one more template, the site started to straight-up refuse to build. Or, if it built, my work laptop—and only dev machine at the time—would crash sporadically as it failed to keep my local test site running. Clearly we had to optimize for maintainability moving forward, because the site's current trajectory was not sustainable.

As I finally began to feel familiar with the site's directories and where various chunks of code were kept, I realized that as the site grew exponentially larger, code was tacked on as needed for each new page or feature. Old unused files were left where they were, while out-of-date content and design sat neglected. Future proofing? What's that?

Much of the framework now behind the site had simply been grafted on piece by piece until the current latticework lay before me. The reason was simple: priorities. ExtraHop was (and is) evolving and expanding at a rapid pace, and with limited development resources the equation had been simple: creating new pages and features beat cleaning up the codebase for marginal improvements.

By early summer, I had a few big projects under my belt, including an overhaul of our resources page. We managed to eke through our "Solutions" section redesign on the current system. It wasn't ideal, but we got the job done. With a relative break from priority tasks, and having been around long enough to grasp the scope of the site and its pain points, Zach and I could coordinate plans for the site's long-term health.