BlogThis 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 this journey as we take you through what it's like to migrate a marketing website.
I started working for the Web Properties team at ExtraHop in the fall of 2015, coming from a brief stint at a real estate startup in Kirkland right after college. While I had developed projects for school, jobs, and internships, this would be my first time working with a team on a well established web platform, as opposed to starting from scratch and working mostly alone. Through the first few months of development, I learned the system and the reasoning behind it, thanks to the patience of the other web production engineer on the team (sorry for asking so many questions, Jen!).
Alright, let's get into it.
Back in the olden days, the Web Properties team managed all of the different web properties that ExtraHop uses to support the product: extrahop.com (hey, that's where you are!), the customer portal, the documentation site, and the forums, just to name a few.
Each of those properties was launched around the same time in May of 2015. We moved them off of an extremely limited CMS tool to a fully customizable and controllable solution. This allowed for greater control over how each resource was defined, and circumvented potential security risks. As an example, the marketing site was built on Wordpress before the migration. To this day, by far the most common 404 errors served up on the site are from automated bots hitting index.php and login.php pages hunting for poor Wordpress configurations. Special shout out to the ExtraHop we have monitoring the website for giving us that information!
When building out all of these different properties, the team created a repo that contained shared styles, partials, helpers, and more in order to be as efficient as possible both in the initial development of the site and when making future changes. This became a fundamental pillar of each of the different properties, as each one pulled in the shared code before any additional code was applied on top of it.
For the marketing site specifically, we emphasized security and load times. Thus we decided to build the site on a static site generation platform, meaning all of the processing would happen on the backend and static HTML pages would be served up to the browser with only the most basic of DOM changes happening on the client side. The page load speeds would be much better than using a single page framework like Angular or React, and we wouldn't have to worry about maintaining databases for the content on the site.
I'll quickly break down how the site currently processes content:
- Markdown files provide the basis of the content, and the static site generator validates, formats, and uses them to define the directory/URL structure from there.
- The static site generator then ports the HTML-ified markdown into pre-defined templates that have other structures, partials, and rules depending on the type of content.
- From a dev perspective, we also run a watch task that rebuilds the site on our dev boxes once changes are made. This gives us absolute freedom when it comes to how a page should look and feel as well as which interactions a user could have. It also allows us to maintain a tight code structure and ensures that for most content elements, adding and updating is very fast for a developer.
On the downside, this does make it harder for content writers to control the content directly, as in order to update it, you need a basic understanding of HTML and Git.
Some writers were excited to learn these technologies when we implemented the new site in 2015, and became de facto content managers for those who were less enthused. (I mean, hey, when you're a small marketing organization, everybody has an absolute ton on their plate and most people simply don't have the time to learn a new technology. Don't worry, folks, I'm not judging.) As somebody who was used to Angular development, this process was a pretty big shift in thinking, but when you're working on 3-4 different properties a day, attempting to develop and push content for each of them, you start to learn and appreciate it pretty quickly.
About a year in, the Web Properties team was pulled into developing the prototype for what would become our anomaly detection engine. At the same time, the teams associated with the various properties wanted greater control over their development. As a result, in late 2016 the Web Properties team split up and I ended up in Marketing, taking over the development of extrahop.com.
The Marketing organization immediately made clear a desire for faster updates to our branding. Historically, these kinds of updates had come at a slow pace for several good reasons: one, the site takes about 30-60 seconds to rebuild when content has changed on our dev boxes and about 15-20 minutes on our build server. Two, the team responsible for implementing changes had plenty of other priorities to respect. Once the Marketing team gained dedicated development resources, however, that slow pace became less and less acceptable.
You may have noticed, dear reader, a host of changes on the site within the last few years and a deeper commitment to the ExtraHop brand than ever before. There's been a pretty big appetite for shifts in appearance and style as we ensure that ExtraHop continues to demonstrate itself as forward-thinking and innovative. As a result, while we still use that shared code repo as a foundation, extrahop.com is no longer as tied down by it as before. Yet the site is still bound by the same slow build times for each and every change we make.
Another big pain point for the Marketing team has always been the lack of direct control over our content. Because our chosen tool for static site generation doesn't integrate with a headless CMS, all of our site content comes through the Web Production team or our code-savvy content manager. We had to write an authoring tool that functioned as a form of CMS for our press releases, but found that difficult to extend to other forms of content. More importantly, nobody had time to maintain the code for that tool, let alone develop in it and extend it.
A few other pain points would come up in conversation, involving things like the generation of breadcrumbs for SEO purposes or localization of site content, but for about a year, I was the only engineer working on the website. So my answer was, "I would love to do that, but it would either require a change of site architecture, or enough development time on my end that we'd have to put all other projects on hold." I'd already hit the point where I couldn't keep up with our rapidly shifting brand structure, which lead us to hire another Web Production Engineer named Zoltan (who you'll be hearing from in the next post in this series).
I had hoped that bringing in another engineer would free us up enough to split our time between working on day to day updates, and on developing tools to alleviate some of the pain points with the current architecture. But, as it turns out, when you hire a new person, the workload only slightly decreases and what happens instead is that the quality of work goes way up. At a small company there's always more that can be done, so increasing the capacity of the team does more for increasing the scope of the projects we've committed to than it does for shrinking the existing backlog.
It also became rapidly clear that we would have to migrate to a new static site generator. The pain points were only getting worse and there hadn't been very active development on this platform in a while. Compared to newer platforms, the community was effectively dead.
So, as all these old pressures and new demands converged, Zoltan and I started discussing our pain points as developers and soon began a formal conversation about a full site migration. Stay tuned to hear his perspective on that next!
