Seamless Content Migrations: Strategy Determines Success

Apr 17, 2015

Article ImageIt's almost a rite of passage: a content migration. Whether you've decided on a new and improved Content Management System (CMS), or your site is undergoing a drastic redesign and restructure, you will need to move your content -- without mangling it -- to the new system. And you are terrified.

Disastrous CMS implementations are a dime a dozen: budget overruns, content that gets lost or doesn't migrate accurately, or worse, a system that simply doesn't work after a significant commitment of time and other resources. But here's the good news: This doesn't have to be you. These disasters happen to people who don't plan, develop a good strategy, and get help from experienced partners who can guide them through the necessary steps.


So let's start with the basics.

First: Do you even need a migration? Even if you've already decided that you do, it's worth examining your assumptions. If you're redesigning your website, how significant are the updates being introduced? How will the site's new information architecture (IA) affect your current content structure? If the change is drastic enough, you may not even need to migrate your content. Similarly, if you're cutting back on your content because a lot of it is outdated or no longer relevant, you may not need to migrate most of it.

If you decide that a migration is the right path, your strategy will determine your success. Make sure to get these important factors defined prior to your migration: What will your new site's information architecture be? What will the content model or content tree look like in the new CMS? Do they work together? If not, you have to get them in sync first. What will be the design of key pages - the Home page, section landing pages, or others that might house significant content? Are you going to add more metadata to enable a richer search experience? The answers to these questions relate to business needs, but defining them helps to prevent disasters down the line.

Next, you need to capture what you're trying to move - and what you can leave behind. You'll need to conduct a thorough content inventory, one that answers questions like:

  • How much content do I have? This includes images, text, links, and other types of content.
  • How many types of content do I have, and what are their characteristics? For example, how much is structured (such as blog posts, white papers, or press releases) and how much is unstructured (free-form rich-text fields)?
  • Do we need this content at all? Is it outdated, irrelevant, not written up to current standards? It's like moving to a new house: purge beforehand, so you don't move stuff you don't really need.

Once you've understood what content you'll be moving over to the new CMS and what content might have to be written from scratch, you can identify what resources you'll need.


As with every web project, you will need a good amount of investment from internal resources. Members of your editorial team and superusers who are familiar with the legacy CMS are good to have on hand during a content migration. Their input can help guide your technology partner in developing an intuitive content structure that works for those who will be using the new CMS the most. This will help you to avoid one of the most common post-implementation headaches: lack of adoption.

On your implementation partner's end, you will need project managers, designers, architects, and developers to play their roles during the migration effort. These are the people who can help you avoid mistakes, define content, and formulate strategies ahead of time for a more successful migration.


Once you're on the content migration path the factors below can significantly influence the cost and timeline for your project and its ultimate success. 

Testing--This comes before, during, and last in the migration, but we're considering it first because it's so important -- and so often neglected. If you don't test, you won't know whether content is migrating properly, what's happening to content if it doesn't migrate, or whether your templates are working. Even more importantly, your technology partner can't do this without you. You know your content inside and out and only your company can detect the subtle changes or deletions that can alter the intent of your content and reduce its credibility.

One way to simplify your testing is to identify so-called "gold copy" pages that cover all types of content in a given category. For instance, one document might be a newsletter that has all the properties and elements that your newsletters might contain. This allows you to avoid checking all 300,000 pieces of content to make sure each migrated properly. Also, remember to validate whether your content is displaying appropriately across all browsers and devices that your solution has been built for.

An Automated or Manual Migration?--Automation offers significant benefits when your content library is large but its returns diminish the smaller your library gets. Content migration scripts often take two or more weeks to write and then they have to be tested - which is definitely worth the effort when you have 50,000 pieces of content to move, not so much when you have 200. In some cases, it may be cheaper to hire data entry people, especially if you've decided to edit content before it's uploaded to the new system.

The type of technologies involved in the legacy and new content management systems make a difference as well. If you're migrating from one .NET CMS to another, this won't be as much of a concern. However, if your legacy CMS is proprietary, there may be serious barriers to an automated migration. Similarly, upgrading from one CMS version to the latest won't be as easy if nine years of version updates separate them.

In the end, you may decide to pursue a hybrid plan -- moving less structured content manually while automating the migration of other, more structured content.

Your iteration plan--As your migration takes place, your website is going to continue running, right? This means that there has to be a way to move new content that is constantly updated in the legacy system. Hence, your content migration scripts need to be written in such a way that they don't overwrite either the source or the migrated content.

It also means that you have to decide when to freeze content. At some point in the process you have to shut off the ability to create new content in the legacy system, and the question here is twofold: When do you do this and how is production content going to be handled after the freeze is complete?

Redirects--Let's say your redesigned site houses all the press releases in the "News" section rather than the "About Us" section as it was in the old design. This renders the URLs that once pointed to those press releases invalid. Clearly, an important step in a successful content migration is a redirection strategy.

Sometimes, a simple tool like URL mapping will work. So can pattern-based re-directs, if your content structure under the new system is similar to the legacy system. Still another strategy is to minimize broken links by conserving the legacy file structure wherever possible.

Another consideration is page ranking. You don't want to lose your hard-earned SEO ranking because the URL in question has changed. With 301 re-directs, the URL can tell search engines where the new page resides and retain your legacy page's ranking.

In Summary

Most CMS implementations and content migrations go far from perfectly. Yet, with a proper plan and strategy, good advice based on experience with similar projects, the right resources, and a well-defined scope and roadmap in place, you can have a content migration that's relatively pain-free.

(Image courtesy of Shutterstock.)