“The Joy of Content Migration” is not the kind of sexy title you will likely see gracing the cover of a bestseller anytime soon.  Information architecture, user experience, development, content strategy: Titles that include those keywords are a lot more likely to make your reading list.

how to do content migration

However, for all of these topics and more, content migration is often the first step. There will always be bumps, but in this blog series we present several content migration best practices that should help prevent blowouts.

In Part I, we covered the preliminary steps for a successful migration, ranging from content inventories and what content actually is, to governance and stakeholder relations. Here in Part II, we cover helpful migration tools and techniques, as well as the basic steps involved in a content migration. Next week, look for the final installment in Part III, covering common areas where content migrations break down.

DEG has assisted clients with countless content migrations on a wide range of platforms, although SharePoint is an especially popular one. We do everything from writing custom scripts to manual migration work such as revising content strategies and the content itself.

As well as the specific steps that follow, we also recommend using three overarching principles to help guide your content migration:

  1. When analyzing data, move from quantitative to qualitative
  2. When carrying out procedures, move from automated to manual
  3. When organizing (mapping) content, remember the difference between forests and trees


What tools can help with a content migration?

Each migration is unique, and will likely require an individual mix of automated tools and manual human resources. Your content inventory should help you decide which balance is right for you. Some common content migration tools include:

  • Software and/or custom scripts: Depending on your content, you can either design custom scripts or purchase a software package that can lift and shift content from one CMS to another. Large databases, document libraries and archives, user groups, etc., are all great candidates for scripts (presuming the fields are well organized and the data is good).
  • Project tracking: The specifics of your project tracking will vary according to the needs of your particular migration. During one recent migration, members of our team used several SharePoint lists, such as one for content inventory, another to track final IA mapping, and yet another for the manual migration pipeline (steps such as web page assessment, editing, uploading, review, and proofing). Remember to track the content needed to fill every single web part, library, list, etc., not just to move the webpages.
  • Project management: Large content migrations require a dedicated project manager. This helps keep the project on track and facilitate productive two-way communication between all members of the migration team, from content creators and managers to IT and the individual business units. At a very basic level the project manager breaks the migration into phases and assigns roles and responsibilities for who moves what content and by when; however, the less quantifiable communications piece is equally critical in helping with change management.


What are basic steps of a content migration?

A successful content migration is made up of four steps: Evaluating content; mapping metadata; migrating content; and review and testing. For each step, you are usually balancing a mix of automated and manual tasks.


STEP ONE – Evaluating content

As covered in our previous posts on content inventories and how to prepare for a content migration, before you can move your content, you need to quantitatively and qualitatively assess it. The quantitative aspect can often be automated. For example, DEG writes programs that crawl your existing site, gathering all sorts of content information. We can also set up rules (such as date created, frequency of access, last date accessed, etc.) to help you determine whether or not the content should migrate. Analytics are also extremely helpful, but intranets aren’t always equipped with robust analytics.

Qualitative assessments require real live human beings to go through both the website and the quantitative data, in order to make some key judgment calls. At the end of the evaluation phase, for every piece of content you should be able to answer these questions:

  • Is the content necessary, or does it need to be deleted?
  • Will the remaining content migrate or stay behind (and if stays behind, will it be deleted or archived)?
  • How much clean up and revision does the migrating content require? Does the content have any special technical requirements that might involve custom coding or other accommodations?
  • Will you migrate this content through an automated process, or will you migrate it manually (using a copywriter, editor, uploader, etc.)? Work closely with your developers and IT people to develop standards for making this decision. Also remember, automated migration processes often require a manual cleanup phase afterwards.

A thought on manual processes: Labor-intensive activities, such as substantial edits to text-heavy content, will go a lot faster if you provide internal style guides, branding guides, and content strategy documentation to those involved. Another idea is to take a few key wireframes and develop them one step further into sample content pages. Such samples can help an editor establish consistent content patterns to repeat across your site.


STEP TWO – Mapping metadata

Designing an information architecture (IA) is part of the development process. However, the content migration is where the metadata theory suddenly becomes very real – especially when it comes to mapping, or deciding exactly where the old content will fit in the new site. Additionally, the development process may have decided to map the IA only through the first two or three levels, leaving the rest to be decided during the migration. (This is also where you find your content holes, and start tracking the content that will need to be generated in Step Three.)

This is also a good point in the process to start thinking about setting up tagging systems and term stores, as well as dealing with governance issues (are term stores open or closed, for example). In automated migrations, you want to make sure to automate at least some of the content tagging as well, if possible, and you need as stable as possible of an IA in order to make this happen.

When working with metadata, it might also be helpful to set up a spreadsheet tracking various content relationships – between tabs, sections, webpages, documents, etc. Remember, one important goal for a metadata strategy is to render all your content searchable, refinable, sortable, filterable, displayable – in general, to make it easily accessible to the right user at the right point in their workflow and overall use patterns.


STEP THREE – Migrating content

Bet you thought we’d never get here. Sometimes it does feel like that, but please believe us when we tell you that the more you lift on the front end, the smoother the actual migration itself will go. And really, this step is pretty self-evident. For the automated parts of the migration, you develop the scripts, migrate the content, clean it up, and start testing. (That makes it sound so simple.)

For a manual migration, you should set up a pipeline that reflects each step it takes to migrate old content and generate the new. Try to think of this kind of migration on the tab (or micro-site) level, or even in terms of the categories within your IA. One useful workflow format might look like this: tab or section assessment, individual page assessment, writing page titles and metadata, content editing and/or generation, business unit approval, content uploading, and content proofing.


STEP FOUR – Review and Testing

Congratulations, your team just migrated seven hundred pages of content and countless document libraries and other assorted files! You also created an entire new metadata strategy of which you are very proud. The group is doing the happy dance around the room, hovering on the heady brink of saying to your boss – what the heck, maybe we can even take it live next week.

Not so fast. You must still allow adequate time for the following steps:

  • Content review by subject matter experts and business units
  • Content review by strategists and editors, in order to translate SME feedback into consumable web content that fits the overall site strategy
  • Testing on all sorts of different devices, to establish whether your content displays correctly in all browsers, plus tablet and mobile formats

If you use an agile design process, then you have probably (hopefully!) been doing the last step throughout, and those fixes are primarily technical ones.  However, when it comes to negotiating the occasionally fraught terrain between the different visions of SMEs and content managers, those interactions can occasionally slow a project down, and the fixes tend to have more of a cultural dimension.

Ideally, you read through Part I and paid close attention to the parts on stakeholder engagement and change management. As a result, you have at least tried to bring everyone along on the migration project. Content can sometimes transform significantly during Step Three, and content managers are wise to keep SMEs and business units in the loop.

As a last note, don’t forget to establish a series of content freeze deadlines. For example, it’s no fun to have people updating content on the old site when you have already migrated to the new, and you’d be surprised how often this happens. Likewise, freezing content during testing and proofing cycles on the new site is also recommended.

Are we done yet? Well may you ask. At this point, you might have checked off every item on every single spreadsheet, all your content might be migrated – and yet, the process does not feel complete. To borrow a useful cliché, this is because a content migration is not as much an end to an old system as it is the beginning to a new one. Content migration is just the first incarnation of an iterative and strategic content review process, which is a never-ending fact of digital life.

Come back next week for Part III, the final installment in this series, when we examine the common areas where content migrations break down.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>