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.
Important:If we are migrating to Version 9.2 from Version 7.5 or earlier, we must first migrate to an interim version. See Migration paths.
Before we use side-by-side or multi-stage migration to migrate from Version 7.0.1, check that your Version 7.0.1 installation is at Fix Pack 6 or later.
Single-stage migration
Single-stage migration is the term that is used to describe replacing the only installation of IBM MQ on a server, with a later release. Before IBM WebSphere MQ Version 7.1, single-stage was the only migration scenario.
The advantage of single-stage migration is that it changes the configuration of a queue manager on the earlier version as little as possible. Existing applications switch from loading the libraries from the earlier version, to loading the libraries of the later version, automatically. Queue managers are automatically associated with the installation on the later version. Administrative scripts and procedures are affected as little as possible by setting the installation to be the primary installation. If you set the installation of the later version to be the primary installation, commands such as strmqm work without providing an explicit path to the command.
Of the three approaches, single-stage migration preserves the greatest number of existing scripts and procedures for running IBM MQ. However, the other migration approaches support a gentler transition to the new version, which can reduce the overall impact on users.
For more information about single-stage migration, see:
- Migrating on UNIX and Linux: single-stage
- Migrating on Windows: single stage
- Installation methods on IBM i (on IBM i, a single-stage migration is called a slip installation)
Side-by-side migration
On UNIX, Linux and Windows, side-by-side migration is the term that is used to describe installing a later version of IBM MQ alongside an older version on the same server. The side-by-side migration scenario sits half-way between the single-stage and multi-stage migration scenarios and 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.
During the installation and verification of the later version of IBM MQ, queue managers continue running, and remain associated with the older version of IBM MQ.
When you decide to migrate queue managers to the later version of IBM MQ, you stop all queue managers, migrate them all to the later version, and uninstall the earlier version of IBM MQ.
The advantage that the side-by-side migration has over the single-stage migration is that we can install and verify the later IBM MQ installation on the server before you switch over to it.
Although side-by-side migration is less flexible than multi-stage migration, it does have some advantages over the multi-stage approach. With the side-by-side approach, we can assign a later version of IBM MQ to be the primary installation. With the multistage approach, if IBM WebSphere MQ Version 7.0.1 is installed, this version has to be set as the primary installation. With a later version of IBM MQ set as the primary installation, many applications restart without having to reconfigure their environment, and IBM MQ commands work without providing a local search path.
For more information about side-by-side migration, see:Note: Side-by-side migration has a different meaning on IBM i. A side-by-side installation upgrades IBM MQ on a different computer. For more information, see Installation methods on IBM i. Multiple installations are not applicable to IBM i.
Multi-stage migration
Multi-stage migration is the term that is used to describe running a later version of IBM MQ alongside an older version on the same server. Multi-stage migration is the most flexible approach.
After you install the later version alongside the earlier version, we can create new queue managers to verify the installation of the later version, and develop new applications. At the same time, we can migrate queue managers and their associated applications from the earlier version to the later version. By migrating queue managers and applications one by one, we can reduce the peak workload on your staff who are managing the migration.
For more information about multi-stage migration, see:Parent topic: Migration concepts and methods
Related concepts