WebSphere Application Server *Formerly WebSphere MQ
& IBM MQ* Migration
There are many things to consider when planning a migration from prior versions, to more current versions.
There are multiple steps involved, which we would overview as below:
Typical Migrations & Upgrades Process
TxMQ Migration Roadmap
Customer migrations usually begin with an initial assessment and a discovery questionnaire, which we can send in advance, or walk through cooperatively, based on customer preference.
WebSphere Application Server Migrations & Upgrades
Information on WebSphere Application Server (WAS) Migrations & Upgrades
TxMQ offers to work with our customers through IBM’s WebSphere Migration Toolkit. This is a set of tools that helps us with some critical components of the migration itself.
We work with our customers to identify the Java EE technologies used by their platform. Are there deprecated Java EE technologies? Will some/all/none of the applications run in cloud environments? What changes to applications will be needed for successful migration (if any). In truth, we spend a fair amount of time focusing on Java applications.
There are quick initial detailed analysis snapshots available using the binary scanner command line tool. This is ideal for quick evaluation, developers not using Eclipse based IDEs, and access to overview for any possible migration issues.
As of April 30th, 2018 the following WebSphere Application Server versions will go out of support:
>> WAS v.7 all editions & WAS v.8 all editions
If you’re currently running a soon-to-be outdated version of WAS, reach out to us to speak to an expert on your migration, upgrade, and back-level support options.
MQ Migrations & Upgrades
Key Message Queue (MQ) Definitions.
There are a few key definitions in the MQ world. Maintenance, upgrade and migration are distinct, and easy to define.
Maintenance is the application of a fix pack, interim fix or Program Temporary Fix (PTF).
It has one main characteristic. Those fixes, whether applied using a maintenance installation tool, or installed using a manufacturing refresh on top of an installation, are at the same command level as the existing code. No migration is required after applying maintenance. The installation can be restored to its previous level and any changed queue managers or applications will continue to work at the restored code level.
However you must still test applications using the new level of MQ code.
Upgrading is the process of taking an existing IBM MQ installation and upgrading to a new level of code. Unless you are upgrading the fix level of IBM MQ, but not its command level, an upgrade must be followed by migration.
Upgrades can be backed out, as long as no migration has taken place. The process of removing an upgrade varies by platform and how the upgrade was applied. Upgrades that change the command level of IBM MQ require queue manager migration before applications can reconnect.
Migration is where one updates the queue manager data to match a newer level of code. This occurs the first time a queue manager is started with the newer level of code.
Migration always follows an upgrade that changes the queue manager command level, both automatic and manual. Migration is the transformation of queue manager data, applications, and the environment that the queue manager runs in.
Once migration has occurred, the queue manager can no longer be started by an earlier code level. On most platforms, queue manager migration is not reversible.
- Distributed, IBM i, Migration cannot be reversed. This restriction applies whether your enterprise uses the Long Term Service Release (LTSR) or Continuous Delivery Release (CDR) model.
- From IBM MQ for z/OS® Version 9.0, you can backwards migrate queue managers only if you are using the LTSR. See IBM MQ release types for further information.