Migrations have rollback capability (down migrations or revert scripts)

Migrations without down functions (or a documented corrective-migration approach for Prisma) mean that a bad migration applied to production has no automated recovery path. The team must reconstruct the revert SQL under pressure during an incident, while the production database is in a broken state and users are affected. ISO 25010 recoverability requires a defined process for restoring normal operation; a migration system where every rollback is improvised from scratch does not meet this bar.

For Knex, Sequelize, and TypeORM, define a down function in every migration that exactly reverses the up function. For Prisma (which intentionally omits down migrations), document the corrective migration approach in a project runbook.

// Knex — both up and down defined
exports.up = async (knex) => {
  await knex.schema.createTable('posts', (t) => {
    t.uuid('id').primary().defaultTo(knex.raw('gen_random_uuid()'))
    t.string('title').notNullable()
    t.timestamp('created_at').defaultTo(knex.fn.now())
  })
}
exports.down = async (knex) => {
  await knex.schema.dropTable('posts')
}

For Prisma, add a docs/rollback-policy.md that states: "To reverse a migration, create a new corrective migration (npx prisma migrate dev --name revert_<issue>) with SQL that undoes the previous change. For dev-only rollback: npx prisma migrate reset (destroys data — never run in production)."