Tips for Content Migration in a DXP Re-Implementation

After having done many large-scale DXP re-implementations, we've seen many ways content migration can be the Achilles heel of a site redesign project. It is typically THE MOST underestimated portion of a DXP implementation.

Here are some essential tips to consider at THE BEGINNING of your DXP re-implementation project:

Will you be attempting automated or manual migration?

If you are doing automated migration, you will likely only be able to do the items with 200 or more of the same structured type of content. For instance, you can migrate all the news articles or all the products, but the rest will likely require manual migration. You will likely only be able to do the center body content, not the right rail or left rail modules. Also, automated migration IS A REAL DEVELOPMENT CYCLE. It will require some thinking/design up front and iterative development and testing. You will most likely need a separate environment to do it as well.

If you will be migrating manually:

You cannot start manual migration until the CMS input templates are more than 80% complete and tested. These are often the same as the output templates for products that provide 'inline editing' but with additional tags specific to the CMS that provide help text and additional features for the editor. If you try manually migrating before the templates are 80% complete, you will risk having to re-add the content because the template structure may change. Manual migration of a system that is less than 100% complete will typically take 30-45 minutes per page, depending on the items that must be done (below).

Plan for 2 passes:

Whether you are migrating automatically or manually, you should plan on doing multiple passes through all the content. Doing everything in one pass is often impossible if you have shared content and pages with a complex navigational or relationship structure. The first pass is to load the content. The second pass is to link the content together (you can only fix an embedded link or image once the target content is loaded). You may need a third pass to set the navigation hierarchy and reset the meta-data (if that's not possible in the first or second pass).

If you attempt to migrate when the system is between 80-100% complete:

You will require a more technical resource. The CMS input final touches are most likely the last to be built. This means that a person who is okay with seeing bugs and working around them will be required, which typically means the resource will be more expensive. If you want to hire a low-wage temporary worker, you can only have them migrate the content once the system is 100% complete and tested unless you want many starts, stops, and wasted time.

Typical migration steps that are forgotten until you start:

Manually migrating content isn't just copying and pasting pages one at a time, as some people guess and plan for. After you get the body content in, you need to:

• Format the text (especially important if you are just pasting into a text blob OR if your CSS styles have changed dramatically). The quality of the CMS text editor will also significantly improve or hinder this.

• Upload all embedded images and re-add them to the pages (remember, the URLs to the images have likely changed).

• Assign SEO-friendly short URLs as well as redirects from the old site structure.

• Assign where the page fits in the navigation structure.

• Fix all embedded links (again, remember all the URLs have changed) in every rich text field and list of links and content relationships.

• Assign meta-data (e.g., URL, title, keywords, etc.) to the page.

• Assign right-rail modules that you'd like to have (even if they are the same modules as before, they will be connected differently in the new CMS, and most times, there are new ones in a re-implementation).

• Handle any new features added due to the new CMS, such as personalization, analytics, etc. (you went to a new CMS for a reason, right?).

Did you change the IA?

If you plan on changing the Information Architecture and/or Visual Design of your pages (page structure or styling), it will make it much harder to automate your migration and will most likely require manual steps. This is something you should know and plan for upfront. It will be a challenge if you tell your UX/creative team they can change the entire site UX and then tell your content migration team you want them to devise a way of migrating content automatically.

Did your Template Granularity Strategy change?

Granularity Strategy refers to how granular your templates are within your CMS. The more granular your templates, the more control your development staff has over enforcing the functionality and UX, but it will take your editors more clicks to accomplish a task (think "Add center body list" module, "Add center body image" module). If your templates are less granular, the editor has more free-form control over the page, but it can make each page look drastically different from the other (think "Page with Center Blob of Text"). Suppose your previous CMS had ten modules on the page, and you plan to build your new CMS with two modules on the page (to reduce the complexity and increase flexibility for editors). In that case, you will have a much more difficult time migrating the content, whether automated or manual. The same holds for going from a LESS granular to a MORE granular template strategy. You can recognize this up front and plan for when determining how long the migration will take you.

Tools are available that can help you with content migration (i.e., make it more automated), but they will still follow the rules above.