> For the complete documentation index, see [llms.txt](https://brightercommand.gitbook.io/paramore-brighter-documentation/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://brightercommand.gitbook.io/paramore-brighter-documentation/transports/rabbitmqconfiguration/rabbitmqmigratetoquorumqueues.md).

# Migrating to Quorum Queues

This guide moves an existing Brighter subscription from a classic queue to a quorum queue, and enables message persistence alongside it.

> **How-to** · Applies to **Brighter V10** · Prerequisites: [RabbitMQ Configuration](/paramore-brighter-documentation/transports/rabbitmqconfiguration.md)

This guide moves an existing Brighter subscription from a classic queue to a quorum queue, and enables message persistence alongside it. It assumes you have already decided that you want quorum queues — if you have not, read [RabbitMQ Durability](/paramore-brighter-documentation/transports/rabbitmqconfiguration/rabbitmqdurability.md) first.

## Before You Migrate to Quorum Queues

Confirm all four of these before you start. The first three are enforced by Brighter at queue creation; the fourth is not enforced anywhere and is the one that quietly costs you the guarantee you are migrating for.

1. **RabbitMQ 3.8 or later**, since that is the release that introduced quorum queues.
2. **`isDurable: true` and `highAvailability: false`** on the subscription. Brighter throws during queue creation if either is wrong — see [RabbitMQ Quorum Queue Requirements](/paramore-brighter-documentation/transports/rabbitmqconfiguration.md#rabbitmq-quorum-queue-requirements) for the full validation rules.
3. **A window in which you can run two subscriptions at once**, because the migration below is a drain rather than a switch.
4. **At least three nodes in the cluster.** Nothing will stop you creating a quorum queue on a single node; it will simply pay the Raft overhead without providing the fault tolerance.

## Migration from Classic to Quorum Queues

To migrate an existing subscription from classic to quorum queues:

1. **Create a new quorum queue** with a different name
2. **Update producers** to publish to the new queue
3. **Deploy new consumers** subscribing to the quorum queue
4. **Drain the classic queue** by processing remaining messages
5. **Remove the classic queue** once drained

Do not attempt to change a classic queue to a quorum queue in place, as this requires deleting and recreating the queue, which would result in message loss.

## Draining the Classic Queue Safely

Step 4 above is the step with a failure mode. Brighter acknowledges a message only once its handler chain has completed, and it holds messages in a per-thread buffer before they reach that chain — so shutting a consumer down mid-drain returns the buffered messages to the classic queue rather than losing them, but it also means the queue is not empty just because the consumer has stopped reporting work.

Check the queue depth in the RabbitMQ Management UI, not the consumer's logs, before you delete anything. The full semantics are in [RabbitMQ Ack and Nack Behaviour](/paramore-brighter-documentation/transports/rabbitmqconfiguration.md#rabbitmq-ack-and-nack-behaviour).

## Enabling Persistent Messages

Quorum queues require durable definitions, so most migrations enable message persistence at the same time. To enable message persistence, set `PersistMessages = true` in your `RmqMessagingGatewayConnection`:

```csharp
// ...
var rmqConnection = new RmqMessagingGatewayConnection
{
    AmpqUri = new AmqpUriSpecification(new Uri("amqp://guest:guest@localhost:5672")),
    Exchange = new Exchange("paramore.brighter.exchange", durable: true),
    PersistMessages = true  // Enable message persistence
};
```

Two follow-up steps are worth doing while you are here:

1. **Set a time-to-live on the messages.** Persistent messages that nothing consumes accumulate on disk indefinitely; a TTL bounds that without needing an operator to intervene.
2. **Test a broker restart.** Persistence is only as good as the recovery you have actually exercised, so restart the broker with messages in flight and confirm they are still there afterwards. Do this on a schedule, not once at migration time.

For the producer- and consumer-side settings that persistence needs, see [RabbitMQ Persistence Options](/paramore-brighter-documentation/transports/rabbitmqconfiguration.md#rabbitmq-persistence-options).

## Further Reading

* [RabbitMQ Durability](/paramore-brighter-documentation/transports/rabbitmqconfiguration/rabbitmqdurability.md) — why you would choose quorum queues or persistence
* [RabbitMQ Configuration](/paramore-brighter-documentation/transports/rabbitmqconfiguration.md) — the parameters this guide sets
* [RabbitMQ Connection Stability](/paramore-brighter-documentation/transports/rabbitmqconfiguration/rabbitmqconnectionstability.md) — retry, heartbeats and blocked connections


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://brightercommand.gitbook.io/paramore-brighter-documentation/transports/rabbitmqconfiguration/rabbitmqmigratetoquorumqueues.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.