Classic to quorum queue: what changes for your queue

Pick a classic queue from your definitions, or type its arguments, and see argument by argument what works the same on a quorum queue, what behaves differently and what a quorum queue refuses. You get the declare arguments for the quorum version and the steps to move the messages. Checked against the quorum queue docs and a real RabbitMQ 4.3.6.

Your definitions export (definitions.json)

Open file

It runs in your browser; nothing is sent anywhere. Users, password hashes and permissions in the file are ignored. The export stays in this browser tab, so the other three tools pick it up without pasting it again.

Queue from the definitions

Queue name

Properties

durable exclusive auto_delete

Arguments (JSON)

Consumers use global QoS (basic_qos global=True) A consumer subscribes with exclusive=True

Moving a queue to quorum

The type cannot change in place. x-queue-type is fixed when a queue is declared, and a policy cannot set it; redeclaring the same name with another type fails with PRECONDITION_FAILED inequivalent arg 'x-queue-type'.
New name, or blue/green. Either declare the quorum queue under a new name, bind it like the old one, switch the consumers, and drain the old queue; or build a new vhost or cluster whose default queue type is quorum (rabbitmqctl update_vhost_metadata <vhost> --default-queue-type=quorum) and move the applications over.
Move what is left with a shovel from the old queue to the new one, then delete the old queue once it is empty.
Set limits by policy, not in code: delivery-limit, dead-letter-exchange and length limits can be changed later without touching the queue. Keep quorum-only keys in a policy with apply-to: quorum_queues: on RabbitMQ 4.3.6 a policy that contains delivery-limit is not applied to classic queues at all. The policy generator writes one for you.

Sources: quorum queues, feature matrix, migrating mirrored classic queues to quorum queues, policies.