It lies there just over the horizon and just below the surface of any new intranet implementation. It is the factor that is most often forgotten or ignored as the intranet 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 system to a new intranet is overlooked:

Content migration is underestimated and misunderstood.

Many organizations moving to a new intranet 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.

Big intranet? Big migration issue.

Content migration is ugly.

Put simply, content migration 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 intranet 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 intranet 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 ThoughtFarmer Professional Services 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 intranet 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 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 intranet 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.

Only migrate relevant content.

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 intranet. Highly collaborative 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 times that apply, any exempt content to which updates are permitted, how exempt content will be “caught up” in the new intranet, and who should be consulted if a mission critical issue comes up that warrants an emergency intranet 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 intranet migration on track by navigating around the content migration iceberg.

This is a modified version of a post that originally appeared on the OpenRoad blog.