The short answer
Classic mirrored queues were deprecated in RabbitMQ 3.9 and removed in 4.0, so replicated queues must move to quorum queues before upgrading. RabbitMQ describes a blue-green migration to a new cluster as the approach. Quorum queues cover the features of durable mirrored queues, but are not suitable for temporary queues used in request-reply.
RabbitMQ 4.0 removed classic queue mirroring. Mirrored classic queues had been deprecated since 3.9 [1], so the removal was well signposted — but plenty of production estates still run them, and for those estates 4.0 is not an upgrade until the queues have moved.
What replaces them
For replicated queues, the replacement is the quorum queue. RabbitMQ's guidance is to move to quorum queues, or to a combination of quorum and classic queues where a workload does not need replication [1]. Non-replicated workloads can stay on classic queues; it is the mirroring that has gone, not the classic queue type.
The one case quorum queues do not cover
Quorum queues support the features of durable mirrored classic queues, with one exception RabbitMQ calls out: they are not suitable for the temporary queues used in request-reply communication [1]. That is the item to inventory first. RPC-style patterns that create short-lived queues need a different design, and they are easy to miss because they are created by application code rather than declared in a definitions file.
Why the migration is usually blue-green
The approach RabbitMQ describes is a blue-green deployment: applications move from the existing cluster with mirrored queues to a new cluster, rather than queues being converted in place [1]. The same post notes that definitions exported from the old cluster can be transformed to declare quorum queues automatically with rabbitmqadmin v2 [1].
Blue-green turns a risky in-place change into a controlled cutover, but it moves the hard work into application routing. Every producer and consumer has to be pointed at the new cluster, in an order that does not strand messages. That sequencing is the actual project.
The wider point
Deprecations give years of warning and still arrive as emergencies, because the work they demand is unglamorous inventory: which queues are mirrored, what creates temporary queues, which applications connect where. The teams that upgrade smoothly are the ones that did the inventory before the version mattered.
Sources
- [1] RabbitMQ, Migrating from Classic Mirrored Queues to Quorum Queues in 2025. Published 29 July 2025.Primary source
Related questions
Are classic mirrored queues still supported in RabbitMQ 4.0?
No. Classic mirrored queues were deprecated in RabbitMQ 3.9 and removed in 4.0. Replicated queues need to move to quorum queues before upgrading; non-replicated workloads can remain on classic queues.
How do you migrate from mirrored classic queues to quorum queues?
RabbitMQ describes a blue-green deployment: applications move from the old cluster to a new one that declares quorum queues, rather than queues being converted in place. Exported definitions can be transformed with rabbitmqadmin v2. Temporary queues used for request-reply need a separate design.