Two brokers, one workload, and a version that had run out of support
RabbitMQ
KubernetesThe institution moved from two brokers on unsupported versions to a single sized, supported RabbitMQ platform with a documented cutover, and its own team trained to operate it.
Overview
The institution streamed events out of its student information system to downstream cloud services. That traffic was split across an ActiveMQ deployment and a RabbitMQ cluster several minor versions behind its supported line.
Challenge
Consolidating onto RabbitMQ was expected to roughly double the load on the surviving cluster, so sizing could not simply be inherited. The existing version was past the point where community support applied, which made the upgrade and the migration the same project.
Environment
RabbitMQ on a Kubernetes platform alongside a separate ActiveMQ estate, carrying event traffic from a student information system to cloud consumers.
Approach
AceMQ ran a full architecture assessment across both brokers rather than a like-for-like port. That covered current and post-migration sizing, the upgrade path off the unsupported version, whether to stand up a parallel cluster to allow a staged cutover, and where quorum queues change the durability story.
Solution
- 1Architecture assessment across both the ActiveMQ and RabbitMQ estates
- 2Capacity sizing for the consolidated workload, not the current one
- 3Upgrade path off the out-of-support RabbitMQ version
- 4Parallel-cluster strategy to allow staged cutover without a hard switch
- 5Kubernetes topology, anti-affinity and failover design
- 6Operations training so the platform team runs it after handover
Outcome
The institution moved from two brokers on unsupported versions to a single sized, supported RabbitMQ platform with a documented cutover, and its own team trained to operate it.
Technologies
RabbitMQKubernetesRelated Use Cases
Enterprise Migration from IBM MQ to Kafka and RabbitMQ
AceMQ advises enterprises transitioning IBM MQ workloads to modern messaging platforms, routing workloads to Kafka for event streaming or RabbitMQ for transactional messaging based on specific use case requirements.
Stabilizing RabbitMQ on Kubernetes for Mission-Critical Airport Systems
Troubleshooting cluster failover, partition handling, and quorum queue issues in a high-stakes aviation operational environment.
Ready for a ActiveMQ Health Check?
AceMQ's senior ActiveMQ engineers have handled this exact type of engagement before. Whether you need architectural guidance, hands-on remediation, or an ongoing managed partnership, we're ready to help.