A release must rename a heavily used database column and ships tonight. The team proposes doing the rename in the deployment. What is wrong, and what do you propose?

What is wrong

A rename is not additive. During a rolling deployment both versions of the application run simultaneously: one expects the old name, one the new. Whichever schema exists, half the fleet is broken for the duration of the rollout.

And it destroys the rollback path. Reverting the deployment leaves old code against a renamed column, so the "safe" response to a bad release becomes a second outage. The team has coupled a schema change and a code change into a single irreversible step.

Propose expand-contract, across releases

Release 1 — expand. Add the new column. Write to both; read from the old. Backfill existing rows in batches. Both application versions work against this schema, so the rollout and any rollback are safe.

Release 2 — migrate reads. Switch reads to the new column, still writing both. Rollback remains safe because the old column is still being maintained.

Release 3 — contract. Once nothing reads the old column and no rollback target does either, drop it.

If tonight is genuinely immovable

Release 1 alone can ship tonight — it is additive and safe. The rename does not complete tonight, and that is the correct outcome to communicate: the deadline constrains what ships, not whether the change is reversible.

If someone insists on the full rename tonight, state the consequences plainly: a window during the rollout where requests fail, and no rollback. If they accept that, it becomes a scheduled outage with a communication plan and a rehearsed forward-fix — not a routine deployment. Make that visible rather than absorbing it.

The step teams get wrong later

Contract. Dropping the old column too early is the usual mistake, because by then the change feels finished. It belongs at least one release after reads move, and it needs evidence rather than reasoning — instrument reads of the old column and drop it only when the count has been zero for a full business cycle, including the monthly and quarterly jobs nobody remembers.

The underlying principle

Deployment and migration must never have to be simultaneous. Every schema change should leave both the current and the previous application version working. That constraint is what makes continuous delivery against a relational store possible at all, rather than an optimisation of it.