Keeping community RabbitMQ patched after leaving Tanzu

Tanzu RabbitMQ is licensed by CPU core count with minimum commitments, so the bill tracks the size of the hosts rather than the support used. For mid-size clusters that is hard to justify at renewal. The alternative, the community build under the Mozilla Public License 2.0, has a different catch: once a series leaves community support, its patch releases go only to Broadcom's commercial customers.

So the exit has two parts that run on different clocks. Procurement wants a decision before the renewal date. Engineering needs time to list the Tanzu-specific features in use, test community builds against the applications and move clusters without dropping messages. The broker has to stay patched through all of it, including the Erlang/OTP runtime underneath.

RabbitMQ on a Tanzu distribution, on virtual machines or Kubernetes, heading toward community RabbitMQ. Some clusters use Tanzu-only features; others run plain broker configuration that would work unchanged on a community build.

Versions range from 3.12 or 3.13 to the 4.x line, and each cluster has its own application owners and its own change calendar. Many of the older clusters also carry the classic mirrored queues that RabbitMQ 4.0 removed, so the exit and the 4.x upgrade are easy to confuse. They are separate decisions: a cluster can leave Tanzu on 3.13 and move to quorum queues later.

Renew Tanzu RabbitMQ. Broadcom's commercial support covers 3.13 until 31 December 2029 and includes the Tanzu feature set. It is the simplest path if the estate uses those features heavily and the licence cost fits.

Move to community RabbitMQ with no support contract. The licence costs nothing, but there is no SLA, and fixes for older series are not public.

Move to community RabbitMQ with third-party support. The broker becomes community RabbitMQ, and a provider supplies patched builds for the versions you run, current and end of life, while the migration happens.

Change brokers entirely. Sometimes right for new systems, but a broker swap touches every client, and that is rarely worth doing just to leave a licence.

OSSeva covers community RabbitMQ from the first day of the exit, on 3.8.x through 4.3.x, with patched builds for the series that are out of community support. Patches are applied to upstream community source and delivered as signed Helm charts, OCI images or Maven artifacts through your registry, with the matching Erlang/OTP release patched alongside.

The migration starts with a fixed-price discovery engagement that sizes the work before any commitment, listing which Tanzu-specific configuration extensions each cluster uses. For most Tanzu customers the migration is a configuration change and a cluster migration, planned to avoid downtime. Where a Tanzu-only feature has no direct community equivalent, OSSeva Assure designs the replacement, alongside version upgrade planning and a reference architecture.

Clusters move one at a time, and each one runs patched community RabbitMQ from the moment it leaves Tanzu. OSSeva Operate can run the migrated clusters on your own infrastructure with 24/7 monitoring and a 15-minute P1 incident response SLA.