A commerce platform must change a database schema while an older application version is still running. What migration pattern prevents downtime, and what is the common mistake?

The pattern

Expand, migrate, contract, across several deployments:

1. Expand: add the new column or table. Nothing reads it. Both old and new application versions work.
2. Deploy an application version that writes both old and new shapes and reads the old.
3. Backfill the new shape from existing data, in batches, without locking.
4. Deploy a version that reads the new shape and still writes both.
5. Deploy a version that writes only the new shape.
6. Contract: remove the old column, after confirming nothing reads it.

Each step is independently deployable and reversible, and at no point do the running application versions disagree with the schema.

The common mistake

Compressing the middle steps, particularly deploying a version that reads the new shape before the backfill has completed — which produces null results for old records — or removing the old column while a previous application version is still running somewhere.

A rolling deployment means two application versions run simultaneously by design, and every migration step must be compatible with both. Teams that think of deployment as atomic get this wrong repeatedly.

What makes the backfill safe

• Batched with a bounded rate, so it does not saturate the database or cause replication lag.
• Resumable, since it will be interrupted.
• Idempotent, since it will be re-run over rows it has already processed.
• Monitored for its effect on production latency, with the ability to pause. A backfill that degrades the live workload is a self-inflicted incident, and during a sale period it is a serious one.

The step that is skipped

Contract. Removing the old column requires proving nothing reads it, which is work with no visible benefit, so it is deferred indefinitely. The result is a schema accumulating columns nobody dares remove — and the next migration is harder because the picture is unclear.

Scheduling the contraction with an owner and a date, at the time the expansion is planned, is what prevents it.