Skip to content

Migrations

Jump to bottom
Simon Hughes edited this page Mar 20, 2026 · 5 revisions

The generator is designed to reverse-engineer an existing database. If you want to use EF migrations going forward after the initial reverse-engineering, this page explains the transition.

EF Core — Converting to Migrations

Step 1: Reverse-engineer your database

Set Settings.GenerateSeparateFiles = true in Database.tt and save to generate the entity classes and configuration.

Step 2: Create the initial migration

Run in the Package Manager Console or .NET CLI:

# Package Manager Console
Add-Migration Init
Update-Database

# .NET CLI
dotnet ef migrations add Init
dotnet ef database update

If EF Core detects differences between the model and your existing database, the migration script will contain those changes. Review it carefully and ensure it is empty (no changes) before running Update-Database, since your database already has the schema:

# Create an empty migration that assumes the database is already in sync
Add-Migration Init -IgnoreChanges    # EF 6 only
# For EF Core, create the migration, then manually empty the Up() and Down() methods before applying

Step 3: Remove the generator

Once migrations are set up, delete the Database.tt and EF.Reverse.POCO.v3.ttinclude files. Inform your DBAs that the schema is now managed via code-first migrations.

EF 6 — Converting to Migrations

Step 1: Reverse-engineer your database

Set Settings.GenerateSeparateFiles = true in Database.tt and save.

Step 2: Enable migrations

Enable-Migrations

Step 3: Create an empty initial migration

Add-Migration Init -IgnoreChanges

This creates an empty initial migration that assumes the current database schema is already in sync with the generated model.

Step 4: Remove the generator

Delete the Database.tt and .ttinclude files. Schema changes are now managed via migrations.

DBAs Keep Control of the Database

If your DBAs manage the database schema (rather than developers), this is the recommended workflow:

  1. DBAs apply schema changes to the production database via SQL scripts or patches.
  2. Developers apply the same patches to their local development databases.
  3. After patching, developers re-save Database.tt to regenerate the entity model.
  4. Generated changes are committed and pushed.

This approach keeps the generated code in source control and synchronized with the production schema.

Important Notes

  • Do not run the generator on a CI/CD build server. If the build server database differs from the development database, the generated code will differ — causing hard-to-diagnose bugs. Generate once during development and commit the results to source control.
  • Generated code is static — it does not change unless you explicitly re-run the generator.
  • See Could this project be run by a script/build process? for more details on automation.

Clone this wiki locally