Today was a looooong day with all day phone calls between stakeholders in this WAS migration project. Addressing communication gaps, the objective of an initiative that takes a program level look at migrating several enterprise applications, questions on why the methodology used will be appropriate to judge the migration effort, and so on and so forth.

There are several things to consider when migrating applications to another platform as a single initiative. Some I have listed in my blogs Migrating between App Server Versions and App Server Migration for Enterprise Applications. Besides the common problems, here are some that are a result of "finding the right hammer for many similar, but not same nails:"

• Applications have varying levels of complexity, and it is hard to apply the same methodology for migration to each of them
• Application teams have differing levels of expertise, and so where the benefits of a structured migration are seen by some, the same is not true for others
• In order to define a structured path for migration of multiple enterprise applications, often you have to take the least common denominator for defining the move. In other words, all the application may not see the same benefit in the migration. Some may be in a better position to leverage the target platform's capabilities than others

Given this, some of the stakeholders will unndoubtedly question the benefit of doing the migration at a program level. A common migration program limits applications' ability to maximally leverage the features that are offered by the new platform. After all, a migration is a tech initiative. And it should try to take advantage of the features offered by the new platform/OS/software platform. Why not roll in  an uplift of the application into the migration?

This is defintely a good thought. But it needs further diagnosis. If yours is the  only application that is in context for the migration, then it is feasible to redesign and focus on a singular migration, including an architecture and redesign.  However, when several enterprise applications are bundled into the migration, if redesign of each and every application is considered, the initiative becomes overly complex and unmanageable.

So the question arises - what is the benefit of a program level migration? Well, there are several benefits, even necessities of doing business that amost mandate planning at a program level:

• If the effort is limited to a pure migration, the methodology and steps can be fairly well documented, with little room for variation or error.
• As a result of this, the confidence level in any budgetary, time, and resource estimates should have a low variance.
• One hard fact is that the business benefits of the migration will not be immediately apparent. If you are trying to justify to business the cost of migration, it usually ends up being a lost cause. This is always a tech initiative. Most often it is out of necessity - to avoid obsolescence, or a cost benefit that can be amortized over the next few years. But hardly any organization will undertake a migration of several of its applications to provide increased functionality to its business users. Unless the existing platform has severe problems in supporting the existing application.
• So the choice is to do the migrate as soon as possible, with the lowest cost, and the least variance in estimates. Or to find business functionality that you can add to the plain vanilla migration in order to please the business users. I'd choose the first, which is an option with mitigated risk. The benefit is - get done with it - and then go on living in the new environment.
• After a plain vanilla migration, the skillset of all the teams will be at a level where they can leverage the benefits of the new platform. Actually leveraging the new features should be a subsequent and  incremental step. Roll in enhancements and new functionality gradually.

But it is hard to justify this to teams that have already done soul searching and determined how they can benefit form an unlift vs. a pure migration. The decision is one that the management and business users need to take - do a one-off migration to save re-architecture later, or be a part of an overall plain vanilla migration initiative - and uplift the application after the fact.