RabbitMQ to Amazon MQ Migration: The Checklist Nobody Gives You

Amazon MQ for RabbitMQ sounds straightforward — “it’s just managed RabbitMQ.” Until you hit the first incompatibility. And the second. And the third.

I’ve run enough of these migrations to know that the official docs technically mention all the gotchas — but they bury them in places nobody reads until something breaks. Here’s the checklist I wish I’d had on day one.

Things That Will Bite You (Know Before You Start)

• Amazon MQ supports RabbitMQ version 3.12 by default
• Amazon MQ does not support quorum queues
• Amazon MQ does not support streams
• Amazon MQ does not support structured logging in JSON
• The username guest is automatically removed — if anything authenticates as guest, it will break silently
• Default plugins included: management, shovel, federation, and consistent hash exchange
• Classic Queue v2 should be enabled for your broker

If your on-premises setup relies on quorum queues or streams, you need to redesign before migration — not during.

Environment Preparation

Organization

• In which AWS account will the Amazon MQ cluster be deployed?
• Should the cluster be accessible from other accounts? (cross-account patterns add VPC endpoint complexity)

Network

Work through these questions methodically:

• Identify all network exchanges between the MQ cluster and consuming workloads
• Cross-account traffic? Document the reason and motivations
• Cross-region traffic? Document latency requirements
• Cross-AZ traffic? (Typically for HA/replication)
• Do you need VPC endpoints?

Security

• How do you authenticate today — username/password or certificates?
• How will you migrate users and privileges? (Export definitions: cloudamqp.com/docs/cloudamqp-definitions.html)
• How should the cluster be accessed? Define security group rules.
• How will you access the RabbitMQ management console in AWS?

Performance

• Double-check that the supported instance types match your throughput requirements
• Benchmark your current message rates and compare with Amazon MQ limits

Monitoring

• Use Amazon MQ’s automatic CloudWatch dashboard
• Set up CloudWatch alarms for queue depth, message rates, and consumer lag
• Familiarize yourself with CloudWatch metrics for Amazon MQ

Operations

Amazon MQ deployment can be automated through:

• CDK (recommended for new projects)
• CloudFormation
• Terraform (aws_mq_broker resource)

Migration Preparation

Discovery

• Get the list of enabled plugins on-premises (compare with what Amazon MQ supports)
• Document the RabbitMQ topology: number of nodes, versions, in-memory vs. disk nodes
• Identify if you want all-or-nothing or workload-by-workload migration with message replication

Strategy Decision

Best Practices

• Enable Classic Queue v2 for your broker
• Configure applications to automatically recover from network failures
• Do not delete queue policies — Amazon MQ manages some internally
• Review the official migration guide

Cost Assessment

• Use AWS Pricing Calculator to estimate costs
• Factor in: broker instance hours, storage, data transfer (especially cross-AZ and cross-region)
• Compare with your current TCO including: hardware, OS licenses, operational burden, patching downtime

The Migration Itself

1. Deploy target Amazon MQ broker with matching configuration
2. Export definitions from source cluster (exchanges, queues, bindings, users)
3. Import definitions into Amazon MQ (adjust for unsupported features)
4. Set up shovel or federation for message replication during transition (if workload-by-workload)
5. Redirect producers first — point them at the new broker
6. Drain old queues — consumers process remaining messages
7. Redirect consumers — point them at the new broker
8. Validate — message rates, consumer lag, no dead-letter accumulation
9. Decommission old cluster

Key Takeaways

• “Managed RabbitMQ” doesn’t mean “drop-in replacement” — Amazon MQ has specific limitations
• No quorum queues, no streams — if you use these, redesign first
• The guest user deletion catches everyone the first time
• Migrate definitions (topology) separately from messages
• Use shovel/federation for zero-downtime transitions
• Automate the broker deployment from day one — CDK or Terraform, never ClickOps

Any opinions in this article are my own.