Debugging scenarioHard~12 minData Performance & Operations / 12 of 14

Interview question

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.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I separate schema compatibility, data movement, and cleanup into observable steps with owners and stop conditions. Preflight queries measure affected rows and detect values that would fail the new constraint. I test the script on production-like volume, estimate locks and log usage, and monitor database blocking, error rate, and both application versions during rollout. Rollback usually means returning application traffic to a compatible version, not blindly running Down after data was transformed or removed. Backups matter only with a rehearsed restore path and an acceptable recovery window. Destructive cleanup happens after validation and rollback confidence, making the normal release reversible even when the final cleanup is not.

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.

Red flagsCandidateRed flagsSignals that an interviewer may treat as risky.Open details

Details

Cannot identify destructive migration operations.
Has no expand-and-contract strategy.
Ignores existing data and table size.
No rollback or compatibility plan.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

How would you safely rename a column?
How would you backfill a large table?
When would you split a migration across releases?

Continue the section

Next in Data Performance & Operations: Slow EF Query

Step 13 of 14

Investigate a slow EF Core query in production

Opening drill

Debugging scenarioHard~12 minData Performance & Operations / 12 of 14

Interview question

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

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.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I separate schema compatibility, data movement, and cleanup into observable steps with owners and stop conditions. Preflight queries measure affected rows and detect values that would fail the new constraint. I test the script on production-like volume, estimate locks and log usage, and monitor database blocking, error rate, and both application versions during rollout. Rollback usually means returning application traffic to a compatible version, not blindly running Down after data was transformed or removed. Backups matter only with a rehearsed restore path and an acceptable recovery window. Destructive cleanup happens after validation and rollback confidence, making the normal release reversible even when the final cleanup is not.

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.

Red flagsCandidateRed flagsSignals that an interviewer may treat as risky.Open details

Details

Cannot identify destructive migration operations.
Has no expand-and-contract strategy.
Ignores existing data and table size.
No rollback or compatibility plan.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

How would you safely rename a column?
How would you backfill a large table?
When would you split a migration across releases?

Continue the section

Next in Data Performance & Operations: Slow EF Query

Step 13 of 14

Investigate a slow EF Core query in production

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

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