An EF Core migration wants to drop a column, rename a column, or make a nullable column required. What would you check before production?

Review a destructive EF Core migration before production

Reviews and stages destructive EF Core schema changes around live data, locks, mixed application versions, recovery, and rollback.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I inspect both the migration operations and generated SQL before production. For a rename, drop, type change, or new NOT NULL constraint, I use an expand-and-contract sequence: add the new compatible shape, deploy code that can work during transition, backfill and validate data, switch reads and writes, and remove the old shape in a later release. I do not combine irreversible cleanup with the first deployment that depends on the new schema.

Full answer below

Practice focus

Migration review, destructive operations, expand-and-contract, backfills, locks, deployment order, and rollback.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
A generated migration is executable code against live data. A harmless-looking rename, constraint, type change, or index operation can discard data, block traffic, or break the overlap between old and new application versions.
I inspect both the migration operations and generated SQL before production. For a rename, drop, type change, or new NOT NULL constraint, I use an expand-and-contract sequence: add the new compatible shape, deploy code that can work during transition, backfill and validate data, switch reads and writes, and remove the old shape in a later release. I do not combine irreversible cleanup with the first deployment that depends on the new schema.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
The review includes current data quality, table size, lock behavior, transaction-log growth, deployment order, and how long old and new app instances overlap. A nullable-to-required change needs a validated backfill before the constraint. A rename must be represented explicitly so EF does not generate drop-and-add. Large backfills run in bounded batches with progress and restartability, while expensive indexes use the database's safe online or staged options where available. Production receives a reviewed script rather than an automatic startup surprise.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Trusting generated migrations without reading them.
Dropping or renaming columns in the same deployment that changes code.
Adding NOT NULL before existing rows are backfilled.
Running a huge backfill as one blocking operation.

An EF Core migration wants to drop a column, rename a column, or make a nullable column required. What would you check before production?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section

Tech stacks

Skill areas

Suggest an improvement