01
IBM MQ to RabbitMQ
Queue managers mapped to clusters and virtual hosts, mainframe queues treated as a later phase, and the licensing case written down for procurement.
Legacy Messaging Modernization
Legacy Modernization for Messaging: IBM MQ, MSMQ, ActiveMQ and Azure Service Bus
Legacy modernization for messaging means replacing or retiring the brokers behind your applications, not rewriting the applications. AceMQ runs it in phases: discover who talks to what, run the old and new brokers in parallel, then cut over one application at a time with a rollback at each step. It covers IBM MQ, MSMQ, ActiveMQ and Azure Service Bus to RabbitMQ and Redis to Valkey, and a moderately complex estate typically takes nine to sixteen weeks end to end.
- phases: discover, design, parallel run, cutover
- 4
- weeks typical for a moderately complex estate
- 9–16
- enterprise customers
- 130+
Is This You?
You probably need this if…
- 01
An IBM MQ or ActiveMQ renewal is close and the number has become hard to justify
- 02
Your .NET Framework applications depend on MSMQ and you are moving them to modern .NET
- 03
An Azure Service Bus bill or a cloud exit plan has put self-hosted messaging back on the table
- 04
A broker runs on a platform that is going out of support, and nobody has a map of what connects to it
- 05
A previous migration stalled because nobody could prove messages were not being lost
- 06
Mainframe queues look like one huge move, so nothing moves
- 07
A Kafka cluster was built for a use case that did not need Kafka, and it is expensive to run
Outcomes
Where you are now, and where you end up
Concrete state changes, not deliverable counts. This is what actually differs about your Infrastructure estate when the engagement closes.
Before
Nobody can list every producer and consumer on the legacy broker.
After
A dependency map that includes the forgotten and low-traffic clients, produced before any design is agreed.
Before
A big-bang weekend cutover is the only plan on the table.
After
An application-by-application cutover, lowest risk first, with a rehearsed rollback at every step.
Before
Message loss during a migration is argued about rather than measured.
After
Both brokers running in parallel, message counts reconciled on each side, and a written go or no-go before each cutover.
Before
The legacy broker keeps running because switching it off feels risky.
After
A decommissioning plan, a soak period and the license or hosting line stopped.
Scope
What's covered
- 02
MSMQ to RabbitMQ
System.Messaging code moved to the RabbitMQ .NET client. Transactional queues and distributed transactions are scoped first, because they have no direct equivalent.
- 03
ActiveMQ to RabbitMQ
Classic and Artemis, JMS to AMQP, with message selectors rebuilt as routing and the transaction and acknowledgement differences tested under load.
- 04
Azure Service Bus to RabbitMQ
Queues, topics, sessions and peek-lock mapped to the RabbitMQ model. If the evidence points the other way, we say so before you spend the budget.
- 05
Redis to Valkey
A stay-or-move review, compatibility tests and a rehearsed cutover for teams whose Redis license or managed service is changing.
- 06
Kafka and RabbitMQ by Workload
Each flow routed to the broker that fits it: RabbitMQ for transactional queuing, Kafka for event streaming and replay, and a move off Kafka where it was never needed.
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 12–3 weeks
Discovery and Dependency Mapping
Every queue, topic and destination on the source broker, and every application that connects to it. Migrations fail on the producers and consumers nobody remembered.
You receive
- Topology and destination inventory
- Application dependency map
- Message volume and pattern profile per flow
- Feature gap analysis against the target
- Phase 22–3 weeks
Target Design and Protocol Mapping
The target topology, sized for your real messaging patterns, plus the semantic differences that only surface under load: acknowledgements, transactions, selectors, ordering and dead-lettering.
You receive
- Target topology and sizing
- Concept and protocol mapping
- Per-application change specification
- Risk register for behaviours that do not map one to one
- Phase 33–6 weeks
Parallel Run and Validation
Both brokers run side by side with traffic mirrored to the new one. Message counts are reconciled and nothing is cut over until they agree.
You receive
- Traffic mirroring in place
- Message-level reconciliation reports
- Load and failure tests on the target
- Go or no-go criteria agreed in writing
- Phase 42–4 weeks
Canary Cutover and Decommission
Application by application, lowest risk first, with rollback at each step. After a defined soak period we help you decommission the source broker and stop its license.
You receive
- Staged cutover with rollback
- Post-cutover monitoring per flow
- Decommissioning plan
- Runbook and handover
A phased plan for legacy modernization
A broker migration is a series of small, reversible moves, not one event. The plan below is the one we run for IBM MQ, MSMQ, ActiveMQ and Azure Service Bus, and the decision at the end of each phase is yours.
| Phase | Typical duration | The gate that ends it |
|---|---|---|
| 1. Discovery and dependency mapping | 2 to 3 weeks | You have a map of every destination and every client, including the forgotten ones. |
| 2. Target design and protocol mapping | 2 to 3 weeks | The target design and the per-application change list are agreed. |
| 3. Parallel run and validation | 3 to 6 weeks | Message counts reconcile on both sides and the go or no-go criteria are met. |
| 4. Canary cutover and decommission | 2 to 4 weeks | Every flow is stable on the new broker and the soak period has passed. |
Two rules apply throughout. We never combine a platform migration with a version upgrade in the same production window, and we say in discovery if RabbitMQ is the wrong target. A moderately complex estate of a few dozen destinations and ten to twenty connected applications typically takes nine to sixteen weeks, most of it discovery and parallel run. Estates with hundreds of destinations, or heavy JMS coupling in application code, take longer, and we scope after discovery.
This page is one of AceMQ's solutions for common infrastructure problems
Migration paths and where the detail lives
Each source broker has its own first problem. The table names it and points to the page that carries the full concept mapping and cutover plan.
| From | To | Scope first | Detail |
|---|---|---|---|
| IBM MQ | RabbitMQ for transactional queuing, Kafka for event streaming | Which workloads are queues and which are event streams. Mainframe queues move last. | IBM MQ migration and alternatives |
| MSMQ | RabbitMQ | Transactional queues and distributed transactions, which have no RabbitMQ equivalent. | RabbitMQ migrations |
| ActiveMQ (Classic and Artemis) | RabbitMQ | Message selectors, durable subscriptions, and transaction and acknowledgement behaviour. | RabbitMQ migrations |
| Azure Service Bus | Self-hosted RabbitMQ | Sessions, peek-lock and filter rules, and whether the cost case holds at your volume. | RabbitMQ migrations |
| Redis | Valkey | Data-file compatibility by source version, modules and client libraries. | Redis to Valkey migration |
The concept mapping and dual-publish cutover plan are on RabbitMQ migrations
For lifecycle dates, workload routing and mainframe messaging, see IBM MQ migration and alternatives
For the license and compatibility decision on Redis, see Redis to Valkey migration
For the whole estate in one document, read the IBM MQ modernization guide
Choosing the target enterprise messaging system
A modernisation plan fails when every workload is sent to the same broker. The question is what each flow is. Commands, work queues and request and reply belong on a queue broker. Change feeds, telemetry and fan-out to analytics belong on a log.
| Flow type | Fits | Why |
|---|---|---|
| Commands, work queues, request and reply | RabbitMQ | A message is delivered, acknowledged and removed, and exchanges route it by rule. |
| Change feeds, telemetry, fan-out to analytics | Kafka | Each consumer group reads the whole log at its own pace, and consumers can replay. |
| Low-latency reference data, caching | Redis or Valkey | In-memory data structures, not a message store. |
| Mainframe and regulated workloads that must stay | IBM MQ, on a supported release | Some queues are best left where they are, and supported. |
Is Kafka a replacement for MQ? Only for flows that are event streams. 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. The same logic works in reverse. Where a Kafka cluster was built for a use case that did not need replay, moving that flow to RabbitMQ can simplify operations, as it did at American National.
The reasoning for the Kafka to RabbitMQ direction is in replacing Kafka with Debezium and RabbitMQ for change data capture
American National: IBM MQ to RabbitMQ in phases
American National Insurance (ANICO) is the named reference for this work. The published account describes a phased approach in which each step reduced risk for the next.
| Step | What AceMQ did | Result |
|---|---|---|
| Windows-based IBM MQ queues | Translated IBM MQ patterns into RabbitMQ exchanges and bindings, gave code refactoring guidance, handled data to HIPAA requirements, and ran both brokers in parallel with behaviour validation before each cutover. | The Windows workloads moved to RabbitMQ on Kubernetes, and IBM MQ licensing cost is being removed progressively. |
| Mainframe IBM MQ queues | Defined and validated a migration roadmap and technical architecture for the mainframe queues as a later phase. | A roadmap for the hardest workloads, with continuity kept in the meantime. |
| Change data capture from SQL Server | Replaced a Kafka-based pipeline with standalone Debezium publishing directly to RabbitMQ, on Kubernetes. | Less Kafka operational overhead, full change capture kept, and more flexible routing. |
The full accounts are American National IBM MQ to RabbitMQ migration
and American National Kafka CDC replacement
For insurers facing the same decision, see messaging for insurance
For banks, payment firms and trading firms, see RabbitMQ and Kafka for financial services
After cutover: who runs the new platform
A modernised platform still needs someone on call. AceMQ offers four stages of cover, and you can start at the first and move up when you want the pager off your team.
| Stage | What it is |
|---|---|
| Stage 1: Reactive support | Senior engineers on call for incidents under a contracted SLA. |
| Stage 2: Proactive support | Stage 1 plus monitoring through AceMQ's observability setup. |
| Stage 3: Managed on your infrastructure | AceMQ operates the platform inside your cloud account or data center. |
| Stage 4: Managed on AceMQ's infrastructure | AceMQ hosts and operates the platform. |
Support plans and what each covers: enterprise open source support
To run RabbitMQ in production, see 24/7 RabbitMQ support
FAQ
Questions about Infrastructure legacy messaging modernization
Who migrates IBM MQ to RabbitMQ in phases without downtime?
AceMQ does, remotely and guided by your engineers. Both brokers run in parallel, producers dual-publish, and consumers move one application at a time, lowest risk first, with a rollback at each step. Windows-based queues usually move before mainframe queues. American National Insurance is the named reference.
Is Kafka a replacement for MQ?
For event streams, yes. For transactional queuing, usually not. Kafka keeps a replayable log that many consumer groups read, while an MQ queue delivers a message once and removes it. We route each workload: RabbitMQ for commands and work queues, Kafka for change feeds and analytics.
Do people still use RabbitMQ?
Yes. It is an actively maintained open-source broker, and AceMQ supports RabbitMQ estates for its 130+ enterprise customers in 26+ countries.
Is there an open source message queue?
Several. RabbitMQ is open source under the Mozilla Public License 2.0, and Apache ActiveMQ and Apache Kafka are Apache 2.0 projects. RabbitMQ and ActiveMQ are queue brokers, and Kafka is a log. Open source is also what lets you buy support independently of the software.
What is the difference between a JMS queue and a JMS topic?
A queue delivers each message to one consumer. A topic delivers a copy to every subscriber. In RabbitMQ a JMS queue becomes a queue, and a JMS topic becomes a topic exchange with one queue per subscriber, which is why durable subscriptions and selectors need mapping during discovery.
What are five common types of middleware?
Message brokers such as RabbitMQ, IBM MQ and ActiveMQ, event streaming such as Kafka, application servers such as Tomcat, integration platforms such as MuleSoft and Boomi, and API gateways such as Kong and Apigee. This page covers the first group: moving legacy middleware solutions for messaging.
What are the top middleware technologies?
By role: for messaging, RabbitMQ, IBM MQ, ActiveMQ, Amazon SQS and Azure Service Bus; for event streaming, Apache Kafka; for application hosting, Apache Tomcat; for integration, MuleSoft and Boomi; for APIs, Kong and Apigee; and for data pipelines, Debezium and Apache NiFi. Which of them are legacy depends on the platform's support position, not its age. MSMQ, older ActiveMQ lines and IBM MQ estates tied to renewal cost are the ones teams most often move, usually to RabbitMQ or Kafka, in phases with both running in parallel.
Who can migrate MSMQ to RabbitMQ?
AceMQ. MSMQ and System.Messaging are .NET Framework only, so moving to modern .NET means rebuilding the queue code anyway, which makes it a natural point to move to RabbitMQ with the .NET client. Transactional queues and distributed transactions are scoped first, because they have no direct equivalent.
Azure Service Bus to self-hosted RabbitMQ: who does the cutover?
AceMQ designs the RabbitMQ topology, maps queues, topics, sessions and peek-lock to the RabbitMQ model, runs the parallel period and cuts over application by application. We will also tell you in discovery if the evidence says to stay on Azure Service Bus.
Can change data capture on Kubernetes replace Kafka Connect?
In some estates, yes. At American National, AceMQ replaced a Kafka-based change data capture pipeline for SQL Server with standalone Debezium publishing directly to RabbitMQ on Kubernetes. It suits flows that do not need Kafka's replay and scale. Flows that do need them stay on Kafka.
How long does a migration take, and what does it cost?
A moderately complex estate typically takes nine to sixteen weeks end to end, and large estates take longer. We scope after discovery, and we do not publish a price list. Tell us what you run and we reply to your quote request within 1 hour.
Let's talk
Scope Your Legacy Messaging Modernization
Tell us which brokers you run, how many applications connect to them and what is driving the move. We will scope the work, including the applications that always get forgotten until cutover, and reply to your quote request within 1 hour.
Get in Touch
Talk to an AceMQ 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.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.