RabbitMQ Upgrades Without the Outage

In most clustered deployments, yes. We perform a rolling upgrade one node at a time while the cluster continues serving traffic: the node is put into maintenance mode with rabbitmq-upgrade drain, upgraded, restarted and confirmed back among the running cluster nodes before the next one starts, which requires that your clients handle reconnection correctly and that queue replication is configured to survive a node leaving. Single-node deployments cannot be upgraded without a brief outage — in that case we minimize and schedule the window rather than pretend otherwise.

No, and attempting it is a common cause of failed upgrades. RabbitMQ requires passing through intermediate versions so that feature flags are enabled in the correct order, and 4.x additionally removes classic mirrored queues, which means queue migration must happen before you get there. We map the specific hops your deployment needs — typically 3.8 to 3.11 or 3.12, then 3.13, then 4.x.

Classic mirrored queues are removed in RabbitMQ 4.x, so they must be migrated to quorum queues before that upgrade. Quorum queues behave differently — they are more memory-sensitive, have different member semantics, and handle poison messages differently. We plan the migration including member count sizing and validate application behavior against quorum queues under load before the cutover.

A straightforward single-hop upgrade on a well-understood cluster typically runs three to four weeks end to end, most of which is assessment and rehearsal rather than execution. Multi-hop upgrades from older versions, or upgrades requiring classic-to-quorum migration, commonly run six to ten weeks. The production execution itself is usually the shortest phase.

It substantially reduces risk, and where one does not exist we frequently build a representative environment as part of the engagement. Matching production exactly is rarely necessary — what matters is matching queue types, approximate message volumes, and client behavior, because those are what surface upgrade problems. A non-production environment with different queue types tells you very little.

Every step in the runbook has a tested rollback, validated during rehearsal rather than assumed. If a validation check fails during production execution, we stop and roll back to the last known-good state rather than pushing forward. This is precisely why the rehearsal phase exists — most upgrade failures we are called in to recover from happened because there was no tested rollback at the point of failure.

Yes. AceMQ is the Broadcom VMware Expert Advantage Partner of the Year for the Americas, and we support both open-source RabbitMQ and Tanzu RabbitMQ upgrades. For Tanzu deployments we also handle Cluster Operator upgrades, entitlement and licensing questions, and coordination with Broadcom support where an issue needs to go upstream.

The metadata store. From 4.3.0 RabbitMQ supports only the Raft-based Khepri metadata store; Mnesia was removed, and the old partition handling strategies went with it, so cluster_partition_handling now has no effect and should come out of rabbitmq.conf. Metadata, quorum queues and streams all follow Raft majority rules on 4.3, which is why we rehearse the move to 4.3 against a copy of your real definitions rather than an empty cluster.

Every patch release in your series, as it ships. RabbitMQ publishes patch releases within a series often: the 4.3 series went from 4.3.0 on 23 April 2026 to 4.3.6 on 16 September 2026, seven releases in under five months. Patches install as a rolling node-by-node change with the cluster serving traffic, so they belong in a routine monthly window rather than waiting for the next major upgrade.

As of 22 October 2026, only the 4.4 and 4.3 series are inside community support, until 31 July 2027 and 31 January 2027. Community support ended for 4.2 on 31 July 2026, for 4.1 on 31 January 2026 and for 3.13 on 30 September 2024. Those series still receive patches under a commercial license: the project lists commercial support for 4.2 to 30 June 2030 and for 3.13 to 31 December 2029, and shipped 4.2.11 on 16 September 2026, after 4.2's community window closed. The full series-by-series table is in our RabbitMQ end-of-life guide.

Yes. If the series is still inside commercial support, we license and apply the patch releases the project ships for it. If it is past that, as 3.8 to 3.12 are, our extended LTS support backports CVE fixes to the exact build you run, so the upgrade can wait for a proper window without leaving known vulnerabilities open.

A rolling upgrade upgrades the nodes of one cluster one at a time, which keeps the footprint the same but needs a supported rolling path between the two versions and a cluster that can run with a node down. A blue-green deployment builds a new cluster on the target version, moves consumers and then publishers across, and decommissions the old cluster, which costs temporary extra infrastructure but lets you switch back. It is also the route when the versions cannot be clustered together, such as a 3.13 cluster with Khepri enabled.

Run rabbitmq-diagnostics check_if_any_deprecated_features_are_used on the current cluster; it exits non-zero if a deprecated feature is in use. The current list includes transient non-exclusive queues, global QoS, RAM nodes, management metrics collection and AMQP address v1, and classic queue mirroring was removed in 4.0. Setting deprecated_features.permit.<feature> = false in non-production lets you test the application as if the feature were already gone. Not every feature can be detected at runtime (global QoS cannot), which is why we also review client code.