Rules for Content Migration: Panning for Gold

Moving content into a new CMS comes with many caveats (for example, is it even a good idea, and migrating to a CMS is far more than just moving content). However you slice it, moving to a new system is an important time to think about your content. Specifically, what content should move? Kristina Halvorson's Content Strategy for the Web lists two reasons to have content: a) it supports a key business objective and/or b) supports a user (or customer) in completing a task. So the Compelling Vision is important here (as always!). It's not just about what can be moved in, but filtering out the gold nuggets from the muck (see The Web Diet for more overall ideas on shedding bulk from your site).

OK, so how do you decide what to move? The most straightfoward method is to have a spreadsheet of content, basically an audit of your current content, and then line-by-line decide what moves over. This can work for smaller pools of content, but what if you have 10,000, 100,000, or more pieces of content? Even with a hundreds of pieces of content this can start being a bit unwieldy.

Having rules (like different types of sieves to leave behind the useful tidbits) for content migration are more helpful than one-off decisions for the following reasons:

Apply in the system on ongoing basis

Why go through the effort of your migration only to have the content go stale immediately? If you decide that press releases older then four years old should be dropped during the migration, then do you really want seven year old releases kicking around your system two years after launch. Similarly, if you decide that pages that are regulation-driven and over one year old should be reviewed, then don't you want that in your new system? Of course, there's a whole other area of governance around actually being able to enforce these rules on an ongoing basis, but perhaps during migration planning is a good time to discuss this.

Better justify drops

In a simple (no beauracracy) environment, justification is not really relevant. For instance, if I want to remove a page from this blog, I don't have to argue with anyone about it. But if you are operating in a large organization, you could wind up in endless discussions going nowhere by reviewing content items on a case-by-case basis (or, perhaps worse, just decide to throw everything into the new CMS again). That said, if you are dropping a piece of content because of a rule (any content of any type that has not been viewed more than ten times in the last year will be archived), it's much harder to argue with (of course, you would probably also need to come up with some sort of very tight exception policy).

More easily to agree first and then everyone do work separately

Related to the above comment, if you agree on the rules first, then you apply those rules and everyone can get cracking on whatever they have to do on the content. For example, if a rule states that a page needs to be updated because it mentions a particular highly negative incident, then the someone can start updating it rather than spending time talking about whether it needs to be updated. Related to this, having some rules in place would better fit into a web operations management framework so that existing teams could make high-impact decisions rather than the impossible task of getting mired in infinite details.

More easily identify disposition

Let's say you have a spreadsheet of 50,000 pieces of content. How do you start? You could just start at the top and work your way down, but how efficient will that be? If you have a rule like any content not updated in the last 8 years gets put into an archive site regardless of any other factors, then you can (assuming you have reliable dates) apply that rule and start working through the content in chunks like that. Note that the process of defining the rules probably means that you need to deep dive into your audit, but the point is that with rules in mind you will quickly see patterns that you can apply to quickly identify the disposition for different content.

Better move content

By looking for patterns, some commonalities may be relevant to deciding how to move content. For example, you may notice that content over a certain age used an old HTML template you forgot about, but that could be scraped easily. Or you may realize that your old working papers can just be moved in as-is rather than needing any manipulation.

Explain to end users if appropriate

If you have these rules in place, then it may in some cases be relevant to your end users. For example, if certain types of content go into an archive after a certain period, you can indicate this to your users. This also gives you a means for public feedback on your decisions.

Reapply rules once you realize you don't have the resources

While going through this process, hopefully you can also take some wild guesses at the effort it will take to deal with different types of content. If working in your content audit spreadsheet, you could always have a running table of the total editing effort. If the effort is high, then you can re-evaluate assumptions, change quality levels, and many other options. One option is to migrate in less. If you have applied rules, then you can tweak the rules and then see the impact on the projected effort. If you went in and did your analysis in a piecemeal manner, then you would now need to go through and have all those negotiations again about what's moving and not.

Hopefully this has convinced you to at least consider defining meaningful rules for defining your content migration. Please share your thoughts or experiences in the comments below.