← All docs

Database migrations

Database migrations are a first-class step in a deploy, not something you have to wire up yourself with a deploy hook. Set a mode once and every deploy runs it, in order, before the new release ever goes live.

Steps:

1. Open the site from Sites, go to its Database migrations tab.
2. Pick a mode:
   • EF Core migration bundle — DotDeployer builds a self-contained efbundle alongside your release (dotnet ef migrations bundle --self-contained) and runs it against ConnectionStrings__Default. Nothing to type.
   • Command — a shell command that runs in the release folder, with your site’s environment variables already loaded. The suggested default is dotnet <MainDll> --migrate, the same pattern DotDeployer’s own Bot uses for its own DbUp migrations.
   • Custom shell command — anything else, e.g. dotnet ef database update.
   • None — the default. No deploy ever touches the database.
3. Leave “Run migrations on every deploy” on (the default) so every deploy migrates automatically, or turn it off if you’d rather only ever trigger a migration by hand with “Run migrations now”.
4. Deploy the site. The migration’s output appears as its own step in the deployment log, between the after-publish hook and the switch to the new release.

Why before the switch: the migration runs against the release about to go live, before DotDeployer repoints current at it and restarts the service. If the migration fails, the release is marked Failed, current is never repointed, and the previous release keeps serving traffic — exactly like any other failed deploy step.

Rollback: rolling back a site re-points the current symlink to an older release; it does not run your migration in reverse. Write migrations that are backward compatible with the release before them (additive columns, not destructive renames in the same deploy) so a rollback never leaves the old code pointed at a schema it doesn’t understand.

Run migrations now: the same migration, run on demand against whatever release is already live — useful the first time you turn this on, or to re-run a migration without shipping a new release. Only one migration runs at a time per site; a second click while one is already running is rejected rather than queued.