You probably need this if…
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.
The queue manager estate is known from memory: a spreadsheet, an old diagram and one engineer.
A complete inventory of queue managers, queues, channels, clusters and client applications, each tagged with what it needs from a broker.
The choice is framed as IBM MQ against Kafka, and every workload gets pushed through the same answer.
Each workload routed to a destination on evidence: stay on a supported IBM MQ release, move to RabbitMQ, or move to Kafka.
Migration risk is a feeling: nobody can say what breaks on cutover or how to undo it.
A per-flow cutover plan with reconciliation gates and a rollback that has been rehearsed before it is needed.
The old platform lingers because retiring it was never part of the plan.
A decommissioning step with a sign-off, so the IBM MQ licence and hosting lines actually stop.
What's covered
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.
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.
- Queue manager, queue and channel inventory
- Application and client dependency map
- Version and support position against IBM's lifecycle dates
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.
- Workload routing table
- Target architecture
- Phased migration plan with exit gates
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.
- Target brokers deployed and tested
- Bridge or dual-publish path with reconciliation
- Per-application change specification
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.
- Cutover runbook per flow
- Rollback rehearsal record
- Decommissioning sign-off
IBM MQ 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. |
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.
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.
Real IBM MQ Results
See how enterprises trust AceMQ for their most critical IBM MQ workloads.
Questions about IBM MQ migration
Talk to a RabbitMQ Expert
Send us a message and we'll follow up within one business day — or book a free 30-min consultation directly.
305-204-2607info@acemq.comMiami, FL 33130
Prefer to talk now? Call us directly or use the consultation tab to find a time that works.