Five Suggestions for a Successful CMS Migration

Migrating to a new system can be surprisingly difficult (some reasons).  The following steps can help in your migration:

1.  Define success and broadly communicate the vision

This step sounds so simple but is easy to be missed in the excitement and work of a migration: Clearly and simply identifying success for your migration efforts, and then broadly communicating this vision.  It's certainly not enough for the success to be defined in some obscure report that no one reads.  Defining success does not need to be complex, but something that is concrete enough to be testable.  In fact, something simple like "1) client-focused (not company-focused); 2) broadly repurposed content; and 3) easy to change look and feel" could be a good statement to broadly communicate.  There are several reasons for doing this:

• Set expectations.  The statement will NOT include some things that some groups think are important.  Instead of people being surprised that something is not provided that was briefly discussed (people often mistake a conversation about potential functionality with a commitment to provide that functionality), this makes things more clear from the start.  The best time to discuss these is BEFORE migration and not mid-way through.
• Testable.  These success criteria should not be so lofty that they cannot be tested.  Ideally, you would define exactly how this will be tested before starting as well.
• Provide focus for everyone.  In the heat of the migration, there will be a lot of people asking for a lot of new functionality.  By defining the migration success factors up front, hopefully everyone can stay a bit more focused.  

Obviously, a key point in messaging is making sure that no one thinks the migration/launch will be entirely seamless.  Of course this isn't the case, so it's best to let people know this.  By having the goals clear in everyone's minds, hopefully it will make the hiccups easier for stakeholders to take.  

2. Put your site on a diet

What's probably obvious is that migrating less will be less effort.  By undertaking a ROT (Redundant, Outdated, and Trivial) analysis before your migration, you can restrict what content/sites get moved into your new system.

That said, a bigger issue is *ongoing* dieting (rather than a binge diet just for the migration).  What can start out as an effort to eliminate sites can actually wind up being an explosion of sites depending on how you proceed.  This isn't just a technology issue, but more of a Web Operations Management issue.  See my Web Diet blog post for more background.  Note that by setting expectations on the complexity of your site before migration, you can better control things.

3. Don't fall in love with the technology

This one is tough.  Most people will fall in love (initially) or hate (eventually) the technology they use for their Web site.  Obviously the technology is important, and you may currently have an Web infrastructure that does not allow you to do what you need.  For the purposes of a migration, some technology traps to avoid include:

• Doing something just because you can.
• Only doing what the technology can do out of the box.
• Blaming technology for people issues.
• Not considering your content authoring strategy.

On the last point, a major advantage of a CMS can be metadata-driven pages/sites.  Without considering the tagging process and quality, you can end up with even more of a mess than you have now.  Thinking through your content authoring strategy means that your process and tagging have a better chance of successfully (and efficiently) driving your site.  

4. Define process for prioritizing issues

The second you start migration, people will want changes (configuration changes, new features, changes for expediency, etc).  If you don't have a process in place before these requests happen, then you may make changes that are difficult for your users and make your system more difficult to manage over time.  See previous posts on Tool Product Management and Web Product Management  for more information.  

5. Honestly ask yourself: are you ready for migration?

Take a cold, hard look at your migration readiness.  Of course, sometimes it's just time to migrate, and things will never be perfect.  But by looking at your situation objectively, you can hopefully mitigate some risks.  For instance, if you do not have the staff you really need, then putting more effort in the process for prioritizing requests may become more important.  Some keys to consider:

• Resource requirements.  Do you have the technical resources (for migration scripting, configuration of the CMS, developing integration points with your other systems, etc); internal client support (liaisons between various units at your organization and the technical resources); editorial; training; and help desk support?  Note that you can generally expect a burst of resource needs once migration starts.
• Management buy-in.  Has management articulated this as a priority?
• Technical readiness.  Putting wishful thinking aside, are the systems ready? Are your most common use cases easy enough for people who will be managing sites?
• Overall Web Operations Management.  Do you have the ongoing operational capabilities to maintain your site (from Strategy, Web Governance, Web Execution, and Web Measurement)?  See Web Operations Management primer for more background.  

Migration is difficult but by defining success (and loudly communicating this), putting your site on a diet, not falling in love with the technology, defining a prioritization process, and carefully reviewing your migration readiness, you should have a more successful migration.