Database Migration Guide: Zero-Downtime Patterns Businesses Need

Application migrations fail most often at the database. Schema changes, long locks, and partial data move cause outages that marketing pages never mention. Product companies need expand/contract discipline and measurable cutovers.

Expand / contract (the default)

1. Expand — add new columns/tables; keep old ones
2. Deploy code that writes both (or reads new with fallback)
3. Backfill historical data in batches
4. Switch reads to new shape
5. Contract — remove old columns after confidence window

Never deploy a breaking schema change in the same release as the only code that understands it—unless you accept downtime.

Dual-write and CDC

For store migrations (e.g., monolith DB → service DB), dual-write or change-data-capture keeps systems in sync. Always design for idempotency and conflict rules.

Validation checklist

• Row counts and checksums per partition
• Business invariants (balances, unique constraints)
• Shadow reads comparing old vs new for a sample
• Backup + restore drill before irreversible drops

Performance traps

• Full table rewrites on huge tables without online tools
• Missing indexes on new query paths
• ORM migrations run manually in production without review

Ownership

Data migrations need a named owner, a runbook, and a business approver for freeze windows. Treat them like product launches.

Frequently asked questions

Can we migrate without downtime?

Often yes for additive changes and dual-run strategies. True zero downtime for every storage engine and every constraint is not free—budget engineering time.