Move models between Django (1.8) apps with required ForeignKey references

Just now moved two models from old_app to new_app, but the FK references were in some models from app_x and app_y, instead of models from old_app.

In this case, follow the steps provided by Nostalg.io like this:

• Move the models from old_app to new_app, then update the import statements across the code base.
• makemigrations.
• Follow Step 4.a. But use AlterModelTable for all moved models. Two for me.
• Follow Step 4.b. as is.
• Follow Step 4.c. But also, for each app that has a newly generated migration file, manually edit them, so you migrate the state_operations instead.
• Follow Step 4.d But use DeleteModel for all moved models.

Notes:

• All the edited auto-generated migration files from other apps have a dependency on the custom migration file from old_app where AlterModelTable is used to rename the table(s). (created in Step 4.a.)
• In my case, I had to remove the auto-generated migration file from old_app because I didn’t have any AlterField operations, only DeleteModel and RemoveField operations. Or keep it with empty operations = []

• To avoid migration exceptions when creating the test DB from scratch, make sure the custom migration from old_app created at Step 4.a. has all previous migration dependencies from other apps.

  old_app
    0020_auto_others
    0021_custom_rename_models.py
      dependencies:
        ('old_app', '0020_auto_others'),
        ('app_x', '0002_auto_20170608_1452'),
        ('app_y', '0005_auto_20170608_1452'),
        ('new_app', '0001_initial'),
    0022_auto_maybe_empty_operations.py
      dependencies:
        ('old_app', '0021_custom_rename_models'),
    0023_custom_clean_models.py
      dependencies:
        ('old_app', '0022_auto_maybe_empty_operations'),
  app_x
    0001_initial.py
    0002_auto_20170608_1452.py
    0003_update_fk_state_operations.py
      dependencies
        ('app_x', '0002_auto_20170608_1452'),
        ('old_app', '0021_custom_rename_models'),
  app_y
    0004_auto_others_that_could_use_old_refs.py
    0005_auto_20170608_1452.py
    0006_update_fk_state_operations.py
      dependencies
        ('app_y', '0005_auto_20170608_1452'),
        ('old_app', '0021_custom_rename_models'),
  

BTW: There is an open ticket about this: https://code.djangoproject.com/ticket/24686

This worked for me but I’m sure I’ll hear why it’s a terrible idea. Add this function and an operation that calls it to your old_app migration:

def migrate_model(apps, schema_editor):
    old_model = apps.get_model('old_app', 'MovingModel')
    new_model = apps.get_model('new_app', 'MovingModel')
    for mod in old_model.objects.all():
        mod.__class__ = new_model
        mod.save()


class Migration(migrations.Migration):

    dependencies = [
        ('new_app', '0006_auto_20171027_0213'),
    ]

    operations = [
        migrations.RunPython(migrate_model),
        migrations.DeleteModel(
            name='MovingModel',
        ),
    ]     

Step 1: backup your database!
Make sure your new_app migration is run first, and/or a requirement of the old_app migration. Decline deleting the stale content type until you’ve completed the old_app migration.

after Django 1.9 you may want to step thru a bit more carefully:
Migration1: Create new table
Migration2: Populate table
Migration3: Alter fields on other tables
Migration4: Delete old table

In case you need to move the model and you don’t have access to the app anymore (or you don’t want the access), you can create a new Operation and consider to create a new model only if the migrated model does not exist.

In this example I am passing ‘MyModel’ from old_app to myapp.

class MigrateOrCreateTable(migrations.CreateModel):
    def __init__(self, source_table, dst_table, *args, **kwargs):
        super(MigrateOrCreateTable, self).__init__(*args, **kwargs)
        self.source_table = source_table
        self.dst_table = dst_table

    def database_forwards(self, app_label, schema_editor, from_state, to_state):
        table_exists = self.source_table in schema_editor.connection.introspection.table_names()
        if table_exists:
            with schema_editor.connection.cursor() as cursor:
                cursor.execute("RENAME TABLE {} TO {};".format(self.source_table, self.dst_table))
        else:
            return super(MigrateOrCreateTable, self).database_forwards(app_label, schema_editor, from_state, to_state)


class Migration(migrations.Migration):

    dependencies = [
        ('myapp', '0002_some_migration'),
    ]

    operations = [
        MigrateOrCreateTable(
            source_table='old_app_mymodel',
            dst_table='myapp_mymodel',
            name='MyModel',
            fields=[
                ('id', models.AutoField(auto_created=True, primary_key=True, serialize=False, verbose_name='ID')),
                ('name', models.CharField(max_length=18))
            ],
        ),
    ]

After work was done I tried to make new migration. But I facing with following error:

ValueError: Unhandled pending operations for models:
oldapp.modelname (referred to by fields: oldapp.HistoricalProductModelName.model_ref_obj)


If your Django model using HistoricalRecords field don’t forget add additinal models/tables while following @Nostalg.io answer.

Add following item to database_operations at the first step (4.a):

    migrations.AlterModelTable('historicalmodelname', 'newapp_historicalmodelname'),

and add additional Delete into state_operations at the last step (4.d):

    migrations.DeleteModel(name='HistoricalModleName'),

Nostalg.io’s way worked in forwards (auto-generating all other apps FKs referencing it). But i needed also backwards. For this, the backward AlterTable has to happen before any FKs are backwarded (in original it would happen after that). So for this, i split the AlterTable in to 2 separate AlterTableF and AlterTableR, each working only in one direction, then using forward one instead of the original in first custom migration, and reverse one in the last cars migration (both happen in cars app). Something like this:

#cars/migrations/0002...py :

class AlterModelTableF( migrations.AlterModelTable):
    def database_backwards(self, app_label, schema_editor, from_state, to_state):
        print( 'nothing back on', app_label, self.name, self.table)

class Migration(migrations.Migration):                                                         
    dependencies = [
        ('cars', '0001_initial'),
    ]

    database_operations= [
        AlterModelTableF( 'tires', 'tires_tires' ),
        ]
    operations = [
        migrations.SeparateDatabaseAndState( database_operations= database_operations)         
    ]           


#cars/migrations/0004...py :

class AlterModelTableR( migrations.AlterModelTable):
    def database_forwards(self, app_label, schema_editor, from_state, to_state):
        print( 'nothing forw on', app_label, self.name, self.table)
    def database_backwards(self, app_label, schema_editor, from_state, to_state):
        super().database_forwards( app_label, schema_editor, from_state, to_state)

class Migration(migrations.Migration):
    dependencies = [
        ('cars', '0003_auto_20150603_0630'),
    ]

    # This needs to be a state-only operation because the database model was renamed, and no longer exists according to Django.
    state_operations = [
        migrations.DeleteModel(
            name='Tires',
        ),
    ]

    database_operations= [
        AlterModelTableR( 'tires', 'tires_tires' ),
        ]
    operations = [
        # After this state operation, the Django DB state should match the actual database structure.
       migrations.SeparateDatabaseAndState( state_operations=state_operations,
         database_operations=database_operations)
    ]   

I’ve built a management command to do just that – move a model from one Django app to another – based on nostalgic.io’s suggestions at https://stackoverflow.com/a/30613732/1639699

You can find it on GitHub at alexei/django-move-model

Coming back to this after a couple of months (after successfully implementing Lucianovici’s approach), It seems to me that it becomes much simpler if you take care to point db_table to the old table (if you only care about the code organisation and don’t mind outdated names in the database).

• You won’t need AlterModelTable migrations, so there’s no need for the custom first step.
• You still need to change the models and relations without touching the database.

So what I did was just take the automatic migrations from Django and wrap them into migrations.SeparateDatabaseAndState.

Note (again) that this only could work if you took care to point db_table to the old table for each model.

I’m not sure if something is wrong with this that I don’t see yet, but it seemed to have worked on my devel system (which I took care to backup, of course). All data looks intact. I’ll take a closer look to check if any problems come up…

Maybe it’s also possible to later rename the database tables as well in a separate step, making this whole process less complicated.

Coming this is one a little late but if you want the easiest path AND don’t care too much about preserving your migration history. The simple solution is just to wipe migrations and refresh.

I had a rather complicated app and after trying the above solutions without success for hours, I realized that I could just do.

rm cars/migrations/*
./manage.py makemigrations
./manage.py migrate --fake-initial

Presto! The migration history is still in Git if I need it. And since this is essentially a no-op, rolling back wasn’t a concern.

You can do this relatively straightforwardly, but you need to follow these steps, which are summarized from a question in the Django Users’ Group.

1. Before moving your model to the new app, which we will call new, add the db_table option to the current model’s Meta class. We will call the model that you want to move M. But you can do multiple models at once if you want to.

   class M(models.Model):
       a = models.ForeignKey(B, on_delete=models.CASCADE)
       b = models.IntegerField()
   
       class Meta:
           db_table = "new_M"
   

2. Run python manage.py makemigrations. This generates a new migration file that will rename the table in the database from current_M to new_M. We will refer to this migration file as x later on.

3. Now move the models to your new app. Remove the reference to db_table because Django will automatically put it in the table called new_M.

4. Make the new migrations. Run python manage.py makemigrations. This will generate two new migrations files in our example. The first one will be in the new app. Verify that in the dependencies property, Django has listed x from the previous migrations file. The second one will be in the current app. Now wrap the operations list in both migrations files in a call to SeparateDatabaseAndState to be like so:

   operations = [
       SeparateDatabaseAndState([], [
           migrations.CreateModel(...), ...
       ]),
   ]
   

5. Run python manage.py migrate. You are done. The time to do this is relatively fast because unlike some answers, you’re not copying records from one table to the other. You are just renaming tables, which is a fast operation by itself.