Monday 16th July 2012 by Rich Saddington

For most website owners and administrators the data stored in their website databases is the most important part of the web infrastructure. Web servers and sites will change over time but the content and user accounts need to persist as the organisations web presence iterates and evolves.

The investment in this data for many organisations is immense and careful cleansing/backup processes are in place to ensure availability and integrity. This data needs to maintain this integrity when you migrate to the next iteration of your website.

The migration of this data is often one of the most complex and costly parts of a website project. The need to move user accounts and content from an older platform into a new shiny CMS or community platform is often considered some time after the need for a new platform.

Conversely some organisations put off re-platforming and carry on using out of date, sub-optimal systems thinking that the effort of moving all that content just isn't worth it.

At some point every organisation will need to consider data migration of some sort, the following should help towards a successful migration project.

1) Think about migration early in the project

One of the biggest risks with data migration is doing it too late in the project, it feels right to build the new site and then move existing content into it. However this approach means that content and data structures in the old system are easily overlooked.

You may find that fields content editors or admins need in the current CMS haven't been considered in the new system and will need adding. You may find some content needs specific JavaScript to display video or flash content. Discover these issues early and they can be factored into the site at build rather than added at the end.

Another benefit of migrating early is that your new website gets tested with real content as early as possible, its much easier to discover usability issues with real content over placeholder content.

The migration process also gets tested early allowing time for tweaking, re-running and re-testing during the project rather than in the final weeks prior to launch.

2) Audit your content

Performing a content audit at the beginning of the website project is a great way to evaluate your content and start to think about which content needs to exist in your new site.

Armed with a content audit the next step is to start defining rules to apply to the migration. Do you really need 10 years worth of press releases on your new site? Would the most recent 2 years be enough? Check your statistics, if no-one is viewing the content then leave it behind.

3) Clean your content

Dirty and inconsistent content increases the complexity of migration. Each small inconsistency or anomaly needs to be accounted for with migration rules or transformations, these rules need verifying and testing with real data. In a large data set with say 100+ fields to migrate, reducing these complexities will keep the effort and cost down.

4) Fully understand the existing schema

Understanding your existing database schema is really important. Standard CMS database structures are normally quite quick and easy to understand, bespoke or highly customised systems often take a lot longer. The more you can share with the team scoping the migration the better.

A test version of your existing site is a great way for the team scoping the migration to fully understand how the database schema relates to admin functionality and the terminology content editors and admins use.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Share on Pinterest
Link to infographic

5) Scope the migration work

Chances are you'll want your new website to do different things to your current site, this may mean content has a new home or location within the site. Your new site may need to use larger images for the desktop experience, it may provide a mobile optimised version where you want smaller images.

Depending on the solution for your new site you may find some content types are merged or become redundant. Others may need new fields to be populated to work with how the next iteration of your site functions.

This is the real nuts and bolts of migration work, and careful scoping and planning is needed to ensure all content, fields and rules are documented and agreed prior to building the tools to perform the migration work.

6) Migrate changes only

Watermarking is the process of regularly migrating new or changed content from one system to another. This approach can be started during development and automated to run daily ensuring content added to your current site is regularly synched to your new site. On go-live day you simply need to migrate content that has been created or changed in the last day or so rather than performing a risky and often time-consuming full migration.

7) Consider search engines

Your current site has been there a long time and content is well indexed by Google and linked to from other sites all over the internet. To keep your page rankings you need to ensure these URLs will continue to work on the new site. You're new site will have a new structure so you'll also want to implement a new URL strategy that matches it. Part of the migration process needs to be creation of mappings of old to new URLs using appropriate redirects to ensure your content maintains its page ranking.

8) Users accounts and passwords

Few systems use the same algorithm to encode passwords, this means the likelihood is that you won't be able to migrate your user accounts to the new site and have users login with their old credentials. The most common approaches to this problem are to provide a reset password function on the site or to send out a mail to all existing users announcing the new site and providing a one-time login link. Either way careful messaging should be considered to ensure you don't get flooded with support requests on launch day.

Summary

Every migration project is slightly different and will involve some bespoke work to make it work. The steps above should help to make the process successful. Have you recently been involved in a migration? What worked well for you? What didn't work so well?