01
Estate Inventory
Queue managers, queues, topics, channels, clusters, listeners, message sizes and rates, persistence settings and the security model: CHLAUTH, TLS and authentication records.
IBM MQ Migration
IBM MQ Migration: Upgrade or Leave, Decided Workload by Workload
An IBM MQ migration starts with a decision, not a tool: which queues should stay on a supported IBM MQ release, which belong on RabbitMQ and which are really event streams that belong on Kafka. AceMQ inventories your queue managers, routes each workload to the broker that fits it, and runs the move in phases with a rehearsed rollback.
- destinations, chosen per workload: stay, RabbitMQ, Kafka
- 3
- min emergency SLA while both brokers run
- 15
- rule: never migrate and upgrade in one window
- 1
Trusted for Mission-Critical IBM MQ by Teams in Finance, Healthcare, Defense, Telecom, and More
Customers
Partners
Is This You?
You probably need this if…
- 01
Your IBM MQ version is at or near the end of standard support and the upgrade has not been scheduled
- 02
A renewal is coming and nobody has measured what the workload actually needs
- 03
Teams are asking for Kafka, but most of your MQ traffic is transactional queuing, not event streaming
- 04
You do not know how much of your code depends on JMS features, XA transactions or z/OS queue managers
- 05
The business wants off IBM MQ but will not accept downtime, message loss or a change in ordering
- 06
A migration was started and now IBM MQ and the new broker both sit in the critical path
- 07
You want an independent view on upgrading versus leaving, from a party that does not sell either
Outcomes
Where you are now, and where you end up
Concrete state changes, not deliverable counts. This is what actually differs about your IBM MQ estate when the engagement closes.
Before
The queue manager estate is known from memory: a spreadsheet, an old diagram and one engineer.
After
A complete inventory of queue managers, queues, channels, clusters and client applications, each tagged with what it needs from a broker.
Before
The choice is framed as IBM MQ against Kafka, and every workload gets pushed through the same answer.
After
Each workload routed to a destination on evidence: stay on a supported IBM MQ release, move to RabbitMQ, or move to Kafka.
Before
Migration risk is a feeling: nobody can say what breaks on cutover or how to undo it.
After
A per-flow cutover plan with reconciliation gates and a rollback that has been rehearsed before it is needed.
Before
The old platform lingers because retiring it was never part of the plan.
After
A decommissioning step with a sign-off, so the IBM MQ licence and hosting lines actually stop.
Scope
What's covered
- 02
Application and Client Analysis
Which applications use JMS, the MQI, XMS or AMQP, which rely on selectors, syncpoint or XA transactions, and which sit on z/OS. This is where the migration effort is decided.
- 03
Workload Routing
Every flow classified as transactional queuing or event streaming, with a recommended destination and the reason for it. Some queues are better left where they are.
- 04
Target Design
RabbitMQ exchanges, queues and policies, or Kafka topics, partitions and retention, designed for the workload rather than copied from the queue manager layout.
- 05
Bridge and Parallel Run
Both brokers run side by side. Traffic is bridged or dual-published and the two sides reconciled, so a flow moves only when the numbers agree.
- 06
Cutover, Rollback and Retirement
Flow-by-flow cutover with automatic rollback triggers, then decommissioning of the source queue managers once the last flow has soaked.
The Engagement
How it actually runs
Every phase has a defined duration and a concrete artifact handed over at the end of it. You always know what stage you're in and what you've received.
- Phase 11–2 weeks
Estate Assessment
We map every queue manager, the applications on each and the bridges between them. Delivery is remote and guided by your engineers over screen share. We take no access to your systems or code.
You receive
- Queue manager, queue and channel inventory
- Application and client dependency map
- Version and support position against IBM's lifecycle dates
- Phase 2Within a week
Decision and Plan
Written findings with the reasoning attached: which workloads stay, which move to RabbitMQ, which move to Kafka, what each path costs in change and in risk, and the order of moves.
You receive
- Workload routing table
- Target architecture
- Phased migration plan with exit gates
- Phase 3Scoped per engagement
Build and Parallel Run
We stand up the target alongside IBM MQ, build the bridge or dual-publish path, and give your developers a per-application change specification. Consumers on the new side are built to tolerate duplicates before any flow cuts over.
You receive
- Target brokers deployed and tested
- Bridge or dual-publish path with reconciliation
- Per-application change specification
- Phase 4Per flow
Cutover and Retirement
Flows move one at a time, simplest first, each with a soak period and a rehearsed rollback. When the last flow has settled, the source queue managers are retired.
You receive
- Cutover runbook per flow
- Rollback rehearsal record
- Decommissioning sign-off
IBM MQ end of life and end of support: upgrade or leave?
Version support sets the clock, but it does not make the decision. IBM MQ keeps running past the end of standard support. What stops is the flow of fixes, and an unsupported version becomes an audit finding on its own. The dates below are the ones IBM publishes on its lifecycle pages.
| Version | General availability | Standard support ends, Extended Support begins | Extended Support ends |
|---|---|---|---|
| IBM MQ 9.0 | 2 Jun 2016 | 30 Sep 2021 | 30 Sep 2025 |
| IBM MQ 9.1 | 23 Jul 2018 | 30 Sep 2023 | 30 Sep 2027 |
| IBM MQ 9.2 | 23 Jul 2020 | 30 Sep 2025 | 30 Sep 2029 |
| IBM MQ 9.3 | 23 Jun 2022 | 30 Sep 2027 | 30 Sep 2031 |
| IBM MQ 9.4 | 18 Jun 2024 | No date published on IBM's lifecycle page. The page shows 9.4 as Support Cycle-5. | Not published |
Across roughly 9 IBM MQ conversations since 2025, the drivers were licence cost and vendor support experience. Most plans were phased: the simplest workloads moved first, and IBM MQ stayed alongside the new broker where it still fits.
| Situation | Points toward | Why |
|---|---|---|
| Queues on z/OS, or applications that need XA transactions across MQ and a database | Upgrade IBM MQ | Neither RabbitMQ nor Kafka takes over two-phase commit. Moving these flows means redesigning the application, not reconfiguring a broker. |
| Work queues, command and request/reply traffic from JMS or AMQP clients on distributed platforms | Leave for RabbitMQ | Per-message routing, acknowledgement and dead-lettering map well, and the clients are straightforward to repoint. |
| Data feeds with many independent readers, replay or long retention | Leave for Kafka | The workload is a log, not a queue. A partitioned, retained topic fits it better than any queue manager. |
| Version at or near end of standard support, no migration scoped | Upgrade to a supported release | Extended Support is a bridge. Use it while a migration runs, not as the plan. |
| Mixed estate, cost is the driver | Both, in phases | Move the simplest flows first and keep IBM MQ where it still fits. |
Rule we hold
Never combine a platform migration with a version upgrade in the same production window. If the IBM MQ version has to change first, that is its own change.
IBM MQ alternatives: RabbitMQ or Kafka, by workload
Most lists of IBM MQ alternatives are lists of products. The more useful question is what each workload is. A queue that distributes commands to workers and a topic that feeds a data platform have different needs, and one broker rarely serves both well.
| Workload trait | RabbitMQ | Kafka |
|---|---|---|
| Message lifecycle | A message is delivered, acknowledged and removed. | A message stays in the log until retention expires, whether or not it has been read. |
| Consumers | Competing consumers share a queue; each message goes to one. | Each consumer group reads the whole topic independently, at its own offset. |
| Routing | Exchanges, bindings and routing keys decide where a message goes. | Producers choose the topic and the key; routing logic lives in the consumers. |
| Replay | Not the default. Streams add a replayable log for specific cases. | Native. Consumers rewind to an offset. |
| Typical IBM MQ fit | Transactional queuing: commands, work queues, request/reply. | Event streaming: change feeds, telemetry, fan-out to analytics. |
That is the rule of thumb we apply: RabbitMQ for transactional queuing, Kafka for event streaming and replay. It is judgement, applied per flow in discovery, and we say so when neither is the right target.
An IBM MQ to Kafka migration deserves care for another reason. A Kafka topic is not a drop-in queue. Parallelism is capped by the partition count, ordering holds per partition, and there is no per-message acknowledgement that removes a message. Queues that behave like work queues are usually better placed on RabbitMQ.
Mainframe queues and timeline
Mainframe queue managers usually move last. They typically need a distributed queue manager as the hop to the new broker, and the application changes are the largest. A moderately complex estate of a few dozen destinations typically takes nine to sixteen weeks end to end, and most of that is discovery and parallel run rather than the cutover itself.
IBM MQ to RabbitMQ in practice: American National
American National Insurance engaged AceMQ for a phased migration away from IBM MQ. Windows-based queues moved first, and a validated roadmap covers the mainframe queues that follow. IBM MQ patterns were translated into RabbitMQ exchanges and bindings, with code refactoring guidance, HIPAA-compliant data handling throughout, and a parallel operation period with behaviour validation before each cutover. The RabbitMQ target runs on Kubernetes. Continuity was kept, and IBM MQ licensing cost is being removed progressively as workloads move.
With Dell, we also built an IBM MQ displacement approach: a total cost of ownership framework, a workload assessment, capability mapping, and AceMQ commercial support as the alternative to IBM support.
What we do not do
We deliver remotely, guided by your engineers, and we do not rewrite your application code: you get a per-application change specification. We do not resell IBM MQ, and we say in discovery if staying on IBM MQ is the right answer for a flow.
Customer Success
Real IBM MQ Results
See how enterprises trust AceMQ for their most critical IBM MQ workloads.
Retry Automation and Downstream Back-Pressure Remediation
International Payment Exchange Service
Reducing manual error-queue operations by improving retry handling, dead-lettering, and downstream flow management across RabbitMQ, BizTalk, and D365.
RabbitMQBizTalkD365
IBM MQRabbitMQ Migration from Legacy Middleware
Global Management Consulting Firm
Moving from older or more rigid middleware to RabbitMQ patterns with architecture transition planning, interoperability, and phased cutover.
RabbitMQIBM MQBizTalk
Kafka CVE Patching and Compliance Strategy for Global Enterprise
Global Technology Enterprise
AceMQ developed a multi-technology compliance strategy covering CVE patching for Kafka alongside RabbitMQ and IBM MQ deployments, creating a unified vulnerability management approach across the entire enterprise messaging stack.
KafkaRabbitMQIBM MQEnterprise Migration from IBM MQ to Kafka and RabbitMQ
Enterprise Financial Services Organizations
AceMQ advises enterprises transitioning IBM MQ workloads to modern messaging platforms, routing workloads to Kafka for event streaming or RabbitMQ for transactional messaging based on specific use case requirements.
KafkaIBM MQRabbitMQIBM MQ to RabbitMQ Migration for Insurance Carrier
American National Insurance
AceMQ led the phased migration of American National Insurance's IBM MQ infrastructure to RabbitMQ, including legacy code refactoring and HIPAA-compliant data handling across Windows and mainframe queue environments.
IBM MQRabbitMQ
KubernetesIBM MQ Displacement Strategy for Global Enterprise
Global Technology Enterprise
AceMQ and a global technology partner developed a joint motion for displacing IBM MQ in enterprise accounts, leveraging RabbitMQ as a cost-effective open-source alternative with AceMQ's commercial support model.
IBM MQRabbitMQKafkaIBM MQ Cost Reduction and Modernization for Financial Services
Financial Services Organizations
AceMQ helps financial services organizations replace costly IBM MQ deployments with RabbitMQ, providing the commercial support and SLA guarantees that regulated industries require while dramatically reducing messaging infrastructure costs.
IBM MQRabbitMQIBM MQ Support Model Assessment for Government Agency
Government / Law Enforcement Agency
AceMQ provided a support model and SLA comparison for a government agency evaluating alternatives to IBM MQ support, including 48-hour critical patch response commitments and compliance documentation capabilities.
IBM MQ
FAQ
Questions about IBM MQ migration
What are the alternatives to IBM MQ?
The practical alternatives are RabbitMQ and Apache Kafka, with ActiveMQ and the cloud services (Amazon SQS, Azure Service Bus, Google Cloud Pub/Sub) as others. They are not interchangeable. RabbitMQ suits the transactional queuing most IBM MQ estates run, such as commands, work queues and request/reply. Kafka suits event streaming and replay. WebSphere MQ is the old name for IBM MQ, so WebSphere MQ alternatives are the same list.
When is IBM MQ end of life (EOL)?
IBM speaks of end of support rather than end of life, so an IBM MQ EOL date means the end of standard support for a version. Per IBM's lifecycle page checked on 14 October 2026, IBM MQ 9.1 left standard support on 30 September 2023 and 9.2 on 30 September 2025. IBM MQ 9.3 reaches that point on 30 September 2027. Extended Support runs to 30 September 2027, 2029 and 2031 for 9.1, 9.2 and 9.3. IBM publishes no end-of-support date for 9.4 on that page, so confirm before using one in a compliance document.
Should we upgrade IBM MQ or migrate off it?
It depends on the workload, not the platform. Flows that need z/OS queue managers or XA transactions are usually best left on a supported IBM MQ release. Work queues and request/reply traffic move well to RabbitMQ, and event streams to Kafka. Most plans we see are phased, moving the simplest workloads first and keeping IBM MQ alongside the new broker where it still fits.
How do you migrate from IBM MQ to Kafka?
First by checking the workload really is a stream. Queues with competing consumers behave differently on a partitioned topic, so those usually go to RabbitMQ instead. For flows that are streams, we design the topics, partitions and retention, bridge traffic from IBM MQ while both run, reconcile counts, and cut consumers over one flow at a time with a rollback ready.
How long does an IBM MQ migration take?
The assessment takes one to two weeks and the written plan follows within a week. A moderately complex estate of a few dozen destinations typically takes nine to sixteen weeks end to end. We give a fixed timeline once the inventory is done.
What does AceMQ not do on an IBM MQ migration?
We work remotely, guided by your engineers, with no access to your systems. We do not rewrite your application code; we give you a per-application change specification. We do not resell IBM MQ or negotiate with IBM. And we never combine a platform migration with a version upgrade in the same production window.
Let's talk
Plan Your IBM MQ Migration
Tell us how many queue managers you run and which IBM MQ versions they are on. We will scope the assessment and reply within 1 hour and follow with a timeline and a written quote.
Get in Touch
Talk to an IBM MQ Expert
Send us a message and we'll follow up within 1 hour — or book a free 30-min consultation directly.
305-204-2607info@acemq.com66 W. Flagler St. 9th Floor
Miami, FL 33130
Miami, FL 33130
Prefer to talk now? Call us directly or use the consultation tab to find a time that works.