The Top 5 Myths of Content Migration

Moving your home appears on the same ‘major life stressors’ list as birth, death and the end of important relationships.  Even with the promise of future positive outcomes (Yard for a dog! Bigger kitchen!) moving to a new home brings with it anxiety and dread.

Every daily routine is disrupted during a move.  All of these daily processes, the way things work in our everyday life, must be recreated on the other side, to some extent, from scratch. Moving, therefore, is generally respected as a ‘big deal’.

Moving content from one content management system (CMS) to another is a lot like moving house. The benefits and positive outcomes are trumpeted early and often in order to gain executive approval, secure budget, or maintain momentum for a project. But as with the realities of a bigger kitchen and a puppy, it’s easy to promote the promise of the new paradigm while glossing over the tedious work required realizing it. The challenge of migrating content is not always given the respect it deserves.

Content Migration is hard.

Once the rubber meets the road – or in this case, old content gets shoehorned into a new content model, a few common unvoiced pre-conceptions start to emerge.

I have to level with you:  the following are myths. But the real heartbreaker?  The false fairy tale that is exposed at the end is something  projects secretly believe.

Myth #1: One big move is best..

Move all the things on one exciting day circled in red on the calendar.

Generally businesses don’t take time off to conduct a content migration like you might with a big house move.  Digital production and publishing continue at their regular pace. No site downtime is tolerated and a freeze on publishing must be kept to a minimum. I understand why the “all at once” approach is appealing.  In order to minimize ongoing disruption it seems feasible, after a few practice runs, to do one massive migration and contain the trauma to a short period of time.

Even if you recognize the fallacy in this logic, the decision to migrate all at once is often led by an external factor – for example, the contract on the previous CMS is about to expire or there are a limited number of people hours available to devote to the cleanup.

Reality #1: Many mini migrations make more sense

In my experience, multiple migrations of specific sections of content, as opposed to one giant heave over the wall, is the better route. The primary benefit of many mini-migrations is learning important lessons along the way, making each subsequent migration more accurate and efficient.  You also uncover problems faster. If you migrate 20k pages all at once it may take weeks to discover an issue on page 16,657 that you wished you’d seen earlier.

Start with the easy bits

Start with a straightforward section of the site and disrupt a smaller group of users and stakeholders initially.  An easy section is one where the content doesn’t change daily and the content owners are supportive of the project.  Iterate toward the more risky migrations, which will tackle the most essential content managed by the most anxious of the content owners.  Everyone learns by doing, the process becomes repeatable and streamlined, and you learn from mistakes and build off success.

Myth #2:  The destination for my content is a turnkey environment.  Every piece of functionality I’ve seen in sales demos is ready for me to use on Day 1.

The new CMS neatly matches my needs in a plug-n-play way.  All those fabulous reasons I chose this new solution? They are all available to me out of the box.

To me, ‘out-of-the-box’ suggests immediate availability with little to no set up or instruction time required.  Real estate agents call houses ‘turnkey’ when absolutely no repairs or renovations are required immediately after moving in.  Often clients, having been through the sales process, imagine that purchasing a content management system is purchasing a turnkey, out of the box solution to all the pain points in their current system.

Reality #2: The CMS is the platform

In reality, the CMS not a finished product awaiting only content to complete it.  It is the foundation of the house, plus some blueprint best practices, and examples of other previously customized homes.  While there may be ‘move in ready’ options, they are generalized across the most basic of requirements. The basics are not likely to include the features that sold you on this new CMS.  Nor is your content likely to fit perfectly into the basic structure without a bit of preparation before migration.

Myth #3: Let’s just 'Lift and Shift' the content into the new CMS to make it easier.  We’ll figure the rest out later.

The license for the current CMS is expiring, and we don’t have time to make any decisions.  We’ll do all the redesign and content strategy once we’re in the new CMS.

Reality #3: Lift and Shifts are not effective

It may be necessary to migrate all the content at one time, hoping transformational magic will occur at the other end - but in the long run we learn that magic is not real and this is a much more difficult route.  Migration is never a 1-to-1 shift across the two systems. If it were, there would be no reason for the new CMS.

Begin as you mean to go on

The better option is to evaluate the content in its current state and make some fundamental content strategy decisions. A complete evaluation of the current content, along with a content model design, should be pre-requisite to migration. Some key questions to ask are:

• Which content shouldn’t be migrated?   
• Which content needs a more reusable structure?  
• How will content travel across all the various properties and screens that will display it?

Not evaluating the content increases the likelihood that you will re-create all the problems of the old CMS in the new CMS.  Process habits and organizational cultures are notoriously difficult to change. One benefit of the content migration upheaval is the opportunity it provides to promote new centralized governance and update content strategy.

Myth #4:  Manual Migration is too time-consuming and surely inefficient. We'll do none of that.

We have way too much content for any manual ‘cut-and-paste’ migration - it’s automated scripts all the way, baby.

Computers demand precise data structure in order to follow migration instructions accurately.  Web content best practices have evolved over the past two decades. The content in your current site has also evolved – probably over decades.  It is not going to find its place in the new site without some assistance.

The goal of an automated migration is to move as much data as possible via a script.  The percentage of content that can be moved by scripted migration depends on many factors.  However, some degree of manual cleanup and quality assurance is always required once the scripts are finished.

Reality #4: You’ve lost control.

It’s common to hear ‘But we have xxx thousand pages!  How can we possibly manually review each one?’

If you can’t confidently QA all of the pages of your public website – and for content heavy sites that generally requires some degree of human touch – then you have lost control of the content.  A migration is the perfect time to cull years of redundant, obsolete and trivial content from your public site.

Websites have been used for purposes other than publishing timely, accurate content.  Particularly in the ‘pre-cloud’ era they have been used for file storage areas or large size file sharing for information never intended for an external end-user.

Last year, I migrated training materials from one CMS to another - from the 1970s. 50-year-old training material may have value as research, but should be part of a historical archive not mixed amongst time sensitive press releases.  This kind of content creep is especially prevalent in industries with murky record retention policies.

Myth #5: Once all the content is migrated, we are mostly done. The site can launch soon after.

A little polish might be needed, but once migration is complete we’ll be 90% ready for launch.

This is a corollary to the previous ‘myth of no manual migration’.  A content migration does just that; it moves the content from Point A database to Point B database.  It does not make that content visible or usable to an end user simply by being moved. Once a migration process is honed, it’s possible that content can migrate and be immediately available. But that is generally not the case in the first few migrations to the new CMS.

Bonus Fairy Tale: New technology will solve old problems painlessly.

Our stakeholders will hardly notice the under the hood transition as well as be pleasantly surprised by all the visual improvements they can spot immediately after the content migration.

Sold on the potential of a new CMS, clients leap to imagining a world where their current challenges evaporate and wondrous opportunities appear in their place, just as we tell ourselves that new kitchen makes me an excellent cook; the puppy will be well behaved and ensure I exercise.

Underneath every wish that a new product will solve all old problems lurks process management failures that dwarf the shortcomings of outdated technology. Process management problems in content development are usually people problems – internal politics, lack of communication, and ‘the way we’ve always done it’.

It’s important to remember that it’s not the ‘moving’ that stresses us out - it’s all that the move changes that is actually the stresser.  Change is hard. A content migration if done right, is ultimately part of a sweeping enterprise change management program. The technology is only one piece of the puzzle, just as the moving van is one part of a life changing re-location.

Respect the holistic need for organizational change management when migrating content into a new CMS and you won’t be disappointed by internalized myths that never come true.