Guides / InconsistentMigrationHistory: Migration admin.0001_initial is applied before its dependency

Peter van Doorn Django Cloud · Checked against Django 4.2 and newer, October 2026

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

You run migrate and Django stops with django.db.migrations.exceptions.InconsistentMigrationHistory: Migration admin.0001_initial is applied before its dependency users.0001_initial on database 'default'. Django's record of what was applied doesn't match the dependency order in your code. On a fresh or throwaway database, reset it. On production, repair the record carefully.

django.db.migrations.exceptions.InconsistentMigrationHistory:
Migration admin.0001_initial is applied before its dependency users.0001_initial on database 'default'.

What it means

Django stores applied migrations in the django_migrations table. Before running anything it checks that, for every applied migration, all of its dependencies are applied too. Here the database says the admin's first migration ran, but the migration it depends on (your app's) did not. Django won't guess how to continue.

Why it happens

1. You added a custom user model after the first migrate. admin.0001 depends on AUTH_USER_MODEL, and was applied before your users app existed. This is the most common cause.
2. Migrations were edited, squashed, deleted or regenerated after being applied somewhere, so dependencies changed.
3. Branches were merged with migrations created in parallel, in a different order than they were applied on each database.
4. The database was restored from a dump of another version of the project.

The fix

On a development or empty database: start over

Fastest and safest when there's nothing to lose. Delete the database (or db.sqlite3) and run python manage.py migrate.

On a database that has data

Back it up first. Then:

1. Compare what's recorded with what exists: python manage.py showmigrations and, in SQL, SELECT app, name, applied FROM django_migrations ORDER BY id;.
2. For the custom-user case, where the tables already exist and only the order is wrong, remove the records of the migrations that ran too early:

   BEGIN;
   DELETE FROM django_migrations WHERE app = 'admin';
   COMMIT;

3. Apply the dependency, then mark the early ones as applied without re-running them (their tables are already there):

   python manage.py migrate users
   python manage.py migrate admin --fake

4. Run a full python manage.py migrate and confirm showmigrations shows every box checked.

This recipe assumes the tables for the late migration already exist. If your custom user app was added after the first migrate, its table doesn't exist and the admin tables point at the old auth_user table. In that case the safe route is a new empty database: run dumpdata on the old one, migrate the new one, then loaddata.

Use --fake only when you have verified that the schema already matches the migration. Faking a migration that never ran leaves your models and tables out of sync. Test the whole procedure on a copy of production first.

Making it stick in production

• Set AUTH_USER_MODEL at the start of a project, before the first migration. It's very hard to change later.
• Never edit or delete an applied migration. Add a new one. Squash only with squashmigrations, after every environment has applied the originals.
• Resolve parallel migrations when merging with python manage.py makemigrations --merge.
• Run python manage.py makemigrations --check --dry-run and a clean-database migrate in CI, which exposes dependency problems before they reach production.

Or skip it

Django Cloud runs migrations before every release and keeps serving the previous release when one fails. It doesn't repair a broken migration history, which is a fix in your code and database.

pip install djangocloud-cli
djangocloud deploy

Get startedSee pricing

Free plans are available for students, AWS Activate startups, open-source, non-profit and research projects. See how Django Cloud compares with other ways to host Django.

Django is a registered trademark of the Django Software Foundation. Django Cloud is not affiliated with or endorsed by it. Found a mistake in this guide? Tell us and we will fix it.