# Zero-downtime cutover
## Steps
1. Get the new cluster fully ready and verified first: data counts, indexes, app smoke tests against it from staging. The cutover is not the time to discover a missing index.
2. Put the new connection string in the secret manager / env config, but do not activate it yet.
3. Freeze or drain writes briefly if the migration needs a final sync (live migration cutover does this anyway).
4. Rolling deploy: restart app instances so they pick up the new string a few at a time. Watch error rates and the new cluster's Connections metric climb while the old one drains.
5. Verify on the new cluster: writes landing, reads correct, latency normal, no auth or pool errors in logs.
6. Keep the old cluster for the retention window (days, not hours). Then decommission.
## Rules
- Never cut every instance at once. A bad string everywhere is a full outage; a bad string on 10% of instances is a rollback.
- Feature-flag the connection string if your platform supports it, so cutover is a flag flip, not a deploy.
- DNS-based cutover (CNAME swap) works but respects TTLs; prefer env-based rolling restarts for precision.
- Have the rollback ready before you start: the old string, still valid, one deploy away.
## Verify
All traffic serves from the new cluster for a full business cycle with clean metrics. Only then delete the old cluster.