## 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

```text
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
- _prisma_migrations 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

```bash
npx prisma migrate status
```

And inspect the record:

```sql
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

```bash
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

```bash
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

```bash
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 _prisma_migrations. 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