Replacing an established website necessities a good content migration plan
When you’re redesigning your website, the most exciting part of the process is the redesign itself. A fresh look, improved navigation, new interaction modules. None of which matters if you don’t have any content. Content migration - moving and transforming content from your old site to your new site is frequently the most challenging step in launching a new site.
Migrating all of the content from your old system (or lack thereof) to your new system should be your primary goal. If you’re moving from one IA to another then there may be content relationships which you want to retain; if the content is worth keeping it would easier maintained within the new system; and it makes it easier to find, as opposed to existing in another complimentary system. This is all predicated on the assumption that you’re not abandoning content!
The content migration process includes a few discrete steps:
Your content inventory, of both existing content and the updated information architecture, will inform all subsequent steps in the migration. If you are in the client’s position this step in the process will take time and effort on your part. The content types and fields identified by a consultant from a system analysis may very well differ from how you understand your content. Content types might be different data objects and templates or they might be defined by nothing more than context and judgement. You will need to be thorough in making sure you have identified your content types.
Mapping the content includes identifying which old content types will migrate to which new content types and under what rules. As a simple example, you might decide to migrate content from a WordPress installation into a Django based site. In your new schema you’ve decided to do away with categories but retain tags. You migrate all post tags as tags, but you still want the information provided by the category labels, so you migrate all categories in the old system to tags in the new system. A simple and perhaps ill-advised example, but it illustrates the kind of decision you’ll need to make.
Wen you finally get down to moving data you have a couple of options. You can either move your content by customizing the new CMS to share the old database or, and more likely, by creating queries to copy content from the old database to the new database. Think carefully about whether your migration will be a one shot effort or may continue for a short period during development. Your queries may differ greatly under the two scenarios and you don’t want to have to rewrite them if they’re complex.
A critical step to consider at this point is content cleaning, especially if clean content was not enforced by the previous content management system. Problems with content can include bad user entered metadata, improperly formed HTML, absolute links and image references, improperly added special characters, and HTML formatting that fails under your new site styles.
Some of this cleaning can be done prior to migration, such as removing extra space and reformatting special characters. However other edits, such as link and image paths, need to be addressed after the content has been migrated to the new system. If you’ve mapped old content paths to the new system, you’ll want to update embedded links based on that map. If you create an archival site you may want to update those links to point to the archival site.