A database schema describes tables, columns, and their relationships. When an EF Core data model changes, the database schema must change with it. A migration is a C# file that records the model change and the actions needed to update the schema. Keeping migrations with application code makes that history available alongside each version of the app. section 12.3 section 12.3.2
To create and apply a first migration:
- Configure an EF Core database provider, entities, and DbContext. Install the EF Core tooling; for the cross-platform CLI, run `dotnet tool install --global dotnet-ef`. section 12.2 section 12.3.1
- From the project folder containing the registered DbContext, run `dotnet ef migrations add InitialSchema`. This generates migration files but does not change the database. section 12.3.1 section 12.3.2
- Run `dotnet ef database update` to create the database if needed and apply outstanding migrations. EF Core records applied migrations in `__EFMigrationsHistory`. section 12.3.1 section 12.6
The generated files include a migration describing database actions, a designer file recording EF Core’s model at that point, and an `AppDbContextModelSnapshot.cs` file representing the current model. Adding another migration updates the current snapshot. The generated database actions depend on the configured provider. section 12.3.1 section 12.3.2
Add recipe fields
Suppose a `Recipe` entity gains `IsVegetarian` and `IsVegan` properties. Run `dotnet ef migrations add ExtraRecipeFields`, then `dotnet ef database update`. The first command records the model change; the second applies it, adding the fields to the `Recipes` table. section 12.3.2
Migrations also matter when a framework feature adds entities. Changing an existing DbContext to inherit from `IdentityDbContext<ApplicationUser>` adds Identity entities to EF Core’s model, so the database needs a new migration. An Individual Accounts project template includes Identity migrations, but they must be applied before creating users. section 23.4.2 section 23.3.1
For production deployment, decide how migrations will be applied rather than assuming application startup is always suitable. Options include scripting the .NET tool, startup code, EF Core bundles, and custom tooling. Multiple web hosts sharing one database make startup migration harder because only one host should migrate it at a time; aim for backward-compatible schema changes where possible. section 12.5
