The Official OpenRoad Blog


Content Migration: the iceberg of CMS projects

It lies there just over the horizon and just below the surface of any Content Management System (CMS) implementation. It is the factor that is most often forgotten or ignored as the CMS build barrels toward launch. It is often left out of the project plan altogether but can take longer than the build itself. It is content migration.

It’s easy to understand why migrating content from your old website system to a new CMS is overlooked:

Content migration is underestimated and misunderstood.
Many organizations moving to a CMS have never been through a migration before and get blindsided by the amount of coordination and planning required to get through it

Content migration is hidden.
When some consultants are bidding on work, they don’t want to raise the issue because it may balloon the timeline or costs vs. their competitors

Content migration is ugly.
Put simply, it is not attractive. Who wants to think about copying and pasting content or writing migration scripts when you can spend your time admiring your site’s new visual design or playing with the new features of a recently installed CMS software package?

For all the reasons to ignore the inevitable, the truth remains that failure to adequately strategize, plan, schedule, and budget for content migration can easily sink your CMS project. Failure to plan can lead to delays as the content migration drags past the launch date. Conflicts can occur as extra resources are called upon at the last minute to attempt to migrate mountains of web pages into the new system. After all of the hard work your team has put into designing and building the new system, content migration is the last hurdle — one that you don’t want to underestimate.

Here are some guidelines that OpenRoad uses to work with our clients to help ensure a smooth migration and an on-time launch.

Include content migration in the project plan. Time is required to consider and draft a migration strategy and approach document and to modify it as the project progresses and decisions are made. Time is required for the migration itself. Because the project plan is written early in the process, it is necessary to be very conservative and even pessimistic in the amount of time required.

Determine if the migration approach is to be Automated vs. Manual vs. Hybrid. Depending on the systems involved, it may be possible to automate the movement of content between systems. If the original system is a CMS or the original content is very structured and the content organization is to change little in the new site, then it may be possible to write a script that reformats the original content and populates the new content repository. Most scenarios however, involve a manual copy/paste job into the new system. Scenarios where a single site has content physically residing in multiple environments may utilize a hybrid manual/automated approach for different sections of the site.

Resourcing for migration should be addressed early in the project. The best case scenario has resources dedicated to the task until it is completed. To achieve this resources need to be booked in advance so that their regular duties can be cleared or reassigned for the period.

I have heard of some organizations outsourcing the content migration activity. I don’t recommend this because it distances the organization from taking ownership of its content and denies the opportunity for the content contributors to learn the new CMS inside and out prior to launch.

Reduce the scope of migration through ruthless pruning of the content inventory. The simplest way to reduce the time required for content migration is to leave any outdated or unimportant content behind in the old system. Organizations should only migrate relevant content to the new CMS.

Think about before, during, and after. The Content Migration Approach document should address content transformations that need to take place before migration begins, during migration, and once the content is in the new system.

Pre-migration: Reduce the inventory, determine URLs to grandfather, do a final update of the content before migration. If automated scripts are to be used, these should be tested and put through a dry run before the real thing.

During migration: What needs to be done to get the content into the new system? Regardless, this should be done during a content freeze – more on this below.

Post migration: What type of clean-up needs to be done once it is migrated? Often hyperlinks fall into this category as frequently the final URL (or link variables that render a final URL at run time) are not known until all content is in the new system.

Negotiate and communicate the nature of the content freeze before migration begins. Migration occurs best if the content on the “source” site is not being updated while content is being replicated in the new system. This entails a freeze or ban on updating the website for the migration period.

Every organization has different needs with respect to the ability to update their web site. Marketing-driven organizations will find any content freeze painful while a freeze at an institution or government department might pass by unnoticed. Any content freeze should be clear on the start and end dates that apply, any exempt content to which updates are permitted, how exempt content will be “caught up” in the new CMS, and who should be consulted if a mission critical issue comes up that warrants an emergency site update.

Foster a focused, goal oriented, teamwork based culture for the migration team. Assuming you have a dedicated team to copy/paste content, likely seconded from their regular duties, you need to keep the team focused and motivated. I suggest the following tools:

The War Room: Have dedicated facilities where the migration team can work together free from distractions.

Set goals and chart progress: A thermometer on the wall charts should be used to chart progress as the team ploughs through the content. Daily goals should be set for the team and each person so that migration is paced for the entire period.

Have an issue resolution process in place: The team should take advantage of each other to solve any problems that arise. If issues cannot be resolved in this way, tools should be in place to track minor bugs and a contact should be designated if a show stopper issue comes up.

Have little rewards and thank you prizes on hand: The migration team leader should give out little prizes to people who exceed their target, are really helpful at helping others solve problems or are great leaders. Keeping morale high will be important if a lengthy migration period is required.

Through careful planning and preparation and closely tracking progress during the migration itself, you can keep your CMS migration on track by navigating around the content migration iceberg.


Denise Lindores

Posted March 21, 2011 at 1:50 pm | Permalink

Is there a template available that you know of for tracking content that is added to the old site during content migration. This is bound to be an issue regardless of content freeze efforts.

Bryan Robertson

Posted April 19, 2011 at 8:43 pm | Permalink

Hi Denise,
My first recommendation would be, if your team already has a tracking system to keep track of content changes and enhancements, to use that with perhaps a few modifications. This way, when the content freeze is in effect you are not asking the team to use a completely new process out of the blue. For example, internally, we use a tool called JIRA to track website issues and changes. The tool lets us identify what type of change is being made. We have two change types or components of interest. One is “Content” and the other is “Content Migration”. “Content” represents regular content updates. “Content Migration” was used during our recent relaunch of our website for precisely these types of issues. Anything that requires follow up during a Content Freeze could be categorized as “Content Migration”, making it easy to produce a list, and track completion of later.

Using an existing request tool, list tool, or bug tracking software that your team is already familiar with would be the best choice. If you do not have such a system (or a team for that matter), then you could use a spreadsheet. The columns of your spreadsheet will vary depending on your processes and how you choose to manage your content freeze. To give you some ideas, I have posted a free sample spreadsheet that is available for download. The key things I recommend tracking are: where is the old content, where is the new content, what change needs to be made after the freeze is over, and who to go to if there are issues.

I hope this helps.


Posted March 11, 2013 at 10:51 am | Permalink

Hi! – a very decent automated tool for content migration.