Migration Guide

CloudMQTT Migration

Using Mosquitto on CloudMQTT? RabbitMQ on CloudAMQP could be an alternative

We invite you to read our RabbitMQ 3.12 release blog to learn more about native MQTT support in RabbitMQ 3.12 and its impact on performance and scalability.

RabbitMQ has had MQTT support for a long time, and with RabbitMQ 3.12.0 it's even better. Starting from this release, RabbitMQ supports MQTT natively – it will parse MQTT messages and send them to queues directly without proxying via its core protocol. The results of this new change are really good:

  • More efficient use of memory
  • RabbitMQ can now support millions of MQTT connections

If at this point you are interested in migrating to RabbitMQ on CloudAMQP, you will find our offer and the migration steps below.

CloudAMQP offer - receive 6 months credits

When choosing to migrate to CloudAMQP we can offer you credits covering the first 6 months of an equivalent plan to your current CloudMQTT plan. If you are considering this option, make sure to reach out to the support.

Migration Steps

  1. Setup a CloudAMQP account
    Sign up for a CloudAMQP account, add your billing information and invite your teammates.
  2. Create a RabbitMQ instance
    All plans support MQTT, use RabbitMQ >3.12 for best performance.
  3. Set up custom hostname and certificate
    Optional. If you have IoT devices, we recommend a custom hostname and a custom certificate to ensure you have full control. Easy to configure via the CloudAMQP console.
  4. Migrate users and access control list
    Convert CloudMQTT users and ACLs to RabbitMQ users and permissions. RabbitMQ and Mosquitto are not fully compatible, so you may need to adjust your ACLs.
  5. Link instances
    Optional. Use a bridge to link your CloudMQTT instance with your CloudAMQP instance while migrating clients.
  6. Update your clients
    Update your clients to connect to CloudAMQP.
  7. Delete your CloudMQTT instance


CloudAMQP offers a wider set of features than CloudMQTT that you might find useful.


These CloudMQTT features are unfortunately not available on CloudAMQP.

  • Multiple users and ACLs on the Shared plans
  • ACLs with variables and wildcards
  • AWS Kinesis stream and Mosquitto bridges
    Consider using RabbitMQ shovels, RabbitMQ federation, AWS EventBridge or Webhooks to move messages.
  • MQTT QoS2
    Motivation by the RabbitMQ team to not support QoS2.
  • Limited retained messages functionality
    RabbitMQ does have support for retained messages but comes with some limitations.

MQTT versions

RabbitMQ has supported MQTT 3.1.1 for a long time, and now MQTT 5 is available in RabbitMQ 3.13.

Topics to Exchanges and Queues

With the MQTT protocol, you publish messages to topics and subscribe to topics while with the AMQP protocol, you publish messages to exchanges and subscribe to queues. Which messages are delivered to which queues is determined by the exchange and queue bindings.

When a MQTT client connects to RabbitMQ and subscribes to a topic, RabbitMQ will create a queue for the client and bind it to the exchange. Messages will then be routed to the client's queue and delivered to the client. If the client subscribes to multiple topics more bindings will be added to the queue. If both QoS 0 and 1 are used RabbitMQ will create two queues, one for each QoS.

The default naming schema for MQTT queues are mqtt-subscription-<clientid><qos>.

ACL tips

In mosquitto you have the possiblity to turn on a setting called use_username_as_clientid. This is needed to get a one-to-one relation between authentication and identity. There is no such setting in RabbitMQ, but you can achieve the same result with the following permissions for the user:

configure ^mqtt-subscription-USERNAMEqos[01]$
write ^(mqtt-subscription-USERNAMEqos[01]|amq\.topic)$
read ^mqtt-subscription-USERNAMEqos[01]$

In need of support?

Our support team is here to assist and answer any questions you might have regarding a migration.

E-mail us at support@cloudamqp.com or click the button

Contact Support