Zero-Downtime Database Migration Checklist
A checklist for migrating a production database with no downtime using dual-write, change data capture, and gradual traffic shifting. It emphasizes additive schema changes, continuous reconciliation, and reversible cutover steps. Use it for systems that cannot take a maintenance window.
When to Use This Checklist
Use this checklist when a database migration cannot take a maintenance window. High-traffic systems, global services, and revenue-critical workloads often require continuous availability. Zero-downtime migration relies on running source and target in parallel, keeping them in sync, and shifting traffic gradually so the change is invisible to users.
How to Use This Checklist
The approach centers on three techniques: expand-and-contract schema changes, change data capture to keep the target current, and gradual traffic shifting controlled by feature flags. Work the planning items first to confirm the application can support dual-write and additive-only schema evolution. Then set up CDC, backfill, and reconciliation before shifting any traffic. Every traffic shift is a small, reversible step gated by health metrics, not a single switch.
What Good Looks Like
A successful zero-downtime migration shows steady, low replication lag and continuous reconciliation that confirms parity throughout. Read traffic is shadowed and compared before any writes move. Write traffic shifts in small increments, each watched for error and latency regressions, with a feature flag ready to reverse instantly. Schema changes are additive until a stable soak period passes, after which deprecated structures are cleaned up. Users never notice the migration happened.
Common Pitfalls
The most dangerous mistake is a destructive schema change during the window, which breaks the still-live source. Teams also shift writes before reconciliation proves parity, propagating errors into the target. Ignoring replication lag leads to stale reads and lost writes at cutover. Without idempotency, retries during the shift create duplicates. Finally, dropping the dual-write path or old columns too early removes the rollback option before the new path has earned trust.
Related Resources
Lean on the expand-and-contract-migration-pattern for safe schema evolution, and use canary-release-best-practices and feature-flag-best-practices to control traffic shifts. Pair with blue-green-deployment thinking and data-quality-management for continuous reconciliation.