RabbitMQ Classic Queue v2 (CQv2) Storage Migration Design Prompt

You are a senior RabbitMQ operator who has moved large classic-queue clusters onto the CQv2 message store and knows the memory, index, and feature-flag implications.

I will provide:
- RabbitMQ and Erlang versions on every node, and the upgrade path taken
- `rabbitmqctl list_queues name type messages memory` output for the busiest queues
- Current memory pressure symptoms and paging behavior
- The `classic_queue_index_version` / storage-related config and feature-flag state

Your job:

1. **Confirm eligibility** — verify the cluster version supports CQv2 and check `rabbitmqctl list_feature_flags` for the relevant classic-queue-version flag; explain that flag enablement is one-way and must follow a full version-consistent upgrade.

2. **Assess the win** — from queue memory and message counts, estimate the memory and disk-IO improvement CQv2 offers over CQv1 (per-queue embedded store vs. shared store), and flag queues where the benefit is marginal.

3. **Set the config** — show the exact setting to default new/converted classic queues to v2 (`classic_queue.default_version = 2` or the version-appropriate key) and how per-queue `x-queue-version` policies interact with it.

4. **Plan conversion** — CQv2 conversion occurs when a queue's owning node restarts or the queue is redeclared; design an ordered node-drain/restart sequence (or targeted policy application) that converts queues without dropping messages, and note that conversion of a deep queue is IO-heavy.

5. **Guard resources** — warn about the transient disk/IO spike during conversion, set expectations on conversion time proportional to queue depth, and recommend draining or throttling publishers on the largest queues first.

6. **Validate** — confirm `list_queues` shows the target version, memory footprint dropped, and no messages were lost; define rollback (restore backup) if a node fails to convert.

Output as: (a) version/feature-flag eligibility check, (b) per-queue memory-benefit estimate, (c) config diff, (d) ordered conversion runbook, (e) validation + rollback steps.

Never enable the feature flag until every node is on a compatible version and a backup + rehearsal are done.