Workflow
1
Fetch a fresh backup from the dev VPS
Before starting any new migration, pull the latest backup from the dev database and restore it locally. Don’t build a new migration against a stale local schema — that’s the #1 cause of migration drift and checksum mismatches.
2
Create a new branch from the latest branch, not from main
Pull the most recently merged migration branch (or main if nothing else is pending) before branching. If you branch from an outdated point, your migration file numbering/order can conflict with migrations that were merged after you branched, causing
_prisma_migrations drift once both land in dev.3
Make your schema changes
Edit
schema.prisma as needed.4
Generate migration locally
5
Test the migration locally
prisma migrate dev against .env.local — it generates the migration SQL file and applies it to your local DB in one step, prompting you to name the migration.6
Run the full local bootstrap to catch seed/permission issues early
prisma:migrate:local and prisma:seed:local (which itself runs permissions:generate:local first). Running the full bootstrap — not just the migration — surfaces seed-script or permission-generation errors caused by your schema change before a reviewer ever sees it.7
Review the generated migration SQL by hand
Open the new file under
prisma/migrations/. Confirm it does what you expect — especially for column drops, type changes, or new NOT NULL columns, which Prisma may implement in a way that’s fine for a fresh DB but destructive against real data (see the Data Migration page if so).8
Push the branch and open a PR
Don’t Include the migration file(s) From
prisma/migrations/ the dev-responsible will do it after check you branch