ExtraHop Website Migration Part 3: The Great Stall

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 3 of this journey as we take you through what it's like to migrate a marketing website.

With our update of the "Solutions" branch of our site and its underlying architecture complete, it was time to plan for the future. The existing platform was simply not going to scale to our site as it climbed past 2,500 pages, with more blog posts being added every week.

But, as with everything in life, deciding "we need a change" and acting on it are two different things. The migration itself was complicated by a number of factors. First, migrating the marketing website would further disconnect the code from our other properties.

While the intense focus on pushing the envelope in interaction and brand had already created a significant split, all of the properties were still built on the same underlying platforms, and the same shared repo. Although the goal was to make development relatively seamless for content authors and developers alike, if all the properties were developed using different frameworks, bouncing between them all would become more challenging for newcomers to the system.

Next, there were a number of dependencies that we had on resources managed by other teams. The biggest of these was our CI/CD pipeline, or the system that builds the site using identical code to the code on our developer boxes, which requires any changes to our local boxes to be reflected up and down the chain as well.

Between testing a change on our dev boxes and that change going live on our site, the code goes through a sequence of automated tests. The pipeline builds and pushes docker images and manages the deployment to a staging environment for final review by project stakeholders, among other things. You're reading this blog right now, so hooray! All of that passed, which means we did a good job. The sound you hear is us patting ourselves on the back.

But, most importantly, any large-scale code changes absolutely had to be done in collaboration with EHIT, our intrepid IT team. Not only were they in charge of the various resources that we would be affecting, we would be absolute fools not to take advantage of the decades of industry experience residing a couple floors down.

Their experience would prove invaluable in helping us choose a new platform, and it would also be necessary for any new system to meet their rigorous standards in technical and security reviews. Our first step, therefore, was to do what so many people in the tech industry dread: Get IT Involved.

In all honesty, however, that was one of the easiest parts of the whole process. I don't know if our IT team is just that good or if the rumors floating around the water coolers are just completely unfounded. Let's go with the first one (please don't lock me out...).

Granted, it helped a lot that we were able to clearly state why our problems with the current toolset were legitimate. I remember a lot of, "It takes HOW LONG to build the site?" when we first started these conversations. An agreement was quickly made and a partner developer on their team was assigned to help us find a new platform.

The requirements were simple. The new platform needed to be: fast, extensible (particularly when it came to direct content authoring), and to have an active development community. There was little point in migrating if the underlying tools would be woefully out of date within the year. We looked into a huge variety of static site generators, eventually narrowing our focus to three and then, primarily thanks to our partner developer's technical and security reviews, settled on our final tool: Hugo.

Unfortunately, as everybody who has gone through a migration knows, this is the easiest part of the process. Our technology was picked fairly quickly, but once we chose Hugo, Zoltan and I were back to working on new things on the site. IT had to juggle their own set of competing priorities as well.

It wasn't that we didn't care about the project, quite the opposite, but the nature of working on this kind of thing is that if nothing is actively on fire, there will always be something else that's more immediately important. Or at least something for which we'd have to start digging ditches and stocking up on hoses, to extend the metaphor. The work on migrating slowed to a crawl, and I ended up going on vacation to Iceland.

Naturally, that's when the fire broke out.

While I was off basking in a hot spring somewhere, a routine push containing a couple of new blog posts went up at around the same time that our documentation surrounding a new version of the product was going up. Fun fact: that property took eight hours to build! Having two resource-intensive processes running at the same time on our build server completely overloaded it and it crashed, preventing anybody from deploying anything as we scrambled to piece it back together.

Thankfully none of our live sites were affected, but we were forced to move to a strict schedule of manual builds so that we wouldn't conflict with other web properties. This had significant impacts on our agility and our ability to keep up with the needs of our content team, and it became painfully clear that we couldn't put it off any longer. It was time to make migration a priority.