Limits of EF Core reversible migrations after schema changes

Direct answer

EF Core 7.0 does not offer a rollback dry-run or a data-restore guarantee. The scaffolder emits a Down method only for structural operations whose inverse is fully derivable from the model snapshot—typically table create/drop, column add/drop, and index or constraint changes. Renames, type conversions, data movement, and hand-written migrationBuilder.Sql calls are not inferred and usually require manual Down code. A Down method that compiles is not proof that the rollback restores the original schema or data.

Which changes are automatically reversible?

There is no stable public matrix. In practice, the scaffolder inverts operations when the prior snapshot contains the complete definition: creating a table is reversed by dropping it, adding a column is reversed by dropping it, and index/constraint changes are usually inverted. Renames are generally not detected because the scaffolder diffs the model, not the Up method; a renamed column appears as a drop plus an add unless you hand-edit both directions.

What protects data when a column is dropped?

Nothing built-in. The generated Down can re-create the column with the same type, nullability, and default from the previous snapshot, but the original row values are gone unless you archived them beforehand. The supported mitigation is to copy the affected data into an archive table or column in the same migration before the drop, and to write Down so it restores from that archive.

How to preview and test the rollback

There is no framework dry-run, but you can generate the downgrade SQL and rehearse it on a disposable copy:

1. Confirm the migration IDs with dotnet ef migrations list.
2. On a restored copy of the database, apply the upgrade.
3. Generate the rollback script:

   dotnet ef migrations script --from <after-migration> --to <before-migration>

   and inspect it.
4. Execute that script on the copy and compare schema, row counts, and checksums for affected tables against a pre-upgrade baseline.

Recommended pattern

Use expand/contract migrations: add the new shape, backfill or archive data, then remove the old shape in a later migration. Keep Down focused on structural reversal and explicit data restoration. Avoid placing destructive schema changes in the same automated rollback path as application deployment.

Missing detail: if your Up contains raw SQL or bulk data transformations, the generated Down is especially likely to be incomplete; confirm whether those are present, because that determines whether hand-written Down logic is mandatory rather than optional.