I’ve been building a Django project called SmartDuka, a smart shop management system for small retailers and shop owners. It handles inventory tracking, low stock alerts, dead stock detection, sales tracking, credit sales, and daily business insights.

This is also my first serious Django project.

And for a while, every time I switched from my home laptop to my work laptop, I went through the exact same process:

git clone
python -m venv venv
pip install -r requirements.txt
python manage.py migrate
python manage.py createsuperuser

Then I would open the admin panel and start entering products, customers, and sample sales all over again.

Every. Single. Time.

At first, I thought this was just part of working with Django. But eventually I realized I wasn’t actually understanding the relationship between:

• my code
• migrations
• and the database itself

This article is basically the explanation I wish someone had given me earlier.

The Mistake I Wasn’t Really Making

To be fair, I was doing one important thing correctly:

db.sqlite3

was inside my .gitignore.

For a good reason SQLite databases are local files and usually shouldn’t be committed to Git.

So technically my workflow looked “correct.”

The problem was this:

I assumed migrations would somehow preserve my data across machines.

They don’t.

What Django Migrations Actually Do

This part finally clicked for me after some frustration.

When you run:

python manage.py migrate

Django recreates the database structure, not the actual records inside it.

So migrations restore things like:

• tables
• columns
• relationships
• constraints

But they do not restore:

• superusers
• products
• inventory
• sales records
• customers
• suppliers

That data lives inside the database itself.

And in SQLite, that database is literally one file:

db.sqlite3

Once I understood that, everything made sense.

Why I Had to Keep Recreating My Superuser

Because every new machine was getting:

fresh empty database

After migrations, Django had the tables it needed, but there were no actual records inside them yet.

So naturally:

• no users existed
• no inventory existed
• no sales existed

I wasn’t losing my code.

I was losing my database state.

The Different Solutions I Considered

Once I understood the problem properly, I realized there are several ways developers approach this.

1. Recreate Everything Every Time

This was my original workflow.

It technically works, but only for tiny projects.

Once your app starts accumulating meaningful data, this becomes painful very quickly.

2. Commit db.sqlite3 to Git

I considered this briefly.

It solves the syncing issue, but introduces other problems:

• binary file conflicts
• messy Git history
• merge problems
• potential security risks

For a real project, this didn’t feel right.

3. Use Fixtures

Django supports:

python manage.py dumpdata
python manage.py loaddata

which export and import data as JSON fixtures.

This is actually pretty useful for:

• demo data
• seed data
• lookup tables

But for constantly changing business data like inventory and sales, it felt awkward as the main solution.

4. Copy db.sqlite3 Between Machines

This ended up being the most practical short-term solution for me.

Instead of recreating everything, I simply keep the latest SQLite database and transfer it between machines manually.

That preserves:

• my superuser
• inventory records
• customers
• sales history
• everything else

The workflow now looks more like this:

git pull
pip install -r requirements.txt
# copy latest db.sqlite3
python manage.py migrate
python manage.py runserver

Much better.

The Important Detail About Migrations

One thing I learned here:

The correct order is:

1. copy db.sqlite3
2. then run migrations

Not the other way around.

Why?

Because migrations should update your existing database schema if new model changes were added.

For example, if yesterday my Product model had:

name = models.CharField(max_length=100)

and today I added:

price = models.DecimalField(...)

then running:

python manage.py migrate

updates the copied database safely.

That’s exactly what migrations are designed for.

The Bigger Realization

At some point, I realized SmartDuka started behaving like a real system.

And once that happens, things like:

• persistence
• synchronization
• database strategy
• backups
• scalability

suddenly become important.

That transition caught me by surprise a little.

What I’m Planning Next

Right now I’m still using SQLite during development because it’s simple and fast.

But I can already see that eventually I’ll need to move toward PostgreSQL, especially because SmartDuka deals with:

• transactions
• inventory
• analytics
• credit management
• reporting

At that point, having a shared database instead of manually copying SQLite files will make much more sense.

But honestly, understanding why I was recreating my superuser every time was already a huge learning moment.

Final Thoughts

One thing I’m learning while building real projects is that software development isn’t only about writing features.

Sometimes the biggest lessons come from workflow problems.

This was one of them for me.

If you’re new to Django and you’ve ever wondered:

“Why do I keep losing my data even after running migrations?”

hopefully this article saves you a few hours of confusion.