The three phases

        EXPAND                 MIGRATE code              CONTRACT
   ┌────────────────┐      ┌──────────────────┐     ┌────────────────┐
   │ add new schema │      │ deploy new code  │     │ remove old     │
   │ (additive,     │ ───▶ │ backfill data    │ ──▶ │ schema         │
   │  backward-     │      │ dual-write       │     │ (now unused)   │
   │  compatible)   │      │                  │     │                │
   └────────────────┘      └──────────────────┘     └────────────────┘
   old code still works    both work side by side    only new code remains

Expand — Make a purely additive change. New columns/tables are nullable or
defaulted so existing code, which doesn't know about them, keeps working unchanged.
Migrate — Deploy code that writes both the old and new shapes (dual-write) and
backfill the historical rows. By the end of this phase every row is populated and every
running app instance is on the new release.
Contract — Now that nothing reads or writes the old shape, remove it: drop the
column, drop the default, tighten constraints.

The gap between Expand and Contract is the whole trick. It's what lets a rolling deploy —
where old and new pods overlap — happen without a single failed request.

Included with Database Migration Toolkit

Ready for the complete Database Migration Toolkit?