Migrations Deep Dive: makemigrations & migrate

A migration is a versioned Python file that records a change to your models so Django can apply that exact change to the database schema in the right order, on every machine.

Learn Migrations Deep Dive: makemigrations & migrate in our free Django course — a beginner-friendly interactive lesson with worked examples, a practice…

Part of the free Django course at LearnCodingFast — hands-on lessons with examples you run in your browser, plus practice exercises and a quick quiz.

In this lesson you'll see exactly what migration files contain, how the migration graph orders them through dependencies, how to move data with RunPython, and how the escape hatches --fake, sqlmigrate, and squashing fit in.

Working with the schema is a two-step dance. makemigrations compares your models.py to the last known state and writes a new migration file describing the difference — it never touches the database. migrate then reads the unapplied migration files and runs their SQL against the database. Think plan , then apply .

The generated file is plain, readable Python — a list of operations and the migrations it depends on:

Migrations are not a flat list — they form a directed graph . Each file's dependencies point at the migrations that must run first. Django performs a topological sort of that graph to decide the real order, which is how a foreign key in one app can safely depend on a table created in another app.

Beyond schema changes, migrations can move data . A RunPython operation runs a function during migrate , giving you a historical version of the model to backfill or transform rows. You write a forwards function and, ideally, a reverse one so the migration can be rolled back.

Fill in the blank so migrate applies only the migrations that are not already in the applied list.

❌ "You are trying to add a non-nullable field without a default"

You added a required field to a table that already has rows, so Django can't fill the gap.

✅ Fix: give the field a default=... , or make it null=True , then re-run makemigrations .

❌ "Conflicting migrations detected; multiple leaf nodes"

Two branches both created a 0002 migration, so the graph forked.

✅ Fix: run python manage.py makemigrations --merge to create a migration that depends on both leaves.

❌ "Table already exists" after adopting an existing database

The schema is already there, but Django still wants to run the initial migration.

✅ Fix: run python manage.py migrate --fake-initial to record it as applied without recreating tables.

Squashing replays a list of operations and keeps the final column set, dropping intermediate churn. Write the optimizer that produces the squashed schema.

Lesson complete — you understand the whole migration pipeline!

You can now read a migration file, explain why makemigrations plans and migrate applies, follow the dependency graph, write a RunPython data migration, and reach for sqlmigrate , --fake , and squashing when you need them.

🚀 Up next: Model Fields & Options — the building blocks that every migration is made of.

Practice quiz

• Browse all free courses
• Cheat sheets & quizzes
• Coding dictionary