Skip To Content

What a CMS Migration Really Looks Like. Why Would You Hesitate?

It’s no secret that the thought of migrating your CMS looks like a daunting task. Whether it’s the prospect of moving to a new version of an existing CMS or the leap to an entirely new platform, most of us look at the process with more than a little trepidation. Many businesses don’t want to consider it until an absolute necessity, which usually means you’re already behind before you start.

It’s understandable, this fear of change. Migration is work - a lot of work. After all, most of the benefit of migrating or upgrading a CMS comes from functionality. There’s rarely very much new whiz-bang, not very many exciting new processes, or even many things that might make the end-user experience noticeably different. And this means the ROI isn’t evident - at first. 

Some teams address the dull, necessary upgrade (that will make the engine run better) by wrapping it up in a redesign to give some new whiz-bang (and, honestly, a reason that makes the work seem justified). However, a redesign effort is so different in thought process, required stakeholders, and long-term implications that it takes something already full of risk and raises it even higher. Redesigns are best as a stand-alone effort or part of a complete, clean-slate rebuild of the site from the ground up.

If you tackle a migration with a disciplined focus and a strong plan, then the effort and time required can be kept in check, the risks can be managed, and the benefits can be clearly articulated against the investment. All you need to do is spend some time planning the steps - one at a time. When you deconstruct it, there are just three steps to a solid CMS Migration, from beginning to end:

  1. Current site audit
  2. Platform selection
  3. Plan & execution

By tackling these steps, one at a time, the whole process becomes much more embraceable - maybe even a little exciting.

Current Site Audit

A content site audit’s goal is to get your arms around how much work you can expect. You do this by taking a hard look at everything that’s gone into your current site, and this may involve looking at thousands of assets and maybe even years (or even decades) of some businesses. This is where it starts to get scary. The best thing to do is to list out the significant assets and then assess their value with something this:

  1. Major Integrations. Which tools are necessary to keep what you already have? Which aren’t? Be critical and honest.
  2. Content. How much is there? What are their functional types? What is unique or re-usable, what are the sources, and where are they managed?
  3. Users & Roles. Take some time to really look hard at your users and their functions, and then think about how many are essential? How many will you want to train on a new CMS, possibly from the ground up? It may sound uncomfortable, but it doesn’t have to be. Just be honest.
  4. SEO. How strong is your non-brand SEO? What pages are most highly ranked? How much will you have to re-do, and how much optimization will you want to start over from scratch?
  5. User Experience. Similar to SEO, what are the most well-traveled paths, and which are the least? Which navigations have to be there, and which don’t.

Platform Selection

Of course, this discussion could be several articles, and you should put some thought into more than a few to narrow down the best one for your business. But for this article, we’ll keep this one pretty high-level. The crucial thing here is that you choose something that covers your current needs and supports your future, with room for growth in the directions you anticipate needing it. For practical purposes, here is a list of some important considerations:

  1. .NET vs. LAMP (Linux, Apache, MySQL, and PHP). Consider the most basic foundation in the same way you would in building a house or a car. What works best for the kind of vehicle you want to drive or home you want to live in - for years and years to come? This means thinking about future-proofing, which leads to the next point – a headless vs. traditional model. The truth is that content, on the whole, is being consumed in ways we never even thought of, even just a few years ago. It would be best if you took advantage of all of them and even more avenues for distribution that we haven’t even thought of yet. 
  2. Out-of-the-Box Features. Remember that anything that’s not on the menu before you start opening the box is something you will almost certainly have to develop or integrate. More work? Sure. But it may be worth it, depending on how specific your needs are.
  3. License Costs. The potential ROI begins to show - this is the first cost that needs approval, so it is better worth it.
  4. Ongoing Maintenance & Optimization Costs. After all the costs you’ll have to put into the work, being surprised by maintenance and optimization costs can deflate any ROI - real or imagined - that you may have built up so far.

Plan & Execution

This is where everything comes together and where everyone - hopefully - is on board. After the considerations and evaluations you’ve just been through, you should have an excellent idea of what you’re doing. It’s this planning part that puts everything you did into perspective and pushes all the things you might have missed, glossed over, or tried to avoid (be honest!) to light. This level of planning makes the migration happen before it happens, so you’re not flying the rocket while you’re repairing the outside hull at the same time. Here’s a suggested framework:

  1. Map Out Your Content. Don’t kid yourself. This is big, and it’s hard. But it’s probably the most fundamental necessity to make the rest of the steps smooth while protecting all the hard work you’ve put into your site up to now while identifying gaps between what you have and what you need. Please make sure you consider categories, taxonomies, and different types of content and their uses.
  2. Identify What Can Be Automated. Look at the things you can program to move over via export/import or some script - it can be a huge time-saver. The most significant dependency here is that automated migration only works when your content is already relatively well structured in its current form.
  3. Identify What is Manual. As laborious as this may seem, it’s necessary for virtually all migrations that content will need to be manually re-created in the new CMS. Besides, your honest assessments earlier in the process have made the volume in this part more than manageable, right? Right!
  4. Train the Team. Once again, your critical assessments of roles and users earlier in the process will make this part much more comfortable. Besides getting each essential cog in the content machine to work well together, you should use the training process to identify further content migration needs. Also, try and use viable, real content in training. This gives the session better context for your trainees and helps with the migration process as a bonus. You can both confirm and test its viability while all of you learn how to manage it.
  5. Undergo Manual Migration. This is where everyone gets to test the training, practice, and make all the magic happen that brings the new CMS to life, all at the same time. 

Breaking up an arduous and scary project into smaller parts is the key to making it work. Breaking all of those smaller parts into even smaller pieces makes it look almost easy -- or at least something that can fit more easily into your team’s schedule and workload. While most teams think CMS migration is a beast (and they aren’t always wrong), it’s usually less scary and more manageable than they think. And it’s almost always worth it, which brings me to my last tip:

Plan and document your success. This can fit into different parts of the process for other teams, but somewhere between taking a hard look at your current site and planning the migration’s execution, take time to document the improvements and successes you expect. Because a migration can be transparent to end-users and many stakeholders when performed well, this step is in some ways more important here than it is on other types of projects. Whether it’s improved performance, reduced security concerns, less time spent managing content, or anything else, please make time to document it and understand how you’re going to prove it. 

As you move through the process, you’ll be glad in hindsight that you didn’t saddle this clear-cut, manageable improvement with all the uncertainty and subjectivity of a rebrand or a redesign.