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:
- Development Environment
- Runtime Environment
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 changes.
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
- Automatic migration
WebSphere Application Server provides migration tooling as part of the product. This can copy the WAS configuration from a previous release (say v6.1) and import it directly into the current release (say v8)
This is particularly useful if you are not 100% sure of the current configuration (you may have had configuration drift over time, or may be not particularly well-documented deployments). Naturally to do this, the application should have already been tested on the current release.
Personally, whilst IBM provides this capability and I know of customers who have successfully used it, I still prefer the manual migration, for reasons I'll articulate below
- Manual migration
What is the manual migration? It's not very exciting. It's building a new environment from scratch.
Why do I prefer it? Well, I would recommend that an environment configuration and application deployment is fully automated through scripting. Therefore, it would be better to upgrade and test the scripts and rely on them to build the new environment.
This ensures that you are using the recent enhancements in the product (some of the migrated configurations may use deprecated or older WAS features - an example of this was when the web container moved to non-blocking I/O, but a migrated config would continue to use the old web container technology). It also ensures that you can build a new environment when you need to in the cases of DR, or needing to scale for example
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:
- Update IBM HTTP Server and the WebSphere plugin first. The latest release can route to the current and previous versions of WAS
- Update the Deployment Manager. The DM should always be at the highest version used in the cell
- Update the Nodes one at a time by stopping all processes on the node and then using the migration tools.
At a given time, the WAS cell will have the current release and the previous release in the same cell. I would advocate that this mixed-version cell should only be used for migration on not for the ongoing state of a WAS environment - it just adds unnecessary complexity.
In terms of my preference, the manual migration, you can take a similar approach to the above, starting with the web server upgrade. However the next step would be to bring a new WAS Deployment Manager online at the current release and configure it. Then the step to update the nodes is more of a scenario to take the old node offline and introduce a new node in the new cell. You'll have noticed that you have 2 cells on the go here, so will need to merge the plugins from the 2 cells to continue to use the IHS instances across both cells.
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