Introduction

Moving a model from one Django app to another is mostly a migration-planning problem, not a copy-paste problem. In Django 1.7, the migration system existed, but it did not have many of the convenience tools available in later versions. The safest strategy is to preserve the existing database table, move the Python import path carefully, and keep the migration history explicit.

Decide Whether the Database Table Should Move

In many projects, you do not actually want to rename the database table at all. You only want the model class to live in a different app. That distinction matters because a Python move is much cheaper than a database-table move.

If the existing table is already populated, the practical default is:

1. move the model code to the new app
2. point the new model at the old table name
3. adjust foreign keys and imports
4. create migrations that reflect the state change without destroying data

That avoids risky bulk data copying when the table itself can stay where it is.

Start With a Concrete Example

Assume the model starts in old_app/models.py:

1from django.db import models
2
3
4class Invoice(models.Model):
5    number = models.CharField(max_length=50)
6    total = models.DecimalField(max_digits=10, decimal_places=2)

In a fresh Django 1.7 project, the default table name would be something like old_app_invoice.

Move the Model Code Into the New App

Create the same model in new_app/models.py, but pin the database table to the old table name:

1from django.db import models
2
3
4class Invoice(models.Model):
5    number = models.CharField(max_length=50)
6    total = models.DecimalField(max_digits=10, decimal_places=2)
7
8    class Meta:
9        db_table = 'old_app_invoice'

This is the key move. The class now lives in new_app, but it still reads and writes the existing table. That means existing rows are preserved.

Update References Before Running Migrations

Every place that imports the model must now use the new app path.

Examples:

1# old
2from old_app.models import Invoice
3
4# new
5from new_app.models import Invoice

Also check:

• admin registrations
• foreign key declarations
• signals
• forms
• serializers
• raw imports inside management commands or tests

If you miss these, the app can boot with a split view of the same concept.

Handle Foreign Keys Carefully

If other models point at the old class, update them to point at the new app label.

1from django.db import models
2
3
4class Payment(models.Model):
5    invoice = models.ForeignKey('new_app.Invoice')

After changing the relation target, create migrations for those dependent apps too. In Django 1.7, migration order matters more than people expect, so review dependencies manually if necessary.

Migration Strategy in Django 1.7

Because Django 1.7 is older, the safest approach is usually explicit state control rather than hoping the autodetector understands your intent.

Typical workflow:

python manage.py makemigrations new_app
python manage.py makemigrations dependent_app
python manage.py migrate

If Django tries to create a brand-new table for new_app.Invoice, that is a sign the migration state does not match your intended preserved-table strategy. In older Django versions, you may need to edit the generated migration so it reflects the model state you want without dropping or recreating the table incorrectly.

When a Physical Table Rename Is Required

Sometimes you do want the database table name to match the new app label. That is a separate operation and should be treated separately from the Python move.

The rough sequence is:

1. move the model class
2. temporarily keep db_table pointed at the old table
3. once code is stable, rename the database table with SQL or a migration step
4. update db_table or remove it if the default name is now correct

Keeping those steps separate reduces the blast radius.

Verify the Move in the Shell

Before declaring success, verify that the new model reads existing data:

python manage.py shell

1from new_app.models import Invoice
2
3print(Invoice.objects.count())
4print(Invoice.objects.first())

If the count matches the original data, the move preserved the table binding correctly.

Common Pitfalls

• Moving the model class without preserving the original table name.
• Letting Django generate a fresh table when the goal was only to move the Python model.
• Updating the model location but forgetting foreign keys and imports in other apps.
• Trying to combine Python refactor, table rename, and data migration into one risky step.
• Assuming the Django 1.7 migration autodetector fully understands model moves across apps.

Summary

• In Django 1.7, moving a model between apps is safest when the existing table is preserved first.
• Use Meta.db_table in the new app to point at the original table.
• Update all imports and relation targets to the new app path.
• Treat table renaming as a separate step from model relocation.
• Verify the result in the shell before considering the migration complete.