Subscribe to WebSphere: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get WebSphere: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

IBM WebSphere software products Authors: Liz McMillan, Pat Romanski, Yeshim Deniz, hyper filter, Timothée Bensimon

Related Topics: Java EE Journal, Prolifics Technology Journal, WebSphere

J2EE Journal: Article

Migration: From Here to There to WebSphere

Migrating to Websphere v5 from earlier versions and from other J2EE application servers

Why migrate to WebSphere v5? Whether you are currently using WebSphere v3.5 or v4, or are using a different J2EE application server altogether, there are many reasons that justify the move.

First there is the corporate choice - when choosing WebSphere you are choosing IBM. This means that you benefit from their reputation for superior support and their rather vast portfolio of software options. You also benefit from the level of investment they are putting into WebSphere, which equals more than the annual revenues of some of their competitors.

Next there is the technology choice. Certainly, by moving to the latest and greatest, you can take advantage of all its advancements and new features, which should match your growing business and technical needs. Additionally, WebSphere probably averages out to a lower cost of ownership than most of its competitors. Compared to similarly priced options such as WebLogic, it offers lower software pricing, and more dramatically, it offers lower maintenance costs. Compared to the freeware or shareware market, WebSphere has a more expensive purchase price, but with all its complementary tooling it actually incurs lower development and deployment costs and provides easier extensions to portals and pervasive devices, as well as offering more reliable support.

Finally, there are the business implications. End-of-support dates or end-of-life dates are significant driving factors for any company running critical business systems - support for WebSphere v3.5 ended in November 2003, and support for WebSphere v4 will end in September 2004. In fact, even if you are on a different J2EE application server such as iPlanet, WebLogic, or Oracle AS, an end-of-support date may be the prime time to make the move to WebSphere instead of performing a version upgrade, due to the similar levels of effort. You may think that your application is running fine, so why change? Well, you don't want to be held back, prevented from upgrading your hardware or buying new software products because they aren't supported by earlier versions of the application server.

Migration Strategy

Each migration has its own nuances, so we are not trying to detail a "walk-through" migration guide. After all there is no "one-size-fits-all" when it comes to migration. Instead, we are trying to give you some general information to guide you and help you get a feel for the effort.

First, go for it - take a few code samples and get them running in WebSphere v5. Second, see if your application will compile, build, and deploy to WebSphere out of the box. It won't - but you're on the right track. Third, add some method to the madness: devise a migration methodology and consult the best practices for migrating.

We have been refining our own methodology on migration for several of our customers. In this article we hope to share some of the expert advice that we have gathered along the way.

After many migrations we have come up with a list of steps that have proven to be very useful, no matter which application server you are migrating from. This list also considers that when we do a migration we usually deal with applications that have been in use for a while and that have been patched, fixed, and updated. Many developers have had their hands on the code, documenting it or not, so over time the application's code documentation has become outdated. This means that when we migrate an application we also have the chance to take care of all of this.

1.  Verify baseline: Confirm the application behavior on the original system (prevent the addressing of migration problems that never existed in the first place). A benefit, this also progressively builds the future documentation of the system.

2.  Stage source code: Take a snapshot of the current production code - version control your code base.

3.  Import source code: WebSphere Studio Application Developer v5 provides ready templates for the J2EE 1.2 and J2EE 1.3 project structure. We find it beneficial to use WebSphere Studio Application Developer v5 as early as possible in the migration steps.

4.  Correct compilation errors: Based on the imported source code WebSphere Studio Application Developer v5 creates an analysis report on the fly (Task List) listing the Java compilation errors, problems in the Web layer of the application, and missing J2EE 1.3 or J2EE 1.2 requirements. (This includes JSPs and HTML pages.)

5.  Complete deployment descriptors: WebSphere Studio Application Developer v5 plays an active role in this part and provides the developer with deployment descriptor editors and wizards to ensure J2EE-compliant applications.

6.  Test and debug: Prepare the WebSphere Studio Application Developer v5 internal WebSphere Application Server v5 Test environment, including data source setup. Conduct a full application test to determine eventual runtime errors as well as database connectivity problems. These are steps that must be completed before deploying an application EAR file into a QA environment. Make full use of WebSphere Studio Application Developer test environment and debugging capabilities.

7.  Deployment strategy: Use WebSphere Studio ANT support to create a deployment EAR file for testing in a WebSphere QA architecture.

Migration Tooling

We recommended WebSphere Studio Application Developer as your primary migration tool, but here is a list of other WebSphere migration tools. Note that most of the functionality in these tools is already embedded in WebSphere Studio Application Developer.


  • WASPreUpgrade: To save the configuration from a prior version of WebSphere Application Server
  • WASPostUpgrade: To convert the configuration saved by WASPreUpgrade into a WebSphere Application Server v4 configuration and application migration
  • ClientUpgrade: For upgrade of J2EE client JARs (primarily a v4-to-v5 tool)
  • WASPreUpgrade: To save the configuration from a prior version of WebSphere Application Server
  • WASPostUpgrade: To convert the configuration saved by WASPreUpgrade into a WebSphere Application Server v5 configuration and application migration
  • MigrateWC: For JSP and servlet source code conversion
  • Ejbdeploy: For EJB 1.0-to-1.1 conversion
  • Earconvert: To convert a J2EE 1.2 EAR file to a J2EE 1.3 EAR file
  • mb2mdb: WebSphere Enterprise Edition 4.0 JMS listener application for using message-driven beans
  • CACT: Class API checker tool; checks for supported API levels in applications

Expert Advice on Migration from WebSphere v3.5 or v4 to WebSphere v5

If you are on WebSphere v3.5, and are deciding which WebSphere version to migrate to, we recommend the latest (currently v5.1). Table 1 shows new features in versions 4 and 5. You should migrate to version 4 only if third-party software used in your application is not supported by version 5 - otherwise you just end up with more work, time, and money spent. Table 2, which identifies the key factors involved in different migrations, demonstrates that migrating from version 3.5 includes much the same factors, whether you're migrating to version 4 or version 5.

If you are on WebSphere v4, the migration to version 5 is even easier because version 4 applications are using the J2EE packaging structure. Remember, WebSphere v5 is backwards-compatible, so you can already run your version 4 application in a WebSphere v5 environment (using WebSphere v4 data sources).

One of the most important differences between WebSphere v3.5 and later versions of WebSphere is J2EE compliance. Figures 1 and 2 show the difference between WebSphere v3.5 application packaging and the J2EE-compliant WebSphere v4 and WebSphere v5 application packaging. Based on these figures you can see how we have to package the applications to comply with the J2EE standard.

We need to adapt the EAR file for the deployment environment (see Figures 3 and 4 for the architecture comparison). Note that in Figure 3 the servlet engine is a Web container, but since WebSphere v3.5 did not really support the concept of a WAR file, we refer to it as a servlet engine.

Expert Advice on Migration from Another J2EE Application Server to WebSphere

In an application server migration you need to move not only the application and its code to the target environment, but also the developers, users, third-party software components, and systems. As part of the migration effort it is important to allocate time for testing the application's integration with other software. Additionally, we recommend that you invest in some training and mentoring of the new environment for your development team so that they are best equipped to maintain the application.

If your organization is an ISV that sells a solution in the marketplace you may need your application to run in multiple application server environments for greater market reach, yet maintain a common code base and elaborate build processes. Prolifics has done this for several customers.

Often in an application server migration organizations choose to perform a proof of concept in which they conduct a sample migration. The migration is conducted on an identified representative vertical slice of the existing application that exercises the application's core features and functionality. The experience gained in packaging, building, and deploying this is also useful for teams outside of development.

A migration is a project. The same principles that apply to any IT project apply to a migration, so consider iterative cycles (including testing) and risk mitigation. Watch out for scope and, more commonly, scope creep. For example, if you migrate the application server, migrate the DBMS, migrate your messaging platform, touch up the code, and upgrade the operating system all in one go, then plan on a very cautious integration effort. We recommend proceeding with no more than one product change per development iteration.

Finally, consider involving a migration expert to conduct an application review with a seasoned eye for potential code issues, and have him/her advise the migration team, or even execute the work.

The first step during the application migration is to determine what J2EE versions you are using today and what the target version will be in your WebSphere target platform (see Table 3). Then compare and contrast the different API versions (e.g., EJB, servlet, JSP, etc.) to plan out the areas to focus on during the migration.

In addition, you should analyze the application to determine which code violates or loosely interprets the J2EE standards. This code may not seamlessly migrate over to the new environment. We detail a common example of J2EE noncompliance in the accompanying sidebar.

Type narrowing with PortableRemoteObject is often not implemented to specification in some application servers. The EJB 1.1 specification states that all client-side representations of an EJB's Home and Remote interfaces must be narrowed. This includes beans referenced by JNDI, those created by the home interface, references returned by finder methods, and references returned from one bean to another.

As part of the analysis process, it is also quite valuable to identify proprietary components specific to the application server, or home-grown middleware modules. These will also require dedicated attention during the migration strategy. Table 4 details an example of proprietary components included in WebLogic.

Next Steps

Whether you go the do-it-yourself route or use expert outside assistance, we recommend that you follow these next steps for your migration.

1.  Assessment: It is always important to assess and plan for the overall migration effort, as well as understand the skills development necessary for adapting to the new environment. During this phase you will analyze existing applications and code, and create a comprehensive plan for efficiently making the move. The assessment can also be a valuable tool to confirm overall costs in an effort to study the total cost of ownership and return on investment involved in a move.

2.  Proof of concept: This is more applicable during an application server migration, and goes a long way toward confirming costs and mitigating any concerns you have regarding the risk.

3.  Migration:
-Consider outsourcing. A migration effort is really a one-time-only effort. Rather than utilizing your staff on this effort and building up skills they will never require again, deploy them to strategic projects where it is essential to use developers who know your business. By leveraging expert consultants with previous expertise, you gain from their tips, tricks, and tools that expedite the process, reducing overall costs.

-Do it yourself. There are several do-it-yourself resources and books that can make this a smoother process. Consider finding a mentor with experience in this area so that you benefit from his or her accumulated knowledge.

4.  Skills development: When moving from one environment to another you will need to arm your development team with the skills to maintain the system. Dedicate training time for the new environment and the new tooling.

More Stories By Max King

Max King, based in Prolifics' London office, has extensive experience delivering WebSphere solutions for clients worldwide, including JP Morgan Chase, NYSE, Wal-Mart, Lufthansa, BNP Paribas, MetLife, Honda, and Hertz. As a senior member of the Prolifics WebSphere Consulting Division, he specializes in J2EE architecture and best practices, application development and deployment, production 'crit-sit' support, production readiness assessments, application migration, and messaging and integration.

More Stories By Juergen Efeish

Juergen Efeish, based in Prolifics’ NewYork office, is a senior member of Prolifics’ specialized WebSphere Consulting Division – a team that IBM calls on to solve the toughest of their customers' challenges and deliver training, mentoring, and development services. He has extensive experience delivering WebSphere solutions for clients worldwide, including the Federal Reserve Bank, Verizon, National Healthcare Group – Singapore, AT&T, Ernst &Young, JP Morgan Chase, BMW, and Avaya

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.