#3 Migration strategy and high level migration plan must be a part of your overall plan.

Most large business and/or IT transformations require a migration of customer or user data from the old to the new systems, and a plan for how to replace old systems with new ones – both from a user, process and technology perspective. 

Now, the term «migration strategy» in the heading is – at best – confusing; maybe even misleading^*). I just struggle to find a better term. I am referring to the complex matter of moving your business, users and organization from one technology ecosystem to another; partly or completely replacing the existing. Often, and preferrably, in steps; making this all the more complex.

There are several aspects to this:

• How are your customer relationships moved from one ecosystem to another?
• How are the users of your systems impacted?
• how are your business transaction managed throughout the change? How do you make sure that you do not lose money, and that your customers do not get any unpleasant surprises?
• How do you migrate data between systems? And how is data integrity upheld?
• How do you grow your new ecosystem? on the back of your exisiting, or on the side?
• How do you roll out changes, and how is the roll-out strategy aligned with how you do technical development and releases?
• And much, much more…

Fundamentally the migration strategy will dictate the end date, duration and cost of the project – and more importantly the timing of benefit realization and impact on the organization. Hence, the migration strategy has to be decided as a part of project initiation for the Business Case to be correct.

You need to guide your stakeholders and decision makers through some choices that will heavily impact your overall plan; your organization, benefit realization, risk profiles, communication, business plans and go-to-market strategies, etc. You will also need to explain the consequences of the different choices, and the dilemmas associated with them. And there are no silver bullett solutions here – you can bet your bottom dollar on that…

Some areas that need to be discussed with stakeholders are typically:

• Will your system replacement impact your customers? And if there is customer impact – are you planning on combining the replacement with launches of new products, rebranding, new features etc?
• How are the company plans for market launches aligned with your project plans? What is on critical path?
• Do you aim for a greenfield approach or brownfield?
• …and if you have decided on greenfield because it seems very convenient and looks nice in PowerPoint, are you really, really sure it is possible? And is the field still green a year from now?
• Do you want to minimize the impact on system users, or is the move to something completely new and shiny your main selling point?
• How do you manage co-existence? Do you want to expose your users or customers to a co-existence, or should it be hidden in some way?
• Is the change and replacement triggered by changes to the physical environments? e.g. are you moving offices, data centres or similar? Does this give you some oportunities for renewal and actual greenfield approach that you shouldn’t miss out on?
• Do you need back-up and roll-back options, reconcilliation and parallell runs to verifiy outcome etc?
• How is the organization impacted? Is there a need for major changes to competence profiles; are cultural aspects an elephant in the room? How do you build ownership to «the new stuff», while «the old stuff» (and the co-existence) remains business critical for years and has to be properly managed?

…and perhaps the most important… since you are a bright and shining example of perfection and followed rule #1 – have you found a clever way of combining the need for a stepwise implementation with the need for an overall strategy on how to identify the right steps and how to order them? i.e. – do you have a migration strategy or just a first step?

^*) Oh yeah. The reason I am saying that «migration strategy» is not a good term, is because people usually start discussing staging environments and data mapping, and – understandably – think it is way, way to early to start designing that during project initiation…