IBM WebSphere MQ migration
Migration is the conversion of programs and data to work with a new code level of IBM® WebSphere® MQ. Some types of migration are required, and some are optional. Queue manager migration is never required after applying a maintenance level update, that does not change the command level. Some types of migration are automatic, and some are manual. Queue manager migration is typically automatic and required after releases and manual and optional after a maintenance level upgrade that introduces a new function. Application migration is typically manual and optional.
Whenever you upgrade IBM WebSphere MQ to a new release that changes its command level, migration is performed by the queue manager. Whenever you upgrade IBM WebSphere MQ to a new maintenance or fix level, which introduces a new function using a new command level, you can migrate the queue manager to use the new command level and thereby the new function.
You must read Changes that affect migration before upgrading your IBM WebSphere MQ installation or migrating your queue managers, to identify what migration tasks you must plan for.
Using the model in Figure 1 you can distinguish different migration questions, which are discussed in the following topics:
- Operating environment migration
- Upgrading the operating environment, or components in the environment such as installing a new level of JRE; see IBM WebSphere MQ operating environment migration
- Queue manager migration
- Migrating a queue manager following an upgrade of the IBM WebSphere MQ installation to a new command level; see Queue manager migration.
- IBM WebSphere MQ MQI client migration
- Migrating a client configuration following installation of a new version or release of the IBM WebSphere MQ MQI client; see IBM WebSphere MQ MQI client migration.
- Application migration
- Relinking, recompiling, or recoding an IBM WebSphere MQ server or client application; see Application migration and interoperation. Application migration also includes migrating any API or channel exits
In addition, you must consider the impact of migrating one queue manager, or WebSphere MQ MQI client, on other clients or queue managers:
- Compatibility, coexistence, and interoperability
- See Coexistence, compatibility, and interoperability for information about the compatibility of IBM WebSphere MQ applications connected to queue managers and IBM WebSphere MQ MQI clients on different command levels. The section also explains the concept of queue manager coexistence, and the interoperability of IBM WebSphere MQ JMS applications with WebSphere Application Server.
- Queue manager clusters
- Can a queue manager cluster contain queue managers at different command levels? See Queue manager cluster migration to answer this question, and how to migrate a cluster of queue managers.
- High-availability clusters
- How do you migrate queue managers that are part of a high-availability cluster to a new command level, and maintain continuous and reliable service? See Migrate a queue manager in a high availability configuration, which covers both migration of multi-instance queue managers, and the migration of queue managers operating in high-availability clusters.
The remaining migration topics describe migration from other products or IBM WebSphere MQ features, to being part of a queue manager.
- IBM WebSphere MQ publish/Subscribe broker
- The version 6 publish/subscribe broker was separate from the queue manager. It used command messages to create and control publications and subscriptions. In migrating it to version 7, and integrating it with the queue manager, two major changes were introduced. The configuration and administration of publish/subscribe changed, and a new programming interfaced was introduced, integrated with the MQI. The first change requires any installation that used the version 6 publish/subscribe broker to run a migration command, strmqbrk. The second change is optional. You can modify existing or write new publish/subscribe programs to use the new programming interface. The changes are described in Publish/Subscribe migration from Version 6.0.
- WebSphere Message Broker and WebSphere Event Broker Publish/Subscribe migration
- The publish/subscribe broker in WebSphere Message Broker version 6.0 and 6.1, is replaced by using IBM WebSphere MQ as the publish/subscribe broker. WebSphere Event Broker version 6.0 is replaced by IBM WebSphere MQ. See WebSphere Event Broker and WebSphere Message Broker migration tasks.
- WebSphere Message Broker SCADA migration to WebSphere MQ Telemetry
- The SCADA nodes in WebSphere Message Broker version 6.0 are no longer supported in version 7.0. You can migrate your SCADA applications to use a combination of WebSphere Message Broker version 7.0 and WebSphere MQ Telemetry; see Telemetry migration from WebSphere Message Broker.
IBM WebSphere MQ migration concepts
Figure 1 shows two runtime operating
system environments. One environment is called Server
, and contains an IBM WebSphere MQ server and server application. The other is
called Client
, and contains an IBM WebSphere MQ MQI client application. The server environment has
one or more queue managers represented by QM
using the installation of IBM WebSphere MQ installed on the server.
The queue manager labeled QM-n?
coexists on the same server as
QM
, but runs at a different release level. Multiple releases of IBM WebSphere MQ installed in the same operating environment
are called coexistent1. The IBM WebSphere MQ
installations for different release levels are not shown. The question-mark in the queue manager name
indicates this capability might not be present in your environment.
- It can be used to reduce the risk involved in migrating to a new command level, and reduce the downtime during the migration process.
- You must consider any configuration implications of running some applications or clusters on the same server with queue managers at different command levels.
The
queue manager, QM*
, represents queue managers of
various levels installed on other servers.