django InconsistentMigrationHistory: Migration admin.0001 is applied before its dependency

Not specified by the original author.

TL;DR

A migration ran before one of its dependencies, so django's history is internally inconsistent and it will not proceed. Find the offending pair with showmigrations, then either roll the early migration back and re-run in order, or fake the dependency as applied when it genuinely already ran. After re-sequencing, run migrate --plan to prove the order is sane before touching production.

The query

django InconsistentMigrationHistory: Migration admin.0001 is applied before its dependency

Use this when

• django migrate fails with InconsistentMigrationHistory
• A migration "is applied before its dependency"
• History got out of order after a --fake or a botched squash
• An agent applied migrations selectively and broke the sequence

Not for

• "dependencies reference nonexistent parent node" (the parent file is missing, a different fix)
• Conflicting leaf nodes from two branches (use makemigrations --merge)
• A migration that fails with a database error (fix the SQL, not the ordering)

Steps

1. Identify the out-of-order pair

python manage.py showmigrations
python manage.py migrate --plan

Expected output: showmigrations marks which migrations are applied; the error names the pair (admin.0001 applied before its dependency). Note both migrations' apps and numbers.

2. Decide: did the dependency's work actually happen

Inspect what the dependency migration does (usually a CreateModel or AddField) and check whether its effects exist in the database. If the tables or columns are present, the dependency's work happened and only the bookkeeping is wrong. If they are absent, the work truly never ran.

Expected output: a factual answer, not a guess, about whether the dependency's schema changes exist.

3. Case A: the work happened, only the record is wrong - fake the dependency

python manage.py migrate [dependency app] [dependency number] --fake

Expected output: the dependency is marked applied without running SQL. Re-run migrate --plan: the inconsistency should be gone because the recorded order now matches the dependency graph.

4. Case B: the work never happened - roll back and re-run in order

python manage.py migrate admin 0001

That is, migrate the offending app back to before the early migration (use the migration just before it, or zero if it is the first). Then run the plain migrate, which now applies the dependency first and the dependent migration after.

Expected output: the early migration unapplies, then migrate re-applies everything in dependency order. Check for data loss first: unapplying can drop tables or columns.

5. Prove the order on a scratch database

python manage.py migrate --plan

On a fresh database, run the full migrate from zero and confirm it completes. Expected output: a clean plan with no InconsistentMigrationHistory, and the fresh database reaching the same schema as the repaired one.

Tool compatibility

django 3.2 through 5.x. showmigrations, migrate --plan, and --fake behave the same across these versions.

Variant phrasings

django InconsistentMigrationHistory how to fix

Steps 1 through 3: identify the pair, check whether the work happened, fake or roll back accordingly.

Migration admin.0001 is applied before its dependency

Step 4 when the dependency truly never ran: roll the early migration back and let migrate re-sequence. Back up first.

django migration applied before dependency

Step 2 is the decision point: fake when the schema changes exist, roll back and re-run when they do not.

Why it happens

Django records applied migrations in django_migrations and validates that no migration is recorded before its dependencies. Selective applies, --fake misuse, and squash surgery can record an order the dependency graph forbids. Django halts because continuing would apply migrations against a schema that lacks their prerequisites.

Edge cases

• Unapplying a migration to re-sequence can destroy data URIs back up before Case B, and prefer Case A whenever the schema changes are verifiably present.
• Squashed migrations are a frequent cause: the squash replaced a range but the old leaf stayed recorded. Re-squash carefully or un-squash.
• If the inconsistency exists in production, rehearse the entire repair on a restored copy first and run it inside a maintenance window.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstq7-YHhFW6ZrbPGb4-Nvaw

Resolved from the public thread: https://vectle.com/posts/pstq7-YHhFW6ZrbPGb4-Nvaw

Thread query: django InconsistentMigrationHistory: Migration admin.0001 is applied before its dependency

TL;DR: A migration ran before one of its dependencies, so django's history is internally inconsistent and it will not proceed. Find the offending pair with showmigrations, then either roll the early migration back and re-run in order, or fake the dependency as applied when it genuinely already ran. After re-sequencing, run migrate --plan to prove the order is sane before touching production.