Previously we discussed planning and data modeling for a content migration system (CMS). In this final segment we cover what a content manager can expect when migrating data from one CMS to another. An old-to-new CMS migration adds two variables to the mix — functionality and data mapping.
While similar, no two CMS products are identical. Most of the time if you understand one system, learning another is fairly straightforward. As a content manager, you’ll want to assess the functionality gains and gaps between the systems. Your new CMS better be more robust than the old one, so it is reasonable to expect a net improvement in usability and performance. Still, differences are inevitable, maybe in some of the most basic operations. Plan for a user testing phase to assess things such as:
- Speed, i.e., time trials to measure response time for various operations
- Manipulating and moving objects within the CMS
- Specific constructs; for example, how ordering tables are created and rendered
Engage as many of your best content developers as possible to test the new system. If you see a significant regression in the ability to present customer-facing information, sound the alarm! Compile a Bug List for follow-up with your CMS provider. Many a problem can be fixed with a few hours of programming or a change in user rights.
Before you can transfer data, you must map all data fields from the old system to the new. This includes your copy fields and SKU-level attributes. It’s a painstaking and exacting task, but done correctly you save hundreds of hours of rework.
At this stage you have the priceless opportunity to clean up your content in several ways:
- Consolidate data
- Parse data
- Standardize data formatting
- Discard obsolete information
Let me give you some examples.
Consolidating and parsing data. Suppose your old CMS stored product family copy data in one or two fields. To make the data more flexible, particularly for character-delimited web page fields, you can choose to parse the data into a new set of attributes.
On the flip side, maybe your data is parsed too much. You can consolidate it into a shorter list of attributes. Here are two alternatives:
|Parsed List||Condensed List|
|Family Title||Family Title|
|Intro text||Intro text|
|Bulleted Text||Bulleted Text|
|Ordering Information||Miscellaneous Text|
|Certifications and Compliances|
|Alerts and Warnings|
There is no correct answer as to which direction to follow; it depends on what works best for you.
Standardized data formatting. I’m talking primarily about SKU-level attributes that hold a product’s specifications and features. A migration is the right time to clean up your data and start fresh with an approved set of attributes that are populated consistently per your style.
Suppose you have the value for “Length” scattered inconsistently in attributes named Length, L, Size, and L x W x H. Take an export from your old system, pull it into an Excel spreadsheet, copy and paste the data into your selected attributes and import ONLY the new set. Not only does this improve the quality of your data, it facilitates parametric searching and makes it easier to ordering tables from a template.
Out with the old. If the old CMS houses past issues of catalog structures, or content that is ten years’ out of date, forget about it. Why clutter your new CMS? Like moving into a new house, you’ll decide what to take with you and what to leave behind at the curb.
When the mapping is finished, you’re ready to migrate the data, which is typically done programmatically. Batch your data into manageable size allotments. Afterward, have your team do a quality check on the migrated data. Are you seeing what you expect to see?
Plan for an overlap period during which your old and new systems need to be maintained before you fully implement the new CMS.
And understand the stress placed on your content and IT teams during the project, especially if they are juggling the migration and their regular work. Be supportive.
DISCLAIMER: This article is intended to advance the reader’s general knowledge about content management systems and should not be interpreted as a guide for specific applications or circumstances. Readers are encouraged to consult their CMS provider or a reputable content consultant for guidance with their individual data migration projects.
Dan Skantar is Director of Content Services for JP Enterprises