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.A STARTER STRATEGY - JUST TRY IT!
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.
A HIGH-LEVEL STRATEGY
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.
