makemigrations vs migrate
How Django plans and applies schema changes.
makemigrations vs migrate is a free Django Academy lesson on CoddyKit — lesson 1 of 4. You can read the complete lesson below for free — then practise it hands-on in the browser with a built-in code editor and a 24/7 AI tutor. It is part of the Django Academy learning path, one of 4 lessons in the course, and your progress syncs across the web and the CoddyKit app.
Two Steps, Not One
Django changes your database in two steps: first it writes a plan, then it runs that plan. Knowing which is which saves a lot of confusion. 🧭
makemigrations Plans
makemigrations looks at your models, spots what changed, and writes a migration file describing the change. It does not touch the database yet.
python manage.py makemigrationsmigrate Applies
migrate takes those migration files and actually runs them against the database, creating or altering real tables.
python manage.py migrateWhy Split Them
Splitting plan from action lets you review a change, commit it to git, and apply the exact same steps on every machine and server.
Migrations Are Files
Each plan lives as a file in your app under migrations/. You commit these files so teammates apply identical changes.
A Typical Cycle
Edit a model, run makemigrations to record it, then run migrate to apply it. That loop is your everyday schema workflow.
Naming Migrations
Add a clear label so files read like a history, not a pile of numbers. Use the --name flag to describe what changed.
python manage.py makemigrations --name add_published_fieldTargeting One App
Pass an app label to generate or apply migrations for just that app, keeping unrelated changes out of the way.
python manage.py makemigrations blogCheck Without Changing
Run makemigrations with --check in CI to fail the build if a model change has no matching migration yet.
python manage.py makemigrations --check --dry-runSee What Is Applied
The showmigrations command lists every migration and marks the applied ones with an X, so you know your exact state.
python manage.py showmigrationsOrder Matters
Always makemigrations first, then migrate. Running migrate alone applies whatever plans already exist, including Django built-ins.
Quick Check
Which command actually changes the database tables?
Recap
You learned the rhythm: makemigrations writes the plan, migrate applies it. Plan first, apply second, and your schema stays in sync everywhere. 🎉
Frequently asked questions
Is the “makemigrations vs migrate” lesson free?
Yes — the full text of “makemigrations vs migrate” is free to read here on the web, and the Django Academy course includes 4 lessons in total. To practise it interactively (a built-in code editor and a 24/7 AI tutor) and unlock the rest of the Django Academy course, upgrade to CoddyKit PRO.
What will I learn in “makemigrations vs migrate”?
How Django plans and applies schema changes. You practise Django Academy with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.
Do I need any experience to start Django Academy?
No prior experience is required. Django Academy on CoddyKit is structured for beginners through advanced learners; this is — lesson 1 of 4, so you can start here or from the beginning and move at your own pace.
How long does the “makemigrations vs migrate” lesson take?
Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.
Can I write and run code in this Django Academy lesson?
Yes. Every Django Academy lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.
All lessons in this course
- makemigrations vs migrate
- Reading a Migration File
- Changing a Model and Re-migrating
- sqlmigrate and Inspecting SQL