write_migrationlisted

# write_migration Database migrations are one of the highest-risk operations in production software. A bad migration can corrupt data, lock tables for minutes, or be impossible to roll back. This skill helps you write migrations that are safe, reversible, and production-friendly. ## Core Principles 1. **Every migration must be reversible** — write both the upgrade and downgrade paths. If a downgrade is genuinely destructive (e.g., dropping a column with data), document why and require explicit acknowledgment. 2. **Separate schema changes from data changes** — don't mix `ALTER TABLE` with `UPDATE` in the same migration. Schema migrations run in a transaction; bulk data updates often can't or shouldn't. 3. **Zero-downtime first** — design migrations so the app can run on the old schema AND the new schema simultaneously during deployment. This allows rolling deploys. 4. **Never rename without a two-step process** — renaming a column or table breaks the running app. Use the expand/contract pattern instead. ## Before Writing the Migration 1. Read the current schema file or ORM model to understand the current state. 2. Check existing migration files to understand the numbering/naming convention. 3. Understand the deployment model: is this a blue-green deploy? Rolling? Does the app need to serve traffic during migration? 4. Estimate table size — a migration on a table with 100M rows behaves very differently from one with 100 rows. ## Safe Migration Patterns ### Adding a Colum