Migrations are Django's way of propagating changes you make to your models (adding a field, creating a model) into the database schema — they're version-controlled, automatically-generated database change files. You change models in Python; migrations keep the database in sync.
python manage.py makemigrations
python manage.py migrate
makemigrations detects model changes and generates a migration file; migrate applies pending migrations to the actual database. You write Python (model changes), and Django generates and runs the SQL.
# migrations/0002_article_views.py (auto-generated)
class Migration(migrations.Migration):
dependencies = [("blog", "0001_initial")] # ordering — depends on the previous one
operations = [
migrations.AddField( # the change
model_name="article",
name="views",
field=models.IntegerField(default=0),
),
]
Migrations are committed to version control, so the database schema's history is tracked alongside the code. Every developer and environment applies the same migrations to reach the same schema — reproducible and consistent.
✓ Schema changes are version-controlled (tracked with the code, reviewable in PRs)
✓ Reproducible — every dev/staging/production DB gets the same schema by running migrate
✓ No manual, error-prone SQL — Django generates the correct ALTER statements
✓ Reversible — many migrations can be rolled back (migrate <app> <previous>)
✓ Team-friendly — schema changes flow through the normal code-review process
python manage.py showmigrations # see which migrations are applied/pending
python manage.py sqlmigrate blog 0002 # preview the SQL a migration will run
python manage.py makemigrations --empty # a blank migration for custom/data changes
python manage.py migrate blog 0001 # roll BACK to a previous migration
Migrations can also transform DATA (e.g. populate a new field, backfill values)
via RunPython operations — useful when a schema change needs accompanying data changes.
Migrations are essential to working with Django's database layer — they solve the critical problem of keeping the database schema in sync with your Python models in a safe, reproducible, team-friendly way.
Understanding them is fundamental everyday knowledge: the makemigrations → migrate workflow is how every schema change happens (you change models, Django generates and applies the SQL), so you can't develop a data-driven Django app without it.
The key value is that migrations make schema changes version-controlled (tracked alongside code, reviewable in pull requests), reproducible (every environment — each developer's machine, staging, production — reaches the identical schema by running the same migrations), and safe (Django generates correct, often-reversible SQL instead of error-prone manual ALTER TABLE statements).
This eliminates a whole category of problems around schema drift, inconsistent environments, and risky manual database changes.
Knowing the workflow, that migrations are committed to source control, how to inspect and roll them back, and that they can also handle data transformations (backfilling/migrating data, not just schema) is necessary for any real Django project.
Migrations are how Django teams evolve their database schema collaboratively and reliably over a project's lifetime, making this core, must-know material.