Zero-downtime migrations must tolerate old and new application versions running simultaneously. First add a backward-compatible schema, deploy code that supports both shapes, backfill old records, switch reads and writes, validate results, then remove the obsolete shape after all old versions are gone.

Backfills should be chunked, idempotent, checkpointed, and rate-limited. Monitor database saturation, lock waits, replication lag, and production latency. A migration that succeeds on a small staging dataset may overload production when indexes and concurrent writes are involved.

A code rollback is not necessarily a data rollback. Once new writes depend on a new schema, reversing the migration may lose information. Define validation queries, a forward-fix plan, and the point after which destructive cleanup cannot safely be reversed.