On this page
Migrate from RabbitMQ to Kafka when the workload is an event log: streams, fan-out to many readers and replay. Stay on RabbitMQ when it depends on RPC, per-message routing or priority queues, which Kafka does not provide. Most estates split: move the event streams, keep the work queues, and run both through a cutover window.
The pattern that most often decides it is priority. A SaaS analytics customer of AceMQ, on RabbitMQ 3.12, lifted consumption from 500 to 5,000 messages a second during a seasonal traffic peak by using priority queues. Kafka has no per-message priority, so that design has no direct equivalent. The reverse direction, with the same honesty about what ports, is in Kafka to RabbitMQ migration; the broader choice is in RabbitMQ vs Kafka.
Which RabbitMQ patterns map to Kafka, and which do not
| RabbitMQ pattern | Kafka equivalent | Maps? | What you rebuild |
|---|---|---|---|
| Event stream with replay | Topic with a retained log; consumers track offsets | Cleanly | Offsets replace acknowledgements; retention replaces delete-on-ack. |
| Fan-out (fanout or topic exchange to a queue per reader) | One topic, one consumer group per reader | Cleanly | Each group keeps its own offset; no per-reader queue to manage. |
| Work queue with competing consumers | Consumer group, or share groups from Kafka 4.2 | Partly | Parallelism is capped by partition count. Share groups add per-record acknowledgement but are new. |
| Per-message routing (direct, topic, headers exchanges) | Topic per route, or consumers that filter | No | Exchanges and bindings do not exist; routing rules move into producers or consumers. |
| RPC / request-reply | Reply topic plus a correlation id in the application | No | No broker-side reply queue; every caller needs its own reply path and timeout logic. |
| Priority queues | Separate topic per priority | No | Kafka has no per-message priority. RabbitMQ quorum queues offer 32 strict priority levels from 4.3. |
| Per-message TTL, dead-letter exchanges, delayed retry | Retry topics and a dead-letter topic | No | No broker-level equivalent; you write and operate it. |
Share groups reached production readiness in Apache Kafka 4.2.0 (February 2026), so the work-queue row is better than it was a year ago. The rest has not changed.
RabbitMQ to Kafka migration tools compared
| Tool | What it does | What it breaks or costs |
|---|---|---|
| Kafka Connect RabbitMQ source connector (Confluent) | Reads a RabbitMQ queue and writes a Kafka topic | At-least-once, so a restart can duplicate records. Free for 30 days, then a Confluent subscription. Payloads arrive as bytes. One task per queue keeps ordering; shared mode loses it. The queue must already exist. |
| Shovel plus a bridge | Shovel moves messages between AMQP brokers | Kafka is not an AMQP endpoint, so something must sit between them: an extra hop and failure domain to run. |
| Custom consumers or dual-write producers | Your code reads RabbitMQ and produces to Kafka, or writes to both | You own the partition key, idempotency and retries. Dual writes are not atomic, so one can succeed while the other fails and you need reconciliation. |
The connector's documentation does not say how message properties map to Kafka keys, so test key handling before relying on partition ordering. The details are on the Confluent RabbitMQ source connector page.
Dual-run plan and cutover
- Inventory every queue against the table above. Routing, RPC and priority consumers stay on RabbitMQ.
- Bridge the event-stream queues into Kafka topics, with RabbitMQ still authoritative.
- Move consumers to Kafka one group at a time, idempotent, comparing output with the RabbitMQ path.
- Switch producers to Kafka, then drain and delete the bridged queues.
- Remove the bridge on a date agreed in advance. Open-ended overlap becomes a permanent second platform.
Expect months, not weeks. Moves of a RabbitMQ 3.x estate to another platform that we have supported ran for several months, with RabbitMQ support kept in place throughout. Patching the old side matters because 3.x is out of community support; RabbitMQ 3.x extended support covers that window.
Cost of a RabbitMQ to Kafka migration
Use this model: dual-run cost = (RabbitMQ monthly run cost + Kafka monthly run cost) x overlap months + connector subscription + engineering time.
- RabbitMQ side. Infrastructure and patching continue until the last queue drains.
- Kafka side. A production cluster, normally three or more brokers, is billed from day one. Independent Kafka support generally runs about $24,000 to $85,000 a year, so a six-month overlap puts $12,000 to $42,500 of support on top of the RabbitMQ bill.
- Connector. Free for 30 days, then quoted by Confluent.
- Engineering. It scales with consumer count and pattern mix, not message volume. Inventory consumers first.
Kafka support and Kafka consulting from AceMQ cover the Kafka side from the first day of the overlap; what Kafka support costs breaks the contract range down.
When to stay on RabbitMQ and fix the cluster instead
- The system is RPC-heavy, routes per message or leans on priorities.
- The need is replay. RabbitMQ Streams keep an append-only log with non-destructive reads in the broker you already run; see RabbitMQ Streams vs Kafka.
- The complaint is reliability. That is usually configuration, covered in RabbitMQ troubleshooting.
- Scale is modest. An industrial operator we advised in September judged Kafka and Pulsar overkill at its volume, with about 25% data growth expected over five years, and kept RabbitMQ with an upgrade to 4 on quorum queues.
Sources
Frequently Asked Questions
Can Kafka replace RabbitMQ?
For event streams, fan-out and replay, yes. For RPC, per-message routing, priority queues and per-message expiry, not without rebuilding that behavior in application code. Most estates end up with Kafka for the log and RabbitMQ for the work queues. Kafka 4.2 added share groups for queue-style consumption, but it still has no routing or priorities.
What tools migrate RabbitMQ to Kafka?
Three routes exist: the Kafka Connect RabbitMQ source connector, which copies a queue into a topic; Shovel into a bridge, because Kafka is not an AMQP endpoint; and custom consumers or dual-write producers. The connector is at-least-once and needs a Confluent subscription after a 30-day trial.
How long does a RabbitMQ to Kafka migration take?
It depends on consumer count and pattern mix, not on message volume. A handful of event-stream queues can move in weeks. An estate with RPC, routing rules and priority consumers is a multi-quarter program with a dual-run period. Moves off RabbitMQ 3.x that we have supported needed several months of overlap.
Will moving to Kafka fix RabbitMQ reliability problems?
Rarely. Most RabbitMQ reliability problems come from configuration: classic queues where quorum queues belong, memory alarms, over-broad HA policies or an old version. Kafka brings different failure modes, such as rebalances and consumer lag. Fix or assess the RabbitMQ cluster first, then decide whether the workload really is a log.
Author
Talk to an engineer
Need a hand with Kafka?
Senior engineers who run it in production. Get a quote or a free consultation, no sales pitch.
Go deeper on Kafka
- GuideThe Kafka Operations GuideRead the guide
- GuideThe Kafka Buyer's GuideRead the guide
- GuideThe Kafka Monitoring and Alerting GuideRead the guide
- GuideThe Kafka Migration GuideRead the guide
- GuideKafka for AI Agents Without Confluent CloudRead the guide
- ComparisonNATS vs Kafka: Core NATS, JetStream and Kafka ComparedSee the comparison
- ComparisonMosquitto vs Kafka: MQTT Broker or Event Log?See the comparison
- ComparisonKafka vs Kinesis ComparedSee the comparison
- ComparisonSelf-Hosted Kafka vs Managed Cloud KafkaSee the comparison
- ComparisonKafka BYOC (Bring Your Own Cloud) Options ComparedSee the comparison
- ComparisonConfluent Alternatives and Competitors After the IBM AcquisitionSee the comparison
