If you do a search for "migrating J2EE application servers" on the de facto "re"search engine - Google - here are some of the results you'll get from your query:

• Migrating J2EE applications from Borland JBuilder to IBM WebSphere
• Migrating J2EE applications from WebLogic to WebSphere application server
• Migrating J2EE applications from earlier versions of the application server and from other application server platforms to Sun ONE application servers
• Migrating your J2EE applications to JBoss
• BEA WebLogic to JBoss migration program

When I first got involved in the planning for a project that involved the migration of applications between versions of IBM's WebSphere product, I naively thought - "This can't be that big a deal. After all it's just different versions of the application server. And the changes in the Java platforms between WebSphere versions is well documented. In fact, IBM even provides a Redbook to do the migration..."

I couldn't have been more mistaken. The migration was a big deal. After working on a few of these projects, I can verify that the amount of moving parts in a machine composed of various portfolios, frameworks, third-party vendors, and a variety of stakeholders made the planning for such an initiative a formidable undertaking.

This article covers the aspects of enterprise application migration that involve J2EE application servers, including the motivation, methodology, challenges, and the way to successfully undertake such an initiative. The focus is primarily on the migration of a large portfolio of applications, not individual applications. This article doesn't get into the basics of application server technologies, Java technologies, etc.; I feel it will be of most interest to architects, team leads, and technical project managers.

What's the Big Deal About Enterprise Applications?
Many of you have probably migrated applications between versions, hardware and software platforms, etc. The magnitude of the problem increases logarithmically with the number of applications, especially when they are spread across a number of business portfolios. When we're considering applications in the J2EE context, enterprise applications typically pose the following challenges:

• The applications are distributed across different tiers - client, business, and database - and they use a different mix of J2EE technologies, including JSPs, servlets, EJBs, JDBC, etc. The versions of the APIs used across the applications are usually not uniform, since they may have been developed at different times.
• The integration requirements of each application may be unique. For example, some applications may require integration with an existing security framework that provides single sign-on. Others may require integration with third-party packaged products.
• Besides the Java platform APIs, the applications probably use other technology components or frameworks that were developed in your organization for Java applications. These may include messaging frameworks, utilities for logging, exception handling, etc. The dependency of applications on such components adds another level of complexity to the migration effort.
• Applications have varying levels of complexity, and it's hard to apply the same methodology for migration to each of them.
• Application teams have differing levels of expertise, so where the benefits of a structured migration are seen by some, the same is not true for others.

Why Migrate?
Chances are that all your enterprise applications have already been in place for a while and have been working satisfactorily. If such is the case, why migrate? After all, you could continue to support your applications on existing versions of the application server.

There are many factors that could have led your organization to consider the migration of applications. One of the main reasons why a migration takes place across the entire organization is because support for the existing version of the application server is being phased out. In such cases, the organization has no choice but to move all the applications to a version that will be supported by the vendor in the future. A typical case is that of IBM WebSphere. IBM plans to phase out version 3.5 of its application server this year. This has led to the mass migration of applications that are housed in 3.5 to the latest version (5.1).

Another reason why organizations end up considering a large scale migration of their J2EE applications is that vendors offer competitive rates/incentives. A typical case is that of Sun offering lucrative pricing on their Sun ONE server to entice organizations into migrating their applications. Another example is that of JBoss. Since this offers the most cost-effective solution, some organizations are considering migrating their J2EE applications to JBoss. For some organizations, it's a matter of consolidating their investment on a standard enterprise platform.

Other reasons include a shift in programming paradigms. Some organizations have recently adopted component-based applications and see a migration to an application server as the natural step to achieve this. Others have realized that departmental applications they have developed cannot scale to an enterprise level. However, in these cases, the effort involved is more along the lines of a rewrite rather than a migration.

I Thought Standardization on J2EE Took Care of Everything
The application server market continues to evolve. Migration is not only about moving non-J2EE applications toward the J2EE standard. Very often, there is a requirement to migrate J2EE applications between application servers. Given J2EE's promise of interoperability, migrating enterprise applications between app servers seems to be more complicated than it should be. This is because application server vendors typically provide extensions to the J2EE platform APIs in order to differentiate their product. In most cases, these extensions were necessary because the performance and rapid development features offered by pure J2EE APIs left much to be desired. For example, when the EJB model was first introduced, it was not usable for enterprise scale applications. It was only in EJB 2.0 that local interfaces were introduced. In the meantime, app server vendors had introduced their own optimizations to address the issues of performance and scalability. When migrating between application servers, the usage of the proprietary extensions adds to the complexity of migration. However, not using the extensions was not the best possible course either, when the applications were originally developed.

Although migration is not only about moving to the J2EE standard, one of the main outcomes of the migration is the move to a standardized platform. This is the case whether the migration is between application server versions, between vendors' products, or between hardware and OS platforms. Figure 1 gives an example of the transition in the case of a migration from earlier versions of IBM WebSphere application server to version 5.1. As shown in the figure, the final state of migration leads to a standardized state of J2EE APIs, IDEs, databases, hardware, etc.

How to Plan for an Enterprise-Level Migration
Enterprise application migration requires careful and detailed planning. In a large organization, at the onset of such an initiative, the planning should be managed in independent tracks that tackle different dimensions of the migration. Figure 2 illustrates the phases and tracks in the planning phase of an enterprise-level migration. As illustrated, these tracks are executed over a number of phases. In the project inception phase, a core migration team should be formed to conduct the migration assessment. As a part of this phase, the team should come up with an initial project plan for the planning phase, determine the methodology and means to communicate with the application teams, identify the key stakeholders, etc. The information gathering phase involves interaction with the various application teams to gather the characteristics of each application. These characteristics include technical parameters such as the number and versions of JSPs/servlets/EJBs, integration requirements, etc., as well as information about releases, schedules, and dependencies between applications and application portfolios.

• Figure 1
• Figure 2