Two brokers, one workload, and a version that had run out of support
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.
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
RabbitMQ
KubernetesRelated 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.
Boomi and RabbitMQ Disaster Recovery and Message Replay
A Boomi integration estate depended on RabbitMQ with no automated failover and no way to replay messages after an outage. AceMQ designed the DR model and the replay path, both under audit constraints.
MuleSoft Integration Estate Assessment
Inventorying and evaluating a MuleSoft estate for reliability, error handling, and reuse before committing to either investment or migration.
IBM MQ to RabbitMQ Migration for Insurance Carrier
AceMQ led the phased migration of American National Insurance's IBM MQ infrastructure to RabbitMQ, including legacy code refactoring and HIPAA-compliant data handling across Windows and mainframe queue environments.
Replacing Kafka with Debezium + RabbitMQ for Change Data Capture
American National Insurance replaced a Kafka-based CDC pipeline with a standalone Debezium + RabbitMQ architecture, simplifying operations while maintaining SQL Server change capture with improved message routing flexibility.
Ready for an 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.