Friday, August 13, 2010

Prototypical Migration Goals

The primary purpose of a migration plan is to successfully introduce the new system as seamlessly as possible. Simple migrations can easily accomplish this, but IT transformation migrations require a more structured approach that can accommodate the inherent complexity and extended timelines involved. Migration is sure to drive transformation tasks and deliverables that need to be planned from the start; so defining the migration process once you’re well into the transformation execution is a little too late. A transformation initiative should be planned with migration in mind as early as feasible. Depending upon the nature of your transformation initiative (is it an evolutionary change or a revolutionary scrap-and-replace effort?), you will need to approach migration with a clear set of goals. Typically, the migration goals you’ll need to weigh represent a cost and focus compromise between the following objectives:
Value Acceleration. The migration should provide benefit early on.  One of the main reasons for the failure of a transformation project is extended delivery timeframes that expose it to the loss of support from new executive teams or built-up financial pressures that lower its priority. When building a cruise liner, one doesn’t attempt to sail it before it’s been completed. This is unlike IT Transformation. IT Transformation is more like a public works program were new infrastructure can gradually enable renovated sections. Waiting for the entire transformation initiative to complete before starting migration is unwise. Instead, you should endeavor to put into production the transformation elements that can deliver value as soon as feasible. When you do this you are providing life support to the transformation initiative.
Some might argue that this approach carries the risk of the company being tempted to halt the remainder of the transformation once a few of its main benefits are enjoyed. But, if management is going to stop a project they will stop it regardless. At least, by following this approach, the transformation will be viewed as having produced value. If the program is stopped under these conditions, you will be in a good position to defend the outcome.  Also, if the initial value represents a significant percentage of the total value of the transformation, then it actually makes sense to give the company a chance to amortize its investment.
A more serious argument against the approach of accelerated migrations is that most transformation initiatives require heavy work on revamped infrastructure before they are able to deliver actual user-perceived value.  This is a true conundrum and one that is very difficult to explain to business customers eagerly awaiting actual functionality. Again, it all goes back to how the project was planned and how well you segmented the various infrastructure deliverables to accomplish a quick return in value. Ideally, you should have segmented the transformation into sub-systems. The horizontal layers provided by the infrastructure should have been segmented along levels of service and functional subsets that can be scoped independently. For example, perhaps you can deliver those data analysis results sooner by relying on a simple data repository that does not have the entire resiliency in place.
In general, it’s best to avoid designing the program along the lines of first building the entire infrastructure and then delivering the applications. The end user does not care how nice the infrastructure is; only that the functionality and expected services are in place.
Non-disruptiveness.  Regardless, your migration effort should never impact on day to day business. You should focus on reducing risks and minimizing impact to business every step of the way. Furthermore, ensure that the migration meets the committed SLAs or you will be exposed to earning a bad reputation from the users. There is nothing worse than having a newly introduced piece of technology fail, causing the credibility of your entire program to suffer. It’s best to avoid “Big-Bang” migrations that require switching off the old system in order to introduce the new.  Through millions of years of evolution, nature has given us the best example of a proper migration plan with the way a caterpillar transforms into a butterfly.
Efficiency and Cost Effectiveness. The migration effort must not force excessive use of resources, whether human or material. Also, a migration effort that’s too expensive is not going to be well received; so you should endeavor to reuse as much of the existing capabilities as possible. Remember, most of the tools and resources needed for migration will usually only be used once.  Migration effort is one of those cases where it makes sense to tap into external resources on an outsourcing basis. Finally, don’t forget to make the required training a core part of the migration plan.
Timeliness. Having expressed an opinion that, if possible, migration should take place sooner, let’s not speed migration for simple political expediency. A migration has to be done in accordance with an overall timeline that properly balances the risks, the benefits, and the application of resources. Migrate too soon, before the system is placed into operation, and you are going to have a recipe for failure. Migrate too late and you’re going to face a situation where any room for failure is effectively shut down
Avoid expedited migrations just to meet a deadline or for purely PR reasons. It’s not worth it.  Migration for migration’s sake is going to leave your executive sponsors and the business people scratching their heads. Then, there are times when migration must take place at a purely infrastructure level in a way that will not be apparent to the end users. When doing so I recommend keeping the PR at a minimum. The last thing you need is a disappointed sponsor wondering what all the brouhaha was about. Think about it, when was the last time your municipal government bragged about replacing those sewage lines?
The key thing to remember here is that migration timelines, the way you manage the expectations for each migration step, and the degree of exposure you apply (PR) must align with the business requirements in order to be effective milestones in accomplishing transformation goals. Accomplishing this requires defining a migration strategy that includes the tenets and principles to be observed.  More on this, next week. .  .