How to Migrate Content in a Major CMS Redesign or Replatform

Whether you are redesigning your existing site but sticking with your content management platform, or migrating platforms, your content is likely going to change and that means a content migration will occur.

Revamping your content strategy may sound simple, but it is a terrific amount of work that impacts the site navigation, visitor flow, analytics, and (most critically—and often overlooked), the project implementation schedule itself. 

The good news is that investing time in improving your content strategy is likely the second-best return on investment for your digital time. The first is improving your navigation—and by improving we really mean mercilessly removing items from your primary navigation, sending your utility navigation to the funny farm, and cleaning up the footer navigation. Why? Because content is crucial to engaging your personas, optimizing customer journeys through your site, and converting visitors into leads.

Do this first

The first step is to plan your content migration. To do that, you have to ask a bunch of questions and keep in mind several considerations:

• Will differences in the destination content management system mean the content model needs to change? For example, will tags, categories, or taxonomy have to be built differently?

• Are there content features that aren’t available in the current CMS but are in the destination CMS that I can take advantage of?

• Do I want to perform any automated clean-up tasks on content, since I’m taking the time to migrate? For example, perhaps there is a new taxonomy field I could start using and that could be populated in a systematic way using the existing body content.

• Who is creating the new content? The client? The agency? External copywriters? None of the above?

• What pages need to be retired, what pages are moving unchanged, and which are being rebuilt?

• How will the URLs change?

• Do I have a cohesive SEO strategy to avoid losing any hard-earned organic visibility?

• How early in the development process can I have content ready? (The earlier the better.)

Once you review these considerations and have a good sense of what the new content reality looks like, you have to choose one of three content migration strategies: manual, fully-automated, or hybrid. Let’s look at each one, and why and when you should—and shouldn’t—choose them.

Approach 1: Manual content migration

Manual content migration means that one or more people will act like a member of the marketing department and use the existing and destination CMS interfaces to copy and paste the content over. This method is very cost effective when you don’t have much content to move, and when you want to conserve engineering hours.

When to use the manual content approach:

• You have less than 100 pages to migrate

• You want to change the content as part of the migration but the changes are non-predictive—meaning you can’t throw code at the problem and automate that pain away

• You have a terrific quality assurance team

• You have low-cost resources that can perform the work (think Amazon Mechanical Turk but more human)

Important tip: Make sure you have a clear plan for where the content migrators will enter in new content to ensure that the environment isn’t erased by the development team in the normal course of software development.

Approach 2: Fully-automated migration

In a fully-automated content migration, one or more of your engineers will create a script that moves the content from the source system into the destination CMS. These scripts will likely use APIs to extract, transform, and import the content.

One of the major benefits of this approach is that you can have most of the content loaded into the new site early in development. The earlier content is loaded, the more meaningful development is because your engineering team is working with a more realistic version of the site on their local instance. The functionality they develop will be dealing with more realistic data, and, as in software development, the more realistic the data, the more honest the code. 

When to use the fully-automated approach:

• There are many content pages to migrate, and it will require too many for humans to do it for less cost

• There are predictive content transformations you can make as part of the process

• You want to reduce risk in development by giving engineers a local environment that is more accurate about the actual experience early on

You want to avoid this approach when it would be faster to just manually move the content. Engineers are often enthusiastic about automating things (at least the good ones are), but they rarely stop to ask if doing it manually would take less time. Content migration scripts take time to write and refine because when it comes to content, there are always exceptions, exceptions, exceptions. You will quickly learn that instead of one pattern applying to how all content can be migrated, there are groups of content that require slightly different handling. 

Important tip: Migrating large amounts of content can take time. Ensure that the automation scripts are hitting the real source and destination systems to avoid surprising in-script run time during launch day. If you don’t fully simulate production conditions, you could find yourself with a script that you expect to run in a few minutes taking hours.

Approach 3: Hybrid migration

In a hybrid migration—you guessed it—you use a combination of manual and automated approaches. Typically you would automate more than 90 percent of the content migration; the content that isn’t changing much, and then the rest, which is perhaps comprised of more new pages that exist on the current site or are crucial landing pages, is managed manually. This gives the marketing team the opportunity to curate new content experiences for crucial landing pages and conversion pathways. 

When to use the hybrid approach:

• You have a large amount of content, but crucial pages (fewer than 50) are new and the marketing team will be refining these heavily throughout the project timeline.

• You have an engineering team that has managed content migrations before

The downside of this approach is increased complexity, as you have content coming from multiple angles, but you do benefit from applying the advantages of the most appropriate approach to each group of content.