Queue Manager Migration

Queue manager migration answers: how do we move QM.PAYMENTS from the aging Linux host in London to a new VM in the cloud—or merge two queue managers after an acquisition—without losing in-flight settlement messages or breaking fifty partner banks? It is narrower than whole-environment migration but deeper than object promotion, because message files, logs, and in-doubt transactions may travel with the queue manager. Beginners confuse exporting MQSC with migrating messages; dmpmqcfg recreates definitions on a blank QM, not a million persistent messages on PAYMENTS.IN. This tutorial compares drain-and-cutover versus backup-restore, same-name versus rename, partner channel retargeting, cluster member moves at overview, testing gates, and rollback when cutover fails mid-window.

Migration Patterns

Queue manager migration approaches
PatternMessagesTypical downtime
Drain and cutoverConsumers empty queues firstMinutes to hours
Backup/restore (cold)Preserved if supportedHours—QM down
Parallel QM + replayDual write or bridgeLow if phased
Definitions onlyNot migratedApp dependent

Phase 1: Inventory and Dependencies

  • Queue depths and ages on critical queues—oldest message timestamp.
  • All XMITQs and channel partners with contact and firewall rules.
  • Applications: CCDT, connection factory JNDI, Kubernetes secrets.
  • Indoubt transactions and XA resources—resolve before move if possible.
  • TLS certificates expiring on old host—renew on target before cutover.

Phase 2: Build Target Queue Manager

Install MQ at target version on target OS. Create queue manager with crtmqm or operator equivalent. If renaming, choose new name and plan partner CONNAME updates. Import definitions via dmpmqcfg output or scripted DEFINE—review for environment-specific paths (DLQ names, cluster names). Do not START channels to production partners until testing complete—use test channels or firewall blocks.

text
1
2
3
4
5
6
# Source — export definitions dmpmqcfg -m QM_PAY -a > QM_PAY_defs.mqsc # Target — after crtmqm and strmqm on new host runmqsc QM_PAY_NEW < QM_PAY_defs.mqsc # Manually edit paths, CONNAME, SSLPEER before prod use

Phase 3: Message Movement

For drain: stop new input (router flag or app config), let consumers drain CURDEPTH to zero, verify with DISPLAY QLOCAL CURDEPTH. For backup/restore: endmqm cleanly, backup log and qmgr directories per IBM guide, restore on target, strmqm and allow recovery. For bridge: use channel pair or tool to move messages queue-by-queue during parallel run—higher complexity, lower big-bang risk. Non-persistent backlog is often acceptable to drop if business agrees in writing.

Phase 4: Partner and Channel Cutover

  1. Agree window with each external partner.
  2. STOP channels on old QM; confirm no new messages arrive.
  3. Update partner firewall and CONNAME to new IP/DNS.
  4. START channels on new QM; verify BINDING then RUNNING.
  5. Test message round-trip with partner test queue.

Phase 5: Application Cutover

Update connection strings in waves: read-only consumers first, then producers, or vice versa per architecture. Watch MQRC 2059 and 2538 during switch. Use feature flags in microservices to point at new CCDT. Mainframe batch may need single JCL change window—coordinate with ops scheduler.

Cluster Considerations

Removing a cluster member affects routing tables. Plan REFRESH CLUSTER and full repository availability. Migrating a full repository queue manager without cluster expertise invites weeks of wrong-route incidents—engage someone who knows CLWLMRANK and repository roles.

Validation and Decommission

Compare message counts, run business reconciliation, monitor DLQ for 72 hours. Keep old QM read-only or powered off but recoverable until sign-off. Document decommission: remove DNS, firewall rules, and monitoring probes for old host. Archive final dmpmqcfg from both sides for audit.

Explainer: Moving One Branch Office

Environment migration is relocating the whole company. Queue manager migration is moving one branch office—files, staff phone extensions, and courier routes to that building still need updating even if headquarters stays put.

Explain Like I'm Five: Queue Manager Migration

Queue manager migration is moving one post office to a new building—you carry the mail bags and tell everyone the new address so letters still arrive.

Practice Exercises

Exercise 1

Export dmpmqcfg from lab QM and build empty target QM from script only.

Exercise 2

Document partner list template for a fictional QM migration.

Exercise 3

Simulate drain: stop producer, measure time to empty test queue.

Frequently Asked Questions

Frequently Asked Questions

Test Your Knowledge

Test Your Knowledge

1. QM migration moves:

  • One QM and its data/partners
  • Only DNS
  • Only clients
  • JCL procs only

2. Hot copy of qmgr disk while running:

  • Risky without IBM path
  • Always best
  • Required
  • Illegal everywhere

3. dmpmqcfg exports:

  • Definitions not message bodies
  • All messages to XML
  • Only logs
  • Only TLS keys

4. Rename QM requires:

  • Partner and client updates
  • Nothing
  • Only LDAP
  • Delete all queues
Published
Read time24 min
AuthorMainframeMaster
Verified: IBM MQ 9.4 documentation