EF Core Migrations

1. The Problem: "It Works on My Machine"

Without Migrations: You add Email to User class. Deploy. Prod crashes: Invalid column 'Email'. You forgot to run SQL on prod DB. Manager angry.

With Migrations: You run Add-Migration AddUserEmail. EF generates C# code + SQL. Commit to git. CI/CD runs Update-Database on deploy. Zero missed steps.

2. The 3 Commands You Need

3. See It Work - 60 Seconds

Step 1: Add property public string Phone { get; set; } to User class.

Step 2: PMC → Add-Migration AddUserPhone

public partial class AddUserPhone : Migration {
    protected override void Up(MigrationBuilder mb) {
        mb.AddColumn(name: "Phone", table: "Users", nullable: true);
    }
    protected override void Down(MigrationBuilder mb) {
        mb.DropColumn(name: "Phone", table: "Users");
    }
}

Step 3: Update-Database. Column added. No SQL written by you.

1. The Interview Theory: How Migrations Work

What is a Migration? A C# class that represents one schema change. Has Up() to apply, Down() to rollback.

Why snapshots? Folder Migrations has AppDbContextModelSnapshot.cs. This is EF's memory of last DB shape. When you Add-Migration, EF compares current models vs snapshot. Diff = new migration. Snapshot updates.

How DB tracks it: Table __EFMigrationsHistory stores MigrationId + EF Version. Update-Database only runs migrations not in that table.

2. The #1 Interview Question: "Rollback a migration in prod?"

Your Answer: "Never run Down() in prod. Too risky. Process: 1. Revert code to previous git commit. 2. Run Script-Migration From To to generate rollback SQL. 3. Give SQL to DBA to review and run in maintenance window. 4. Deploy old code. For emergency: Update-Database PreviousMigrationName runs Down() locally, but I avoid this in prod pipelines."

This answer gets you hired. "Run Down()" gets you fired when data loss happens.

3. Pro Commands for Staff Engineers

4. Data Seeding in Migrations

Theory: Use HasData() for lookup data only. Not 10k users.

protected override void OnModelCreating(ModelBuilder mb) {
    mb.Entity().HasData(
        new Role { Id = 1, Name = "Admin" },
        new Role { Id = 2, Name = "User" }
    );
}

Staff Rule: Seeding runs on every Update-Database. If you put 10k rows, every deploy = 10k inserts. Use SQL script or app startup for big data.

5. Team Workflow - Avoid Merge Hell

Problem: Dev A creates Migration_20260101. Dev B creates Migration_20260102. Merge conflict in snapshot.

Fix: 1. Last dev to merge deletes their migration. 2. Pull master. 3. Add-Migration again. New timestamp wins. 4. Push.
Rule: Migrations are immutable after merge to master. Never rebase them.