The RabbitMQ Migration Guide

The licence line is the smallest part of the comparison. The costs that decide it are dependency mapping, rebuilding integrations, parallel running and cutover risk on the workloads that matter. From IBM MQ, the case is usually cost and modernisation with a long tail of COBOL and JMS integrations to map. From Kafka, it is usually that the workload was never streaming. From a cloud broker, it is control, cost shape or lock-in. Say which one you are in before scoping anything.

Every queue and topic, message sizes and rates, ordering and delivery guarantees actually relied on, consumers and how they retry, dead-letter handling, security and TLS, and the integrations nobody has documented. The readiness checklist exists because most migrations that overrun did so on something that was not on the list.

IBM MQ's queue-manager-to-queue-manager channels, message groups and transactional puts have RabbitMQ equivalents, but not identical ones. Kafka's partitions, consumer groups and replay have no direct counterpart in exchanges and queues, and streams cover only part of the gap. Azure Service Bus sessions, scheduled messages and dead-letter semantics each need an explicit mapping. Write the mapping down per feature; a migration is a translation, and the untranslated words are the incidents.

Do not migrate onto classic queues and plan a second migration to quorum queues later; it never happens on schedule. Design the target with the clustering guide: odd node count across failure domains, quorum queues for durable workloads, policies rather than per-queue arguments, and monitoring in place before the first message arrives.

Migrating classic mirrored queues to quorum queues is its own project: a quorum queue cannot be converted in place, so each is recreated and consumers repointed, usually behind a policy change and a short drain. If a major version upgrade is in the same window, sequence the queue migration and the version hop separately, and confirm the Erlang dependency and feature-flag order before either.

Run source and target side by side, bridge messages between them with a shovel or an application-level relay, move consumers first and producers last, and keep the bridge until the source is drained. Blue-green at the cluster level for version migrations; per-queue or per-service for broker migrations. The bridge is also the rollback: while it runs, moving back is a consumer repoint.

Message counts reconciled across the bridge, latency and throughput measured against the source under real load, the failover test run on the target, and the integrations nobody documented exercised end to end. Only then does the source come down, and only after a definitions export of the target is in version control. A migration is finished when the source is off and nobody noticed.