The six blind men* who attempted to describe the elephant eventually described it only from their perspectives - the parts and not the whole. The same malady can be found lurking in one of the problems that faces many organizations that have adopted J2EE as their platform of choice: the migration of these applications between J2EE application servers - be it vendors or versions. The number of migration initiatives that have come up in the past few years is substantial. 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.
• The number of mainstream app server vendors has died down from a few tens to single digit numbers within the short span of a couple of years.
• Since the platform on which the core product is written has moved on, there is no choice but to move. Often the support for an 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. So migration can involve one or many of several dimensions - versions, vendors, operating systems, hardware, related third-party vendors, etc.

For most organizations already using a J2EE application server, the upgrade to another version is not difficult, if planned properly. However, the complete migration of several enterprise applications is not trivial. Therefore, it's critical that adequate planning be done in advance so that the external factors (besides code migration) have minimal impact on the actual upgrade. The strategy and planning for such initiatives is very complex. The complexity is multiplied due to the number and profiles of stakeholders in the equation. People tend to view migration from a narrow perspective due to the limited visibility each individual has into the entire process. There are several stakeholders involved in such migration initiatives, including:

• Developers who think of migration in terms of the application code changes
• Administrators who think of migration in terms of production runtime
• Product architects who think of migration in terms of the impact on design and product features as well as the product roadmap
• Development managers who think of migration in terms of the resources available, existing deadlines, etc.
• Technical support and services who think of migration in terms of the infrastructure and capacity planning
• Executive management who think of migration in terms the cost, the risk, and the impact on the LOB (Lines of Business)

A typical migration requirement that is prevalent in the industry today is migration from IBM WAS 3.5 to WAS 5.0. This is not unexpected. IBM has finally caught up with the latest version of the J2EE platform, but they took their time doing it. IBM's support for EJB 2.0 came nearly a year after competing vendors, such as BEA, had provided the same. From a technology viewpoint, a migration from 3.5 to 5.x involves code migration, application redesign, total repackaging for deployment, and 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 migrating 20-50 enterprise applications becomes very formidable.

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 feed 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

IBM provides a Redbook that serves as a "how-to" guide for such a migration (publib-b.boulder.ibm.com/Redbooks.nsf/RedbookAbstracts/sg246910.html). However, the other aspects of migration, such as the ones mentioned earlier, cannot be covered in a generic migration guidebook. Someone has to define application characteristics, dependencies, etc., and define a viable strategy for the migration of each application, as well the migration of all the applications in a fixed time frame. Then a team needs to manage the migration to ensure it's 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.

To do this in a planned fashion, the best recourse is to engage a team that works solely on this planning initiative, across the applications in the scope of the migration. Such a team needs to operate outside all the applications and deliver an analysis that addresses the needs of each application. This is your seventh (seeing) "man" who can paint the true picture of the elephant.

*THE AMERICAN POET JOHN GODFREY SAXE BASED HIS POEM, "THE BLIND MEN AND THE ELEPHANT" (WWW.WORDFOCUS.COM/WORD-ACT-BLINDMEN.HTML) ON A FABLE THAT WAS TOLD IN INDIA MANY YEARS AGO.