Recovering Safely From Failed EF Core Migrations in Production

public partial class AddEmployeeDetails : Migration
{
    protected override void Up(MigrationBuilder migrationBuilder)
    {
        migrationBuilder.AddColumn<string>(
            name: "Department",
            table: "Employees",
            type: "nvarchar(100)",
            nullable: true);

        migrationBuilder.CreateIndex(
            name: "IX_Employees_Department",
            table: "Employees",
            column: "Department");
    }
}

SELECT *
FROM __EFMigrationsHistory
ORDER BY MigrationId;

SELECT COLUMN_NAME, DATA_TYPE
FROM INFORMATION_SCHEMA.COLUMNS
WHERE TABLE_NAME = 'Employees';

SELECT
    name,
    type_desc
FROM sys.indexes
WHERE object_id = OBJECT_ID('dbo.Employees');

public partial class AddEmployeeFields : Migration
{
    protected override void Up(MigrationBuilder migrationBuilder)
    {
        migrationBuilder.AddColumn<string>(
            name: "Department",
            table: "Employees",
            type: "nvarchar(100)",
            nullable: true);

        migrationBuilder.AddColumn<DateTime>(
            name: "LastReviewedAt",
            table: "Employees",
            type: "datetime2",
            nullable: true);
    }
}

A safe recovery process looks like this:

1. Take a database backup or confirm that a suitable recovery point exists.

2. Inspect the actual schema and data.

3. Compare the database with the intended migration.

4. Determine which operations were committed.

5. Decide whether to restore the original state or complete the intended schema change.

6. Validate the result before allowing the application to continue.

In many cases, completing the intended schema change through a carefully reviewed corrective migration or SQL script is safer than attempting to reverse every operation manually.

If you need to repair the database manually, ensure the final schema matches the migration model before allowing EF Core to proceed with later migrations.

Do not insert a migration record into __EFMigrationsHistory simply to make EF Core believe that a migration succeeded. The record should only represent a migration whose intended database changes have actually been completed and verified.

6. Should You Roll Back a Failed Migration?

Rolling back is one possible recovery strategy, but it should not be the automatic response to every failure.

EF Core migrations support an Up method for applying changes and a Down method for reversing them.

For example:

protected override void Up(MigrationBuilder migrationBuilder)
{
    migrationBuilder.AddColumn<string>(
        name: "Department",
        table: "Employees",
        type: "nvarchar(100)",
        nullable: true);
}

protected override void Down(MigrationBuilder migrationBuilder)
{
    migrationBuilder.DropColumn(
        name: "Department",
        table: "Employees");
}

You can use EF Core tooling to move the database to an earlier migration:

dotnet ef database update PreviousMigration

However, this command is intended to move a database between migration states. It is not a general-purpose repair command for a partially applied migration.

Before rolling back, consider:

• Does the Down method remove production data?

• Have users started writing data into the new columns?

• Does the rollback affect other application versions?

• Are there dependent tables, indexes, or constraints?

• Can the rollback be tested against a recent database backup?

For example, dropping a newly added column can permanently remove data collected after deployment.

A rollback script should be generated, reviewed, and tested before it is executed against production.

7. Create a Corrective Migration When Forward Recovery Is Safer

Sometimes the best recovery strategy is to move forward rather than reverse the database.

Suppose a production migration successfully added a column but failed while creating an index. After investigating, you confirm that the column is present and the migration is not recorded as applied.

You may need to reconcile the database state before proceeding. One option is to restore the database to its original state and retry a corrected migration. Another is to use a controlled repair script to complete the intended change and then carefully align the migration history.

If the failed migration has already been applied and recorded, create a new migration to correct the remaining issue.

For example:

dotnet ef migrations add AddMissingEmployeeIndex

Then define the missing operation:

public partial class AddMissingEmployeeIndex : Migration
{
    protected override void Up(MigrationBuilder migrationBuilder)
    {
        migrationBuilder.CreateIndex(
            name: "IX_Employees_Department",
            table: "Employees",
            column: "Department");
    }

    protected override void Down(MigrationBuilder migrationBuilder)
    {
        migrationBuilder.DropIndex(
            name: "IX_Employees_Department",
            table: "Employees");
    }
}

This approach is appropriate when the earlier migration is already considered successfully applied and the database needs a separate corrective change.

If the earlier migration was never recorded, do not simply add a later migration and assume EF Core will skip the failed one. The migration sequence and database state must be reconciled first.

8. Use SQL Scripts for Safer Production Recovery

Applying migrations directly from application startup or running database update commands manually can make production recovery harder to control.

A better approach for many production systems is to generate SQL scripts and review them before execution.

Generate a script for the migration range:

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

For environments where databases may have different migration histories, generate an idempotent script:

dotnet ef migrations script --idempotent --output migration.sql

An idempotent script checks the migration history table and applies migrations that are not recorded as applied.

However, idempotency does not mean the script can repair every partially modified schema. If a failed migration left an object behind without a corresponding history record, the script may still fail when it tries to create that object again.

Always inspect the generated SQL and verify the database's actual state before running it.

For automated deployments, EF Core also supports migration bundles:

dotnet ef migrations bundle --output artifacts/efbundle

A migration bundle can be generated during the build and executed as a separate deployment step. It does not require the .NET SDK or EF Core tools to be installed on the production server.

Choose SQL scripts when database administrators need to review and approve the exact SQL. Choose migration bundles when you want a packaged migration executable in an automated deployment workflow.

9. Prevent Migration Failures in Future Deployments

Recovery is important, but preventing migration problems is even better.

Use these practices in your deployment process:

• Review generated migrations before applying them to production.

• Test migrations against a database with realistic data volume.

• Take a backup or verify point-in-time recovery before high-risk schema changes.

• Use a dedicated deployment identity with schema modification permissions.

• Keep the application's runtime database identity restricted to the permissions it needs.

• Apply migrations through a controlled deployment job rather than having every application instance execute them independently.

• Monitor migration execution and retain the complete error logs.

• Validate application compatibility with the old and new database schemas.

• Test rollback scripts separately, especially when they remove columns or transform data.

• Avoid combining unrelated schema changes into one large migration.

For applications using multiple instances, coordinate migration execution through a deployment process. EF Core 9 and later include migration locking for supported migration execution paths, but this does not replace deployment coordination or database compatibility planning.

10. Common Mistakes During Production Recovery

A few recovery shortcuts can turn a migration failure into a much bigger production issue.

Mistake	Why it is risky	Better approach
Deleting a row from __EFMigrationsHistory immediately	EF Core may try to repeat operations that already exist	Inspect the schema and history together
Rerunning a failed migration without investigation	Existing columns, indexes, or constraints may cause another failure	Identify which operations completed
Running Down without checking its impact	Rollback operations can delete production data	Review and test rollback SQL
Editing an already deployed migration	Existing databases may have applied an earlier version of that migration	Use a corrective migration when appropriate
Applying migrations from every application instance	Concurrent deployment activity can cause conflicts	Use a coordinated migration job
Assuming an idempotent script repairs partial changes	It checks migration history, not every database object	Validate the schema before execution

The most important principle is to treat the migration history table and the actual database schema as two separate pieces of evidence. Both must be consistent before deployment can safely continue.

Summary

A failed EF Core migration in production does not always mean the database has been rolled back to its original state. Transaction behavior, database provider limitations, and non-transactional operations can leave different outcomes.

Start by stopping additional migration attempts, reviewing the error, inspecting the migration history, and comparing the actual database schema with the intended changes. Depending on the result, you may retry a corrected migration, restore the database, apply a controlled repair, or create a corrective migration.

For future deployments, generate and review SQL scripts or use migration bundles, maintain reliable backups, and coordinate migration execution through a dedicated deployment process.

A safe recovery is not simply about getting the migration to run again. It is about restoring consistency between the database schema, migration history, and application code without losing production data.