IBM MQ migration

Migration is the conversion of programs and data to work with a new code level of IBM® 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 MQ to a new release that changes its command level, migration is performed by the queue manager. Whenever you upgrade IBM 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 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 MQ operating environment migration
Queue manager migration: Migrating a queue manager following an upgrade of the IBM MQ installation to a new command level; see Queue manager migration.
IBM MQ MQI client migration: Migrating a client configuration following installation of a new version or release of the IBM MQ MQI client ; see IBM MQ MQI client migration.
Application migration: Relinking, recompiling, or recoding an IBM 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 IBM MQ MQI client client, on other clients or queue managers:

Compatibility, coexistence, and interoperability: See Coexistence, compatibility, and interoperability for information about the compatibility of IBM MQ applications connected to queue managers and IBM MQ MQI client clients on different command levels. The section also explains the concept of queue manager coexistence, and the interoperability of IBM 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.
Queue-sharing groups: Queue sharing groups involve multiple queue managers running on z/OS®. How do you migrate queue managers that are part of a queue-sharing group to a new command level; see Queue-sharing group migration.
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 Migrating 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.

IBM MQ migration concepts

Figure 1 shows two runtime operating system environments. One environment is called Server, and contains an IBM MQ server and server application. The other is called Client, and contains an IBM MQ MQI client client application. The server environment has one or more queue managers represented by QM using the installation of IBM 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 MQ installed in the same operating environment are called coexistent ¹ . The IBM 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.

[z/OS] Only z/OS supports multiple queue managers coexisting at different release levels in the same operating environment.

Queue manager coexistence is important for migration in two respects:

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.

For details, see Queue manager coexistence in Version 8.0

The queue manager, QM*, represents queue managers of various levels installed on other servers.

Software component diagram showing a client and server. Each contains a number of software components, such as databases, application servers, and the language or subsystem runtime environment. The environment contains an IBM MQ application, the IBM MQ MQI client or server library, and IBM MQ channel and API exit programs. These components are connected to a queue manager component, either locally in the server, or remotely to the same server queue manager from the client. The application is linked to the IBM MQ library by the MQI. The libraries are shown linked to the queue manager either by an SPI, which describes the connection between the process running the MQI and the queue manager processes, or by an IBM MQ MQI client connection. The diagram also shows the queue manager linked to another queue manager at a different level on another server, and also a queue manager, QM-n, on the same server. The queue manager called QM-n is running at a lower level. It represents a number of queue managers of different versions, coexisting on the same server. — Figure 1. IBM MQ application migration model

¹ It is not necessary, but it is usual, for coexistent installations to be at different release levels.