Messaging and streaming licensing is priced per core or by throughput, and premium connectors/features add up. Open brokers, Apache Kafka, RabbitMQ, NATS, Pulsar (and Kafka-compatible Redpanda), remove the subscription while preserving familiar protocols. The key to a clean migration is bridging so producers and consumers move without message loss.
Two families, not one
Before choosing a target, decide which family the source workload really belongs to, because they are fundamentally different and the mistake is expensive. A distributed log like Kafka keeps an ordered, replayable record of events and lets consumers track their own position, which suits streaming, event pipelines, and replay. A smart broker like RabbitMQ, IBM MQ, TIBCO EMS, or Solace holds state, routes each message, and tracks acknowledgements, which suits queueing, request/reply, and work distribution. A source built on one model does not map cleanly onto the other: strict ordering, transactions, and JMS selectors that feel free on a broker take deliberate design on a log, and high fan-out replay that is natural on a log is awkward on a broker. Split a mixed estate by pattern rather than forcing everything onto one target.
Picking a broker for each pattern
- Kafka (KRaft mode), the default for high-throughput streaming and log/event pipelines. Confluent Platform migrations land here because Confluent is Kafka at the core.
- RabbitMQ, classic queueing/routing (AMQP) for task and work-queue patterns. IBM MQ, TIBCO EMS, and Solace queue workloads map here.
- NATS, lightweight, low-latency pub/sub and request-reply.
- Pulsar / Redpanda, Kafka-API-compatible options with different operational tradeoffs.
Catalog your topics and delivery semantics
Catalog topics/queues, partitions, ACLs, and delivery semantics (ordering, at-least-once vs exactly-once), then baseline throughput and consumer lag.
Bridge, then repoint
Stand up the target cluster and recreate topics/queues + ACLs. Bridge during transition, MirrorMaker 2 for Kafka-to-Kafka, or shovels and small relay services for cross-broker moves such as IBM MQ, EMS, or Solace into RabbitMQ, to replicate messages and offsets. The bridge is what decouples the producer cutover from the consumer cutover, so you are never mid-flight with a half-migrated flow. Then repoint producers first, consumers second, queue or topic family at a time, drain backlogs, and cut over once consumer lag or queue depth reaches zero. A consumer that quietly stayed on the source is the classic way to strand messages after you think you have finished, so reconcile the client inventory before retiring anything.
Proving no message gets lost
Throughput/latency benchmark, delivery-semantics and ordering tests, consumer-failover and replay tests, and a backpressure/soak test. The acceptance bar is “no message loss and ordering/semantics preserved under load.”
Repointing clients
Moving off Confluent is mostly a config change, since the Kafka protocol and client APIs are identical, so producers and consumers usually only change bootstrap servers and security settings. Broker-to-broker moves ask more of the applications: IBM MQ, EMS, and Solace clients repoint onto RabbitMQ over AMQP, and JMS apps can often take the shorter path through RabbitMQ’s JMS client before any deeper refactor. Apps you will keep evolving are worth moving to a native client so they get publisher confirms and fine-grained acking directly, while legacy apps you just need off a license can take the fastest supported route. Whichever path, reproduce the source’s delivery guarantees deliberately with durable queues, persistent messages, confirms, and manual acks rather than assuming they carry over.
Sizing on cores and peak throughput
Bills scale with broker cores/throughput. Self-hosted brokers shift cost to compute + operations, usually far lower at scale. Size on broker cores and peak throughput.
Keep the bridge up until parity holds
Validate semantics on a non-critical topic first, keep the bridge running until parity is confirmed, and don’t decommission the source broker until consumers are stable.
Use the TCO calculator to model a per-core comparison.