Overview of migration methods

An overview of the various methods of migrating IBM® MQ from one release to another are explained, together with a brief description of the difference between maintenance, migration, and upgrading.

Maintenance, migration and upgrading

How IBM MQ uses this terminology:
  • Migration is the process of updating 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.
  • Maintenance is the application of a fix pack, interim fix or program Temporary Fix (PTF). The installation can be restored to its previous level and queue managers or applications continue to work. Migration is not required after applying maintenance. However, you should test applications with the new level of IBM MQ code.
  • Upgrading is the process of taking an existing IBM MQ installation and upgrading to a new level of code. Unless the upgrade is applying a fix (and not enabling new function), an upgrade must be followed by migration.
  • Once migration has occurred, the queue manager can no longer be started by an earlier code level. Queue manager migration is not reversible [z/OS](except on z/OS®, with important restrictions).
Notes:
  1. The example commands in these topics apply to UNIX and Linux®, and Windows platforms only.
  2. [IBMi]Side-by-side migration has a different meaning on IBM i. See Installation methods on IBM i for further information.
  3. [IBMi]Multiple installations are not applicable to IBM i.

Single stage migration

Single-stage migration is the term used to describe replacing the only installation of IBM MQ on a server, with a later release.

Until IBM WebSphere® MQ 7.1, single-stage was the only migration scenario. Single-stage migration preserves existing scripts and procedures for running IBM MQ the most. With other migration scenarios you might change some scripts and procedures, but you can reduce the effect queue manager migration has on users.

See UNIX, Linux, and Windows: Single-stage migration to a later version for information on carrying out this method of migration.

Side-by-side migration

Side-by-side migration is the term used to describe installing a new version of IBM MQ alongside an older version on the same server.

Queue managers continue running, and remain associated with the older version of IBM MQ, during the installation and verification of the new version of IBM MQ.

When you decide to migrate queue managers to the new version of IBM MQ, you stop all queue managers, migrate them all to the new version, and uninstall the old version of IBM MQ.

The side-by-side migration scenario is less flexible than the multistage migration. The advantage the side-by-side scenario has over the single-stage scenario is that you can install and verify the new IBM MQ installation on the server before switching over to it.

The process is based on the following premise:
  • Install additional IBM MQ code alongside existing installation while queue managers are still running.
  • Move queue managers one at a time to the new installation.
  • Migrate and test applications one at a time.

With the side-by-side approach, you can assign a later version of IBM MQ to be the primary installation, whereas, with the multistage approach, you cannot do so, if you have IBM WebSphere MQ 7.0.1 installed, until you uninstall IBM WebSphere MQ 7.0.1.

With a later version of IBM MQ set as the primary installation, many applications restart without having to re-configure their environment, and IBM MQ commands work without providing a local search path.

See UNIX, Linux, and Windows: Side-by-side migration to a later version for information on carrying out this method of migration.

Multistage migration

Multistage migration is the term used to describe running a new version of IBM MQ alongside an older version on the same server.

After installing the new version alongside the old, you can create new queue managers to verify the new installation, and develop new applications.

At the same time, you can migrate queue managers and their associated applications from the old version to the new. By migrating queue managers and applications one-by-one, you can reduce the peak workload on your staff managing the migration.

See UNIX, Linux, and Windows: Multi-stage migration to a later version for information on carrying out this method of migration.