It has to happen at least once in a career – you find yourself facing a major website content migration.

Your enterprise situation will probably be unique. Perhaps you are replacing your content management system (CMS), and need to take a lot of content along with you, and it doesn’t look like the process can be easily automated. You might be transitioning to a responsive web design where your current content simply won’t integrate well into smartphone or tablet formats. You might be consolidating two or more websites, overhauling an existing information architecture (IA), deploying a new content strategy, integrating a legacy system, or (if you’re really lucky) all of the above.

how to do content migration

These processes will all require varying levels of technical and strategic content solutions, involving everyone from to content owners and content creators to IT. However, if you follow the best practices below, you can develop a successful content migration plan that can prepare you  for most situations and contingencies.

DEG has extensive content migration experience, particularly in SharePoint platforms but across all sorts of enterprise systems. In Part I of our content migration series, we help you with preparation – understanding exactly what a content migration is, how different types of content will affect the process, and key strategy moves to make before the migration even starts. In Part II, we cover helpful migration tools and techniques, as well as the basic steps involved in a content migration. And in Part III, we’ll look at common areas where content migrations break down.


What exactly is a content migration?

In this context, a content migration refers to moving web content from one platform to another, usually during the replacement or upgrading of a web content management system (WCM). Ideally, a content migration takes place as one of the final steps in a development process that integrated a user-driven discovery process and requirements phase. Content migrations are usually collaborative efforts carried out by enterprise teams with members from business units, content management, and IT. Making the migration happen usually requires a mix of technical solutions (like automation, or writing new code) and manual resources (everything from content creation to change management).

The best way to understand the challenges of a content migration is to remember what happened the last time you moved house. Hopefully, you first went through all your things, figured out what was really important and what wasn’t – and then threw out what wasn’t. Hint, hint. Even so, you might have been moving from a historic Victorian to an icon of modern architecture, and needed to replace a few pieces of furniture. Perhaps your living companions suddenly decided to redecorate entire rooms. Or you might have been moving from a larger space into a much smaller one (or vice versa).

You heard it here first. The challenges of moving house pale next to the challenges of migrating content.


What is content?

Content does not just consist of the text and images appearing on a web page. This would be like saying that a kitchen is made up only of granite countertops and shiny stainless steel surfaces, with no relationship to the room’s and appliances’ key functions. Kitchens may look simple on the outside, but open up your refrigerator and it’s a whole different story.

Similarly, content constitutes everything on your website and managed through your CMS, from webpage text to links, file types, metadata, permissions and targeting, etc. Before migrating content, carry out a content inventory that lists every single type of content on your site and where and how it is stored, and how you will treat this content in the migration. For example, if you plan to move video files to SharePoint 2013, you have several improved options for handling video on this updated platform. (More on key content-related changes between the SharePoint 2010 and 2013 platforms here.)

Shifting CMS systems can also alter your content in significant ways. Your document handling and archiving procedures may need to shift, for example. Or if you are moving to a system that targets content by audiences and permissions, be sure to outline this new strategy. As a general rule, familiarize yourself with the new system back end and how it handles everything from page titles, authors, and owners, to expiration dates, tags, etc. Your content exists as an evolving composite of multiple functional and contextual details.

Now that I confused you with that last sentence, just remember the kitchen.


How do you set the foundation for a successful content migration?

In a perfect world, your content migration will involve a perfectly balanced team of business units, content managers, and strategists, as well as IT personnel. You will also have buy-in from every key stakeholder. The people down in the weeds will be in alignment with those looking at the view from 20,000 feet. Despite having different business agendas, everyone will collaborate productively in support of the overall migration goals. And, oh yes, everyone will be trained on the new system before migration even begins.

Though we can’t promise miracles, DEG does recommend having the following ingredients in place before beginning a content migration.

  • Content inventory: Before migrating anything, you must know your existing content inside and out – quantity and quality, analytics, patterns, problems, and holes.
  • Content Strategy: Once you gather information on your content, you need to analyze its strengths, weaknesses, and develop an overall strategy.
  • Metadata strategy: Metadata helps your employees and customers quickly find the information they need, which is key to your business success. Working with enterprise systems like SharePoint, DEG approaches metadata by developing user-driven information architectures, then following up with analytics regarding folksonomies and user tagging.
  • Training and governance strategies: Under your old system, maybe only a few people had access to the CMS. Collaborative software, however, usually broadens this field considerably – which in turn broadens your training and governance challenges, too. (Check out this awesome deck on SharePoint governance.)
  • Stakeholder engagement and change management strategies: Any time you move or change content, you are also shifting your culture. Proceed consciously and cautiously. One strategy is to set up a core content migration team of content managers and IT, and augment that team with satellite support from individual business units. Be sure to identify local champions within those units – people who can successfully carry the message about the migration, educate about its goals, and do the on-the-ground work that is so critical to managing change.

Handling this last dimension – the overall context of cultural nuances and norms – is key to a successful migration. You can get all the details exactly right and check off every item on this list of best practices but if you blow it on culture, the migration (and thus the new system) might be negatively viewed.

It’s the same with moving house. Quite likely, you moved school districts, too, right? Imagine if your kids moved schools but you as a parent paid no notice to the fact that they were changing teachers, friends, sports teams, etc. Your tunnel vision would quite likely not lead to domestic tranquility.

Workplace tranquility might be a long shot, especially where a content migration is concerned. Regardless, putting these best practices into place prior to the migration will go a long way toward smoothing your path.

Later this week, we’ll share Part II of our content migration series – the basic steps involved in a content migration, helpful migration tools, and the major areas where content migrations usually 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>