How easy is it to migrate to WebSphere vX
JonMarshall 1000009QM4 Visits (3827)
I often get ask about how to do WebSphere Application Server migrations.
This is something that WebSphere now provides really excellent support for. There is loads of good documentation for it now (I provide my favourite links at the bottom) and even the InfoCenter provides an excellent starting place.
I always break migrations down into 3 different areas:
In my view, application migration has become increasingly straightforward over recent years. This is primarily as a result of the stabilisation of the Java Enterprise Edition standards, particularly the web standards of servlet/JSP. Java Enterprise Edition provides a level of backward compatibility explicitly in the specification. However, WebSphere Application Server goes beyond that. For example, the latest release of WebSphere Application Server version 8 provides backward compatibility all the way to J2EE 1.2 (the specification implemented by WAS v4!)
What does this mean? Well, you should be able to take your J2EE application from 1.2 onwards and run it seamlessly on WAS v8.
What's the reality? Where applications have adhered well to the specifications then this typically works quite well. We'd naturally always advocate full testing of the application. However, if you consider some of the older applications (say J2EE 1.2, 1.3), developers would often make use of 3rd party libraries or sometimes "break the rules" by coding to vendor-specific APIs or non-public APIs. Often this was because the J2EE specifications didn't provide such complete functionality as they do today (or because EJB was a bit of a pig to code with prior to JEE 5). Regardless of the reasons, this bespoke coding and libraries can often be the hardest bit to migrate. So as part of any migration assessment, I'd recommend checking out that kind of aspect to an application.
For that reason also, I recommend that when migrating an application, do consider putting in the time to "modernise" the application, bringing it up to date in terms of the latest specifications.
IBM provides a free tool, the application migration toolkit (link below), where an initial sanity check can be performed on the application prior to running it on the latest version. It will check for violations of the spec and recommend chan
The "development environment" is an increasingly diverse environment, with many developers customising their workstation to their working preferences.
From an IBM perspective, we would recommend Rational Application Developer (either the full product or Standard Edition), is this provides the most comprehensive WebSphere development environment. In the context of migration, the benefit of using RAD is that it comes with migration tools to update your current RAD workshop and the application to the latest level. It has support for a range of versions of WAS test environments allowing you to test against the old and the current version at the same time. The only other considerations when migrating RAD environments is that your environment (source code repositories, 3rd party plugins) to support the latest release.
If you're running an open source Eclipse environment, then you are likely already on a current release of the web tools project and 3rd party plugins. If not, this is the time to upgrade, so you can support the latest Java EE specification levels.
Something you may not be aware of is that IBM recently released free Eclipse tools in the Eclipse market place (called the Developer Tools for Eclipse) that provide operational control of WAS, and editing of the deployment descriptors for WAS. This provides a zero acquisition cost development option for WAS with Eclipse, the Eclipse Developer Tools and WebSphere Application Server for Developers.
When performing the migration, there are 2 approaches I consider
When migrating the runtime environment, I always ask the question of what availability you need during the migration, because this likely directs some of the migration decisions.
If you cannot have any outage and need to run at 100% capacity throughout the migration, you may need to consider building a duplicate environment.
If you cannot have an outage, but are able to run at a lower capacity for a period, there may be an option to do a phased migration (migrate node by node)
If you can have an outage, you are free to do whatever is easiest!
Let's briefly discuss the phased migration to express what I mean. WebSphere Application Server Network Deployment supports the notion of having mixed-version cells, that is nodes from various versions of WAS in the same cell.
This provides the support needed in the automatic migration to do a phased migration, 1 node at a time. The order of the migration is important here and must be performed as:
This approach gives more control over the migration and gives a more robust rollback if you need it (although a decent backup will of course have been taken).
I would value your comments as to your experiences in this area