weco-migration-safety

Run showmigrations to verify the graph has no duplicate numbers or broken chains, then makemigrations --check --dry-run to confirm models match migrations. Finally test migrate on a clean database and on a copy of the existing database, and verify each migration can roll back.

Run manage.py makemigrations --check --dry-run. It must report No changes detected; any proposed migration means either a migration was never generated or the branch is missing migration files that exist elsewhere.

migrate --fake marks migrations as applied without running them, so the database state and migration graph silently diverge. The discrepancy typically surfaces later on another machine, which is why it requires explicit written owner approval.

No. Django does not know about the missing numbers and will generate a new migration under an already-used number, creating two different migrations with the same number that can never be reconciled.

Some errors only appear on PostgreSQL, such as stale sequences after bulk inserts with explicit ids and constraint differences. Test migrations on an empty PostgreSQL instance and run sqlsequencereset after bulk data loads.

Every RunPython migration should define a reverse function or explicitly use migrations.RunPython.noop with a comment explaining why rollback is unnecessary. Large data migrations should also flag expected deploy downtime.