prisma Error P3015: Could not find the migration file for a recorded migration

TL;DR

The database recorded a migration whose folder is gone from the migrations directory, usually deleted or never committed. First try to restore the folder from version control so the record matches reality. If the migration genuinely never applied anywhere, mark it rolled back with prisma migrate resolve and redeploy. Then run prisma migrate status to prove the history is consistent.

The query

prisma Error P3015: Could not find the migration file for a recorded migration

Use this when

• prisma migrate deploy fails with P3015
• A migration folder was deleted or never committed
• prismamigrations references a migration with no directory
• An agent cleaned up "unused" folders and broke the history

Not for

• P3009 failed migrations (use resolve --applied or --rolled-back on the failed row)
• migrate dev drift warnings on a development database
• A migration folder that exists but has a bad migration.sql inside

Steps

1. See which migration is missing

npx prisma migrate status

And inspect the record:

SELECT migration_name, finished_at, applied_steps_count FROM _prisma_migrations WHERE migration_name = '[missing name]';

Expected output: status names the missing migration, and the table shows whether it recorded as finished. A finished record for a missing folder is the P3015 case.

2. Try to restore the folder from version control

git log --diff-filter=D --name-only -- prisma/migrations/ | head -30
git checkout [commit] -- prisma/migrations/[missing folder]/

Expected output: the folder and its migration.sql are back. If the content matches what was recorded, status goes green with no further action.

3. Case A: the folder is unrecoverable but the migration applied - recreate it faithfully

If the migration ran in production, the folder must exist and match. Reconstruct migration.sql from the database itself: diff the current schema against the previous migration's schema, or recover the SQL from backups and logs. The recorded checksum is not verified against content on deploy, but future diffs depend on this folder being accurate.

Expected output: a folder whose migration.sql reproduces the applied change. Verify by deploying to a scratch database and diffing schemas.

4. Case B: the migration never applied anywhere - mark it rolled back

npx prisma migrate resolve --rolled-back "[missing migration name]"

Expected output: the phantom record is marked rolled back and no longer blocks deploy. Only use this when you are certain no database ever applied it; on a database where it did apply, this corrupts the history.

5. Verify the history is consistent

npx prisma migrate status

Expected output: "Database schema is up to date" or a clean list of pending migrations, with no P3015. Run migrate deploy on staging before production.

Tool compatibility

prisma 4.x and 5.x. P3015, migrate resolve, and migrate status behave the same across both. Not applicable to prisma db push workflows (no migration history there).

Variant phrasings

prisma P3015 could not find migration file

Steps 1 and 2: identify the missing folder and restore it from git. That resolves the large majority of P3015s.

prisma recorded migration folder deleted

Steps 2 and 3: restore from version control; reconstruct from the live schema only if git cannot help.

prisma migrate resolve rolled-back P3015

Step 4: resolve --rolled-back is only safe when the migration never applied anywhere. When in doubt, restore the folder instead.

Why it happens

Prisma tracks every migration as a folder containing migration.sql, and records the folder name in prismamigrations. Deploy replays history by folder, so a recorded folder with no files is a broken link in the chain. P3015 is prisma refusing to guess what the missing migration contained.

Edge cases

• Never commit a migrations folder without its migration.sql: an empty folder trips the same class of error one step later.
• If the missing migration was created by migrate dev on a developer machine and never merged, the fix is resolve --rolled-back on every database that recorded it, plus deleting the folder everywhere.
• Shadow-database failures during restore attempts are a separate issue (P3014): fix the shadow database, not the history.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_wHmDMueXavfsa8EXoY6Aow