Content migration can sometimes be tricky and even downright messy (with good reason). In fact, the content migration can be the hardest part of implementing a new CMS. Having worked on some challenging migration projects for one of our European clients, I’d like to share a few practical tips on how to make life a little easier for teams involved with particularly large and demanding CMS migrations.
First off, content migration should be executed as early as possible and presented to editors in the test environment. For large sites with thousands of pages, a 100% verification of their look and feel is hardly possible. However, starting the review process earlier helps with broadening test coverage and with identifying fresh migration-generated/CSS-related issues sooner.
Also, in order to migrate a large website with constantly generated and updated content, you may want to make your rollout sequence look something like this:
Let’s also touch on the issue of the old URL structure. Most large sites today have a wide variety of content: html, RSS, images, PDF files, etc. When moving to a new CMS, in most cases it is simply too expensive to preserve the URL structure 100% , even if the new CMS allows for that. A less costly and a more practical avenue to take might be identifying the types of content for which URL mapping can be preserved automatically, as well as the exceptional cases where the URLs can be fixed manually:
And another tip: If you have a team that is skinning/customizing the new CMS with off-the-shelf plugins or even write their own code, please keep in mind that they rarely diligent about documenting their changes in database schemas. To mitigate that, migration engineers should be part of this team from the very beginning to facilitate “osmotic communication”.