The Auto-Magic Content Migration Myth
Few elements of a rolling out a new CMS driven website or redesign are overlooked during planning as often as content migration. I think there are a few reasons why this happens:
- Many project sponsors are still unaware of the critical importance of content strategy.
- Those who understand the many ways content can derail a CMS project may be hiding from the pain.
- Because of the massive investment in design and build resources, content strategy is often carved out of the plan or internalized.
Unfortunately, this does not make the content migration (or many other content related risks) disappear. At some point the build team is going to ask for content. If the implementation partner is experienced, this will happen before development begins. Although we believe this is already late in the process, at least it’s at a time when the cost of migration can be properly considered along with the cost of development.
When content migration is being estimated, stakeholders often ask: “Can’t we just automatically migrate the content over?” Like so many others, the answer to this question is: it depends. In some cases it makes sense to migrate content automatically and in others it does not. However, it’s really important to point out for many projects, automatic content migration is unlikely to be the road to efficiency and savings one may imagine. Particularly if the decision to explore the possibility is coming up after strategy, planning, user experience design, and content modeling have already been completed.
When automatic migration works
Automatic content migration is an incredibly valuable strategy under certain circumstances but there’s still a lot to consider. For example, if the scenario is migrating thousands of content items between identical content management systems where the structure of the data and the user experience design requirements have not changed, and none of the content is going to be edited in any way, this is an excellent candidate for making an investment in building or obtaining a programmatic solution. Bonus points if the two content management systems in this scenario are not separated by ten years of version updates.
Any sufficiently advanced technology is indistinguishable from magic. – Arthur C. Clark
However, consider this same scenario with only slightly different parameters. For example, unique content management systems for the source and destination. Under these circumstances the investment in creating or configuring the programmatic migration goes up as well as the cost of checking and likely making slight adjustments to the content in the destination website. Depending on the number of records, it might still make perfect sense to migrate automatically, but I think we can see where this is going.
When it clearly does not
On the opposite end of the spectrum, let’s explore a scenario where automatic content migration almost never makes sense: Unique content management systems, an updated content model, lots of different content types, under a thousand total records, and new user experience design requirements. Unfortunately, this describes a fairly typical project. Even if there are over a thousand total records, the majority of them are usually tied up in only one or two content types such as news and events.
In scenarios like this it is even more important to spend an appropriate amount of time running a cost/benefit analysis against each approach to determine what makes the most sense. But add any level of content editing to the mix, which is also often the case for a typical project, and that probably ends the discussion around automatic migration.
Plan early and often
Realistically, most CMS website projects are going to be a candidate for a hybrid automatic/manual approach. Regardless, the best strategy is to start content migration planning early and update it often. If the team does not include a content strategist, it’s never too early to suggest a content migration plan is created.
If part or all of the migration is going to be handled automatically this plan should include:
- A detailed technical specification for the migration program
- A statement of work for building and/or configuring the program
- A migration content model indicating the mapping of content attributes from the source to the destination.
- A timeline for the migration
- Quality control planning
For those parts which will be handled manually, the plan should include:
- A timeline
- A migration spreadsheet which at the very least indicates (for every record in the site being migrated):
- Original location of the content item
- Ownership of the content item
- Destination location of the content item
- Destination cotent type
- Sign off indicating the item is ready to be published
- A content deck with templates that match the content model of the destination website.
- Quality control planning
We’d like to know how content migration has worked out for you on past or current projects. Please leave comments or send us an email at jcram [at] connectivedx [dot] com and we’ll send a CMS Myth tee shirt to the first person who is willing to share a story. In the future we’d like to spend more time unpacking the specific components of a migration plan so we’d also love to know what’s worked for you and your team.