Migrating IBM MQ
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.
Before starting
Before upgrading the IBM MQ installation or migrating your queue managers, we must read Changes that affect migration to identify what migration tasks we must plan for.
About this task
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, we can migrate the queue manager to use the new command level and thereby the new function.
If you start a queue manager running on a later release level, then migration of the queue manager to that release level is required. The migration tasks we must perform to migrate from one release to another are documented in Migrating a queue manager on Windows; see also Changes that affect migration.
On IBM MQ for Multiplatforms, we cannot easily revert to a previous level of IBM MQ after installation. If we install a copy of IBM MQ obtained from Passport Advantage or from physical media, the installer uninstalls IBM MQ, if it is present. It then installs the new level of IBM MQ. To revert to the previous level of IBM MQ, we must keep the earlier installation image and any fixes you applied. Then we must uninstall the new level, reinstall the previous release level, and reapply the required fixes. If we have started any queue managers at the later level, they will not work with the restored level of IBM MQ. (Unless you installed a later maintenance level upgrade, not a new release or version: then you could revert to an earlier maintenance level by reinstalling the earlier maintenance level upgrade. Queue manager data is compatible between maintenance levels.) To restore IBM MQ to its previous level, after starting any queue managers, we must first back up the queue managers. We can then restore the backup queue managers after restoring the previous level of IBM MQ.
On IBM MQ for z/OS it
is possible to backwards migrate from a Long Term Support
(LTS) release. This
statement also applies to those CD releases
that have the same VRM as an LTS release, for
example Version 9.2.0 CD.
Backwards migration is not supported to or from a Continuous Delivery (CD) release on z/OS, unless those releases have the same VRM as an LTS release, for example Version 9.2.0 CD.
- Changes that affect migration
Changes to the product might affect the migration of a queue manager from an earlier release to the current release of IBM MQ, or affect existing applications or configurations. Review these changes before upgrading queue managers to the latest product version and decide whether we must plan to make changes to existing applications, scripts, and procedures before starting to migrate the systems. - Migration paths
An overview of the migration paths between different IBM MQ versions. For some IBM MQ for z/OS migration paths, we can revert to the version you were using prior to migration. For IBM MQ for Multiplatforms, we cannot easily revert to a previous version. - Migration concepts and methods
An overview of the various concepts and methods for migrating from one release of the product to another. - Coexistence, compatibility, and interoperability
The definitions of the IBM MQ terms coexistence, compatibility, and interoperability. - Migrating from one Continuous Delivery release to another
An overview of how we migrate from one Continuous Delivery (CD) release to another. - Migrating IBM MQ on Windows
IBM MQ migration tasks associated with Windows platforms are grouped in this section. - Migrating IBM MQ on UNIX and Linux
Migration tasks associated with UNIX and Linux platforms are grouped in this section. - Migrating IBM MQ on IBM i
IBM MQ migration tasks associated with IBM i are grouped in this section. - Migrating IBM MQ on z/OS
Migration tasks associated with z/OS are grouped in this section. - Migrating a queue manager cluster
We can migrate queue managers in a cluster all at once, or one at a time, which is called a staged migration. Migrate full repository queue managers in a cluster before partial repository queue managers. We must consider what the effect is of migrating some queue managers in a cluster, before all the queue managers are migrated. - Migrating a queue manager in a high-availability configuration
High-availability configurations of queue managers can increase the availability of IBM MQ applications. If a queue manager, or server fails, it is restarted automatically on another server. We can arrange for IBM MQ MQI client applications to automatically reconnect to the queue manager. Server applications can be configured to start when the queue manager starts. - Migrating an RDQM configuration from RHEL 7 to RHEL 8
If you upgrade from RHEL 7 to RHEL 8, create a new Pacemaker cluster and migrate your replicated data queue managers (RDQMs) to the new cluster. - Migrating replicated data queue managers
When we need to migrate replicated data queue managers (RDQMs), we must upgrade all nodes in a sequence. Do not try to operate with the nodes at different levels. This guidance is appropriate for moving between major releases, or CD releases, but not for applying (fix pack) maintenance. - Moving a queue manager to a different operating system
Follow these instructions to move a queue manager from one operating system to another. Note that this is not a migration of a queue manager. - Migrating logs on UNIX, Linux, and Windows
From IBM MQ Version 9.1.0 we can migrate a circular log to a linear log, or from a linear log to a circular log. - Internet Protocol Version 6 (IPv6) migration
This section deals with using IPv4 and IPv6 when we are thinking of installing IBM MQ - Migrating existing security configurations to use an alias CipherSpec
Migrating existing secure channel definitions to use an alias CipherSpec, for example, ANY_TLS12_OR_HIGHER, ANY_TLS13_OR_HIGHER, and so on, means that your enterprise can adapt to cipher additions and deprecations without needing to make further invasive configuration changes in the future.
Parent topic: Maintain and migrate IBM MQ
Related concepts
- The version naming scheme for IBM MQ for Multiplatforms
- Multi-installation queue manager coexistence on UNIX, Linux, and Windows
- Queue manager coexistence
Related information