Be Ready: Initiating CMS Migration

 CMS migration is a resource-intensive undertaking.  The following graph of central team effort isn’t strictly accurate but hopefully will illustrate some key points:

•    The first users will find issues that were not yet identified in pilot, as actual usage always uncovers nuances not found in earlier stages.  Even with very tight product management (so you aren’t just whipsawed implementing various whims of clients), there will probably be a burst in the central team’s effort when the very first users use the system to implement changes and workarounds and also communicate these changes.
•    Although perhaps not at as high a level, the required level of effort will continue to rise as more and more users enter the fray, but at some point (perhaps after 80% of sites are in the system) the central team effort should start going down.
•    The central team’s effort level will probably never go back to the level it was at during the pilot.
•    The steady state is represented as a flat line below although there will be occasional bursts to implement special initiatives. Since that’s in the steady state, that won’t be a focus in this document.

How do you brace yourself for this?  Some pointers:

• Define a process for responding to feature requests (and not just trying to implement every request that comes in).
• Attempt to clearly separate between changes to core CMS, templates, and items that end users can control, and treat each kind of request uniquely.  Ideally, only very sound changes are made to the core CMS, and most other changes are made to global templates.
• Ideally you should have a strong support team (including training, documentation, and liaisons between the implementors and user groups), technical team (the folks that can implement any changes that arise) as well as a product manager to ensure that changes are made in a way that keeps the CMS coherent / logical.