Review an EF Core migration as a database change before applying it. A property rename can generate a column drop and add, deleting the values you intended to keep.

Keep each migration focused on one logical database change you can explain. If a rename comes with unrelated indexes and seed-data edits, split the work so the reviewer can see why each operation belongs.

Check the generated operations

Suppose you rename Customers.Nickname to DisplayName without changing its type or meaning. If EF Core generates DropColumn and AddColumn, replace them with a rename in Up:

migrationBuilder.RenameColumn(
    name: "Nickname",
    table: "Customers",
    newName: "DisplayName");

Make Down perform the reverse rename. Review the model snapshot diff too: it should reflect the intended model change. EF Core cannot reliably infer rename intent. Its migration guidance explicitly calls for reviewing generated code.

Review the SQL you will deploy

Generate a script for the intended migration range:

dotnet ef migrations script PreviousMigration RenameCustomerNickname --output migration.sql

Replace both names with your actual migrations. For this normal, non-idempotent range script, the starting migration should be the last migration already applied to the target database. Inspect the SQL generated by your configured provider, then test it against a representative test database with realistic data volume. Microsoft recommends SQL scripts when deployment requires SQL review before execution.

In the review, answer:

  • Are any columns dropped, types narrowed, or nullable columns made required? What happens to existing values?
  • Could an index build or data update hold locks long enough to disrupt requests?
  • Can the previous application version still run after this change?

Include deployment order in the review

A rename preserves data but breaks an old application that still queries Nickname. If old and new instances overlap, plan an additive transition: introduce the new column, keep writes consistent while backfilling and switching readers, and remove the old column only after its users have gone. That may require several releases.

For a coordinated maintenance window, a direct rename can be appropriate. Record that requirement in the pull request.

Apply this level of review before a migration reaches a database with data worth keeping. A migration used only with a disposable local database can follow a simpler loop. For shared environments, include deployment order and recovery steps; a Down method cannot restore values discarded by a destructive change.