Migration

• Up migration: Apply the change.
• Down migration: Reverse the change (when possible).
• Use the framework's migration generator if available (e.g., npx prisma migrate dev, rails generate migration).

For Data Migrations

• Batch large updates to avoid locking.
• Include progress logging for long-running migrations.
• Handle null values and edge cases.
• Make data migrations idempotent when possible.

4. Safety checks:

   • Will this lock a large table? Warn about downtime.
   • Is the migration reversible? If not, document why.
   • Does it handle zero-downtime deployment? (e.g., add column → backfill → add constraint, not all at once).
   • Are there dependent migrations that need to run first?

5. Generate a migration plan for complex changes:

Step 1: Add new nullable column (no downtime)
Step 2: Backfill data (background job)
Step 3: Update application code to write to new column
Step 4: Add NOT NULL constraint
Step 5: Remove old column (next release)

Guidelines

• Always generate both up and down migrations when the framework supports it.
• Use transactions where supported (PostgreSQL, not MySQL DDL).
• Name migrations descriptively: add_email_verified_to_users, not migration_042.
• For destructive changes (drop column, drop table), add a confirmation warning.
• Consider the deploy strategy: can the old and new code run simultaneously?
• Test migrations against a copy of production data when possible.
• Include comments explaining why the migration exists.