Upgrading our unsupported RabbitMQ versions

We're getting an upgrade… literally! This blog covers what unsupported versions are, how these are managed via Scheduled Maintenances and what to expect during these upgrades.

The RabbitMQ core team defines unsupported versions as those that no longer receive patches or official support. As a result, upgrading to the latest versions is strongly recommended. At CloudAMQP, we've supported a wide range of RabbitMQ versions over the years, including some that are no longer officially supported. However, it's time to begin phasing out the most outdated releases, starting with all unsupported versions earlier than 3.13.x.

Over the coming months, we’ll schedule maintenance to upgrade affected clusters. Customers will be notified well in advance, with plenty of time to reach out to our support team for assistance or to discuss specific needs.

In the second half of 2025, the minimum RabbitMQ version available for new cluster creation will be the latest 3.13.x release. Please note that future versions, especially the upcoming 4.x, may introduce breaking changes and could require additional migration steps. For more information on this, check out our blog series about this here.

An important thing to note is that it is not possible to downgrade versions. If you need to stay on a specific unsupported version, please contact CloudAMQP support.

About Scheduled Maintenances (how to run or reschedule)

Scheduled maintenance is created and managed by the CloudAMQP team to keep servers up to date. There is a scheduled window set to run the maintenance, and a Required By date for when customers can reschedule the maintenance before this time. Please note that times are in UTC.

Customers can view details of the upcoming upgrades via the Scheduled Maintenance tab in the CloudAMQP Console. This is where maintenance can be rescheduled or triggered to run early. Contact the CloudAMQP Support team if you need to reschedule outside of the allocated time, and we can adjust this to suit customer needs.

An important thing to note is that it is not possible to downgrade versions. If you require to stay on a specific unsupported version, please contact CloudAMQP support.

About Scheduled Maintenances (how to run or reschedule)

Scheduled maintenance are created and managed by the CloudAMQP team to keep servers up to date. There is a scheduled window set to run the maintenance and a Required By date for when customers can reschedule the maintenance before this time. Please note that times are in UTC.

Customers can set a preferred time to run all scheduled maintenance specific to each instance. Please refer to our blog about this here.

We recommend that customers update their Notice Alarm settings with the correct notification recipients to stay informed about upcoming maintenance. The system sends alerts when maintenance is scheduled, one hour before it begins, and at the start of the maintenance. Please make sure your contact details are current to ensure you receive all notifications.

What to expect during upgrades

There are a couple of notable things about these upgrades:

Depending on the server’s current RabbitMQ version, it may require multiple version upgrades to reach version 3.13.x.
We expect these unsupported upgrades to take approximately 20 minutes to complete.
Please note that any custom plugins installed will be disabled upon upgrading, and customers will need to contact CloudAMQP support to have these reinstalled.
Customers running TLS v1.0 and v1.1 must also contact support to enable these.

Expected Downtime

An upgrade requires a restart of RabbitMQ. This means any connections attached will close and will need to be reconnected. We recommend ensuring clients can handle reconnecting to brokers.

There is expected downtime during an upgrade when RabbitMQ restarts; however, this can depend on your cluster setup:

Single clusters

All single-node upgrades will require a couple of minutes of downtime upon restart. This can take longer if there are a very large number of virtual hosts, queues, or messages in the queues at the time of restart.

Multinode clusters

Version upgrades from 3.9.x will be rolling upgrades, advantageous for multinode clusters. They will be handled in a rolling fashion so that each node will be updated in turn, and the cluster as a whole should remain accessible to clients.

We recommend that clients point to the general cluster hostname (DNS load balancer) instead of individual nodes, as that should ensure that an online server node will resolve any connection requests.

Upgrade without downtime

If customers cannot afford downtime, we recommend the blue-green deployment strategy. This entails creating a new instance with the desired RabbitMQ version and migrating clients over. If there are any issues, customers can revert clients back to the previous instance.

Create a new instance
Export definitions from old instance (if on a dedicated instance)
Import definitions to new instance (if on a dedicated instance)
Point your publishers to the new instance
Allow consumers to empty the queues on the old instance
Move consumers to the new instance
Finish up by deleting the old instance

Utilising RabbitMQ queue federation can efficiently assist with migrating to another instance without stopping all producers and consumers, as it transfers messages with ease. Please refer to our documentation on this here. If downtime takes too long, please email CloudAMQP support.

Tips to ensure upgrades go smoothly:

Keeping messages low, recommended under 1,000,000 msg to avoid long sync times.
If customers have a specific time of day where clusters experience low traffic, we recommend rescheduling upgrades during these times.
Ensure messages are persistent and on durable queues.
Auto delete queues (queues that are marked AD) will be deleted during the update.
Ensure Notice alarm recipients are able to receive notifications.