When migrating a MQ cluster, please migrate full repositories first to avoid instability. To work predictably, the full repository queue managers must be at the new command level to be able to store information from the rest of the cluster that arises from using new features.
Reference document:
Migrating a queue manager cluster
https://www.ibm.com/docs/en/ibm-mq/9.2?topic=mq-migrating-queue-manager-cluster
How mixed version cluster repositories are updated
https://www.ibm.com/docs/en/ibm-mq/9.2?topic=cluster-how-mixed-version-repositories-are-updated
.
Follow the steps in below MQ documenation to migrate a single queue manager in a cluster, starting with a queue manager in your test system. Base these steps on your cluster migration plan.
Migrating one cluster queue manager
https://www.ibm.com/docs/en/ibm-mq/9.2?topic=cluster-migrating-one-queue-manager
SUSPEND QMGR is to advise other queue managers in a cluster to avoid sending messages to the local queue manager if possible. Because you will stop entire system, it’s not necessary to suspend qmgr in this scenario.
Note:If the QMGR that Is planned for migration is a kind of QMGR where there are no application are connected by architecutre and no message are routing to this based on channel priority then Suspend may not be need as per the above statement .
Reference Document:
SUSPEND QMGR, RESUME QMGR and clusters
https://www.ibm.com/docs/en/ibm-mq/9.2?topic=commands-suspend-qmgr-resume-qmgr-clusters
SUSPEND QMGR (suspend a cluster queue manager)
https://www.ibm.com/docs/en/ibm-mq/9.2?topic=reference-suspend-qmgr-suspend-cluster-queue-manager
.
If there is a full downtime to bring entire cluster then we need to make sure the full repository is migrated first and start followed by the partial repositories .
Note to take the backup of the entire /var/mqm and any share file systems to help to restore incase if it needed .