At Infosys, this is the second assignment that I have been involved in regarding a migration of enterprise applications between app server versions (IBM WAS 3.5 to 5.x). The strategy and planning for such initiatives is very complex and requires planning in advance. The number of migration initiatives that have come up in the last few years is formidable. There are several reasons for this:

• Java, as ever, is rapidly evolving

• Although the splitting of Java into three platforms (J2EE/J2ME/J2SE) happened a few years ago, it took a while for the app servers to catch up and provide the necessary support

• Enterprise applications, once deployed, have a multitude of dependencies, besides the dependency on purely Java. In fact, the dependency on Java is often a small part of the big equation. There is the corporate agenda, budget allocated, and of course, existing LOBs (Lines of Business) that get impacted by the move. However, since the platform on which the core product is written has moved on, there is no choice but to move. Often the support for existing version is cut off.

• The drivers for migration are not merely limited to app server vendors and software. Many companies are recognizing the need to shift to open source and Linux platforms as a more viable alternative

A typical migration requirement that I have seen is migration from IBM WAS 3.5 to WAS 5.0. And this is not unexpected. IBM has finally caught up with the latest version of the J2EE platform, but they took their own time doing it. IBM's support for EJB 2.0 came nearly 14 months after competing vendors, such as BEA had provided the same. And a migration from 3.5 to 5.x involves code migration, application redesign, total repackaging for deployment, migration of the entire development environment from VAJ to WSAD - just to name a few key factors. Add the integration with MQ at IBM clients, and throw mainframes into the mix, and the prospect of migration 20-50 enterprise applications is a very formidable undertaking.

The best way for companies to tackle this type of a tech initiative is to include a planning phase during which several aspects of migration are addressed, some of which are:

• Dependencies between applications - in order to bundle and sequence the applications to minimize disruptions

• Training, especially if the development team is shifting IDEs

• Shared code libraries - which feeds into the bundling

• Third party APIs that may have incompatibilities with the new version of the app server/Java platform

• Integration with in-house utilities

• etc.

IBM provides a RedBook that serves as a "How To" guide for such a migration. However, the other aspects of migration, such as the ones mentioned above cannot be covered in a generic migration guidebook. Someone has to gather the requirements, application characteristics, dependencies, etc. and define a viable strategy for the migration for each application. And then a team needs to program manage the migration to ensure it is done in the proposed manner. The dollars spent up front in such an effort are a fraction of the amount of money that will go down the drain if these parameters are not accounted for.