Markus essentially answered that question in a later comment. In order to turn off the old app, you’ll have to edit the migration in the new app to make two changes:
Remove the dependency on the migration in the old app, and
Change the operation from a SeparateDatabaseAndState() which creates the model in new_app only in memory, to a regular CreateModel(); this is required for the whole set of migrations to work correctly on an empty database, when old_app is no longer available.
I should note, though, that while the issue is indeed long-standing, it seems that someone from Brasil has started working on it only a few weeks ago. Have you coordinated with them?
hi @shaib , thanks for the quick reply.
Actually i was doing research on this issue from about a month, trying to reproduce various edge cases with different approaches, but somehow i missed to assign it to myself.
Yes i saw that that someone from brazil started working on it and i’ll surely connect with him so that we can work together to find the best approach.
I have opened a draft PR for what was in my mind .
I have tested the code against some cases on a demo project and it was working fine (even for reverse migration). but there are some cases that need to be tested .
Adding more about the functionality , With this approach we have to move model without changing anything in the model definition. If we made changes to the moving model then those changes will not be detected with the MoveModel operation, running makemigration command again will detect those changes and new migration files will be created.
Only the fields which are referencing the moving model are handled during the MoveModel operation.
We can also modify rename_model() for moving models between apps but i don’t think that such big change will be preferred.
Also I’m still trying to figure out how can we create table for moved model on empty database when the old app is removed from INSTALLED_APPS .
Any feedback in appreciable.