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 part 3 of this journey as we take you through what it's like to migrate a marketing website.
As we—primarily Zach—began discussions with our partner developer from IT about planning the migration's first steps, I had gained a pretty firm understanding of how our current site was laid out. I audited the codebase and catalogued which templates, partials, and content files were either horribly out-of-date, or had become completely obsolete.
Unfortunately, I couldn't simply remove everything I deemed unnecessary or old. Even in the case of content that hadn't been touched in years, there was still a chance it had to remain on the site for one reason or another.
In many cases, myself or the website's content manager, Jaq Evans, needed to hunt down whichever member of the company owned that slice of content and ask whether we could remove those old pages. Often that required working some important nuggets from the old content into newer pieces, like blog posts discussing similar subject matter.
In other words... the process was slow. Dealing with old, low-traffic pages wasn't the top priority when there were always upcoming projects and web pages to get out the door.
With all that said, there were still large portions of the old site that I could remove or renovate on my own. There was many-a-branch titled "[X]-cleanup" in the second half of 2018 and early 2019. I worked my way through a long series of projects..
If I didn't need to remove or edit a page, I could simply port it to a more current template already in use without needing approval. As I mentioned in part 2 of this series, due to a lack of development resources and a site structure that wasn't future-proofed for the rapid growth it was now undergoing, we had too many templates and muddy rules for where to use them.
To remedy this, I began the arduous process of slimming down our options for templates. Press releases and blog posts could fall under a simpler, newly-created "post" template, with a heading, body, sidebar, and a standardized footer.
Our marketing landing pages (e.g., the solutions section of our site) were more complicated and required a great deal of flexibility. They included hero text, any number of custom blades diving further into the page topic, and a footer usually highlighting one specific call to action.
After I'd streamlined the hierarchy of templates, Zach and I made sure that, going forward, every page could fall into one of a few logical buckets that determined which template it would utilize.
With the deep cleaning done, we began translating pages from the old site generator's language, which was matching content files to templates. Our template files contained code specifying what to include from the content files. That code needed to be rewritten in the Hugo templating language, but the fewer template files and partials we had, the less we had to translate.
With this simplified design, our understanding of the logic behind our website architecture, and a clear list of templates and their associated hierarchy, we had an easier time converting over to Hugo, our choice of new site builder.
And so, by the time we began to work on migrating to Hugo page by page, I had trimmed hundreds of obsolete files and cut the number of templates from around fifty to a dozen.
