How to Migrate Content Into a CMS

You're staring at a seemingly insurmountable pile of content that needs to be moved. For whatever reason, you are moving to a new content management system. How are you going to migrate this stuff? A natural conclusion is that you'll have to manually review, edit, and move content. That is understandably intimidating and would probably take a huge amount of time and effort. Moreover, especially for a large site, a manual approach has many other issues including lower quality due to inconsistency in decisions that the various editors make. Furthermore, even if you are going to be doing a lot of manual work, you should still look at the problem as a whole and break down the steps rather than just dealing with each piece of content in isolation.

So how can we turn this mess of content into something that is easier to deal with? In the following steps:

1. Divide the content into manageable pieces

2. Define quality and migration expectations

3. Take time to understand the implications

4. Sequence meaningfully

5. Generate content manifest

6. Migrate and re-assess as you go

7. Redirect and launch

Step 1: Divide the content into manageable pieces

For every piece of content on your current site, we need to define three things: 

• Bucket. What logical group does this content belong in? More specifically, what group of content that will be treated the same? A bucket may be a content type for example. 

• Disposition. What are you going to do with the content? In other words, how will it be treated? Dispositions are things like Drop or Move-As-Is-Automatically.

• Resourcing. Who is going to make the changes?

To see the overall picture we want something like this: 

Note that we aren't staring at a long list of content, but seeing the big picture. This isn't to say that we don't need to see the specifics. For example, sometimes we want to sample (very useful for large sites), filter, and slice content in different ways to find patterns and also to confirm that the data in our analysis is correct:

The site represented in the example above is tiny, so we could potentially go through the site content-by-content to make decisions. But this does not work at scale (like the first example image in this article). At scale, we need to make decisions using rules: 

Step 2. Define quality and migration assumptions

A natural place to being a migration discussion is on what you're going to do to the content. But really you want to anchor on quality. 

Obviously, there's the fundamental quality of the content that is about the writing/presentation. This may require rewriting content. If you're tempted to rewrite a lot of content, one of the most important things to consider is whether you have the resourcing to pull it off (see the next step, implications, below). 

In addition, there's the wide range of technical quality. If you're doing any amount of mechanical migration (be it automated or manual), you need to define the expectations clearly from the start. This includes things like whether Microsoft HTML cruft (from cutting and pasting from Word for example) will get removed and how images will get massaged (or not) on the way over.  Ideally you define, for a wide range of quality areas, who is responsible for executing that quality detail and who is responsible for QAing it. 

Step 3: Take time to understand the implications

One of the worst things that can happen in a migration is being overly optimistic. Why? If you start off assuming you're going to be making deep and wide changes, but mid-stream realize you can't, then you'll wind up doing what's easy rather than what's important. If you look at the implications of your tentative decisions, however, you can course correct before you even start the work. This means you can best leverage your available resources, or seek additional resources from the start. 

Step 4: Generate content manifest

In step 1 we are looking at the big picture of our decisions. Once we have done this and validated the implications, we are ready to generate the manifest. The manifest is a spreadsheet with a row per content item, with the following columns: 

• Absolute musts:

• URL of existing content

• Bucket

• Disposition

• Resourcing

• Nice-to-haves:

• Title

• Other columns that would help the person responsible for transforming the content to more easily make those changes

• Any other unique ID(s) to tie this back to other data sources

Note that ideally the manifest is generated automatically. Steps 6 and 7 extend and use the manifest.

Step 5: Sequence meaningfully

The migration should be sequenced for quality, efficiency, and to limit surprises.

There are a lot of factors that go into sequencing a migration, but some key elements are: 

• Include cycles for tweaking and responding to the migration, and provide the time to actually make improvements mid-stream

• Consider the data layer (for instance from a product database) in addition to the content that will be stored in the CMS — these need to be coordinated

• You need to see the content in the system to make sure that it "fits" correctly — ideally you implement the back end and front end templates before you start migrating so you don't have costly changes late in the process

Step 6: Migrate and re-assess as you go

During active migration attempt to do two things: 1) track what is happening so you have visibility into the process and 2) you stand ready to reassess. One of the things to do is have a clear set of steps for the migration: the states that a piece of content goes through during the migration. The steps might be something like: 

1. Unassigned. You know you have a piece of content that needs to be transformed but you have not yet assigned it to an individual person.

2. Assigned. The content is assigned to someone but they cannot yet start working on the content.

3. Ready for entry. The content is both assigned and the systems are ready for the migration activity to start. Whether content is ready for entry may depend on content type (some content types may be ready before others).

4. Ready for review. The person responsible for transforming the content has, to the best of their knowledge, completed their transformation and met the quality requirements. The content is now ready for review.

5. Done. The content has been reviewed in the new system.

To assess the progress, you can extend the manifest to include two new fields: 

• Person responsible

• Migration step

Then you can track progress over time:

Step 7: Set up redirects and watch launch

Aside from the content being in the new system at high quality, another responsibility of the migration is to make sure that redirects from old URLs to new ones work as expected. To do this: 

• Set up a redirect engine. 

• During step 6, for any manually-migrated content have a mechanism for either adding the old URL to the new CMS or add the new URL to the manifest (and then automatically use this information in the redirect engine).

• During launch, carefully watch for 404s.