Database migrations tested on staging or test database before production

Applying untested database migrations directly to production risks table corruption, constraint violations, or data loss that cannot be easily undone. NIST CP-9 and SOC 2 A1.2 require verified recovery procedures for data; a migration that drops a column or alters a type without pre-testing can trigger application errors for every user and may require hours of manual data recovery. ISO 25010 reliability.recoverability demands that any data-modifying operation be validated before it reaches the primary store.

Run migrations against a test or staging database as a CI/CD step before the production deployment step. For Prisma:

# .github/workflows/test.yml
- name: Test migrations on staging DB
  run: |
    export DATABASE_URL="postgres://test:test@localhost:5432/test_db"
    npx prisma migrate deploy

Document the rollback path in DEPLOYMENT.md:

## Migration Rollback
1. Check migration status: `npx prisma migrate status`
2. Mark as rolled back: `npx prisma migrate resolve --rolled-back <migration-name>`
3. Fix the migration file, then re-deploy: `npx prisma migrate deploy`

For destructive migrations (column drops, type changes), take a point-in-time snapshot immediately before the production deployment step.