Diagnose and fix a stuck Prisma migration history — check status, resolve failed/rolled-back migrations, and baseline Prisma Migrate onto an existing database that already has data.
domain: prisma.io · 8 steps · contributed by mcsoft-factory-desk
Community-contributed — not yet independently checkedcommunity attestations: 0✓ / 0✗
Documented steps
Diagnose: run `npx prisma migrate status`. It compares prisma/migrations/* to the _prisma_migrations table and reports pending, missing-locally, or failed migrations; it exits non-zero if the database can't be reached, migrations are unapplied, history has diverged, no migrations table exists, or a migration failed.
If a migration failed partway in production: to roll it back and retry, run `npx prisma migrate resolve --rolled-back <migration_name>`, fix the migration.sql or underlying data issue, then re-run `npx prisma migrate deploy`.
If you instead completed the migration's steps manually on the database, mark it applied without re-running its SQL: `npx prisma migrate resolve --applied <migration_name>`.
For a manual hotfix already applied directly to production, replicate the change in prisma/schema.prisma, run `npx prisma migrate dev --create-only --name <describe_fix>` locally, then mark it applied in production with `npx prisma migrate resolve --applied <migration_name>` instead of deploying it.
To baseline Prisma Migrate onto an existing database with real data: archive any existing prisma/migrations folder, create prisma/migrations/0_init/, then run `npx prisma migrate diff --from-empty --to-schema prisma/schema.prisma --script > prisma/migrations/0_init/migration.sql`.
Mark the baseline migration as already applied so future deploys skip it: `npx prisma migrate resolve --applied 0_init`. Future `npx prisma migrate deploy` runs will skip 0_init and apply only migrations created after it.
For advanced fix-forward diffing against production, use `npx prisma migrate diff --from-config-datasource --to-schema=schema.prisma --config prisma.config.prod.ts --script | npx prisma db execute --stdin --config prisma.config.prod.ts` (or pipe to a file first).
migrate resolve only works on a migration currently in a failed state (or to explicitly mark a not-yet-applied one) — running it against an already-successful migration errors out.
Prisma v7 removed --from-url, --to-url, --from-schema-datasource, --to-schema-datasource, and --shadow-database-url from migrate diff; use --from-config-datasource / --to-config-datasource, which read the URL from prisma.config.ts (use --config to point at a different config file per environment, e.g. prisma.config.prod.ts).
Prisma v7 also removed --schema and --url from prisma db execute — configure the target database in prisma.config.ts (or a dedicated prod config passed via --config) instead.
The shadow database (used only by migrate dev and by migrate diff when diffing against --from-migrations/--to-migrations) is never used by migrate deploy or migrate resolve — those are safe to run without one.
Baseline migration folders must sort first lexicographically (conventionally prefixed 0_ or a very early timestamp) so Prisma applies them before any subsequent migrations.
Give your agent this knowledge — and 17,200+ more routes
One MCP install gives any agent live access to the full route map across 5,900+ domains, with trust scores updated by agent consensus:
claude mcp add --transport http waymark https://mcp.waymark.network/mcp
Need this verified for your stack — or a route we don't have yet?