Migration concepts and methods

An overview of the various concepts and methods for migrating from one release of the product to another.

Objects to consider during migration

It is important to consider four types of object during migration:

Operate 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.

When migrating queue managers that are members of a cluster, do full repositories before partial repositories. This is because an older repository cannot store newer attributes introduced in a newer release. It tolerates them, but does not store them.

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.

It is better to migrate the clients after the queue managers that they communicate with have been migrated.

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.

Use the new version of the libraries to build the applications, once the queue managers have been upgraded.

Impact of migration on other queue managers or clients

In addition, we must consider the impact of migrating one queue manager, or IBM MQ MQI client, on other queue managers or clients:

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 Migrating a queue manager cluster 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 we 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 we 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 application migration model

Figure 1 shows the various components of the application migration model.

This diagram shows two runtime operating system environments, each of which contains a number of software components, such as databases, application servers, and the language or subsystem run time environment. One environment is called Server, and contains an IBM MQ server and server application. The other environment is called Client, and contains an IBM MQ MQI client application.

The language or subsystem run time environment contains an IBM MQ application, the IBM MQ MQI client or server library, and IBM MQ channel and API exit programs.

The server environment has one or more queue managers, represented in the diagram by QM, that are using the installation of IBM MQ installed on the server. The components of the language or subsystem run time environment are connected to queue manager QM, either locally in the server, or remotely from the client.

The application is linked to the IBM MQ library by the MQI. The libraries are shown linked to the queue manager QM 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 two more queue managers:

• The queue manager labeled QM*, which represents queue managers of various levels installed on other servers.
• The queue manager labeled QM-n?, which represents a number of queue managers that coexist on the same server as queue manager QM, but are running at a different release level. The installations for these different release levels are not shown in the diagram. The question-mark in the queue manager name QM-n? indicates that this capability might not be present in the environment.

Multiple releases of IBM MQ installed in the same operating environment are called coexistent. It is not necessary, but it is usual, for coexistent installations to be at different release levels. Queue manager coexistence is important for migration in two respects:

1. It can be used to reduce the risk involved in migrating to a new command level, and reduce the downtime during the migration process.
2. We must consider any configuration implications of running some applications or clusters on the same server with queue managers at different command levels.

For more information, see Queue manager coexistence.

• IBM MQ operating environment migration
  We might need to perform some migration tasks for IBM MQ as a result of upgrading the operating environment.
• Queue manager migration
  After upgrading an installation, queue manager migration might be required. Migration takes place when you start a queue manager. We can remove an upgrade before you have started a queue manager. However, if you remove the upgrade after a queue manager has been started, the queue manager will not work.
• IBM MQ MQI client migration
  IBM MQ MQI client migration is the process of converting IBM MQ MQI client configurations, and client and server channels from one version to another. Client migration can take place after upgrading the IBM MQ MQI client, and is reversible.
• Application migration and interoperation
  IBM MQ supports running applications compiled and linked against previous versions of IBM MQ, with later levels of IBM MQ. IBM MQ applications might require migration between Version 7.1 and the latest version. Use the new version of the libraries to build the applications, once the queue managers have been upgraded.
• Migration methods on IBM MQ for Multiplatforms
  There are three main methods of migrating from one release to another: Single-stage migration (called a slip installation on IBM i), side-by-side migration, and multi-stage migration. Multi-stage migration is not an option for IBM i.
• Primary installation on UNIX, Linux and Windows
  On UNIX, Linux, and Windows, which support multiple installations of IBM MQ, we can optionally define one installation as the primary installation. The primary installation is the one to which IBM MQ system-wide locations refer.
• Multiple IBM MQ installations
  From IBM WebSphere MQ Version 7.1, multiple IBM MQ installations are supported on UNIX, Linux, and Windows. This gives you the option to install and select between one or more IBM MQ installations.

Parent topic: Migrating IBM MQ