Database Migration Cutover Checklist
A cutover checklist for switching production from a source to a migrated target database. It covers replication parity, write freezes, parity checks, smoke tests, and a tested rollback path. Use it to keep the highest-risk step of any database migration short and reversible.
When to Use This Checklist
A database cutover is the moment you switch production from the old database to the new one. It is short, high-stakes, and hard to undo. Use this checklist when you have already migrated and validated data into a target database and are ready to move live traffic. It applies to engine swaps (Oracle to PostgreSQL), version upgrades, and lift-and-shift moves to managed cloud databases.
How to Use This Checklist
Work through the items in order during a planned maintenance window. Assign each item an owner before the window opens. Treat every required item as a gate: if it fails, stop and decide whether to continue or roll back. The optional items improve safety and observability but should not block a healthy cutover.
Rehearse the full sequence in a staging environment at least once. A dry run reveals missing permissions, slow checksum queries, and incorrect connection strings before they cost you production downtime.
What Good Looks Like
A clean cutover finishes inside its window with replication lag at zero, matching row counts and checksums, and green smoke tests on the target. Monitoring is live before traffic arrives, so the first slow query or error spike is visible immediately. The source database stays read-only and reachable, giving you a tested escape hatch for the agreed rollback window. Every timestamp and decision is written down, so the post-cutover review is based on facts, not memory.
Common Pitfalls
The most common failure is cutting over while replication is still catching up, which silently drops recent writes. Another is forgetting downstream consumers: scheduled jobs, ETL feeds, and CDC pipelines that still point at the old database after the application has moved. Teams also underestimate connection-pool and timeout differences between engines, so the application works in tests but stalls under real load. Finally, many cutovers have no real rollback plan, only a hope that nothing breaks. Define the rollback trigger and steps before you start.
Related Resources
Pair this checklist with blue-green deployment and the expand-and-contract migration pattern to reduce cutover risk, and lean on data-quality-management practices to design the parity checks. Review incident-management-best-practices so the on-call team knows how to respond if the window goes sideways.