How to force migrations to a DB if some tables already exist in Django?

When you apply a migration, Django inserts a row in a table called django_migrations. That’s the only way Django knows which migrations have been applied already and which have not. So the rows in that table have to match the files in your migrations directory. If you’ve lost the migration files after they were applied, or done anything else to get things out of sync, you’ll have problems.. because the migration numbers in your database refer to different migration files than the ones in your project.

So before you do anything else, you need to bring things back into sync by deleting the django_migrations table rows for any migration files that you’ve lost somehow and can’t get back. The table should contain rows for only those migrations that you do have and that were actually applied to the database correctly.

Now you need to deal with any changes in your database that Django Migrations doesn’t know about.. and for that there are a few options:

If things worked out such that the database changes that were already applied to the database are in different migration files than the ones that weren’t, then you can fix it by running your migrations one at a time using the --fake option on any changes that are in reality already in the database. The fake option just writes the row to the django_migrations table marking the migration as done. Only do this if the database does in fact already have all the changes contained in that migration file.

And those migration files that contain only changes which have not been applied to the database, run without the --fake option and Django will apply them. eg:

# database already has it
manage.py migrate myapp 0003 --fake 
# need it
manage.py migrate myapp 0004
# database already has it
manage.py migrate myapp 0005 --fake

If you have migration files where some but not all of the changes have been applied, then you have a bigger problem. In that case, there are several ways to go about it (choose ONLY ONE):

1. Edit the migration files to put changes that have already been applied (whether Django did it or you did it manually does not matter) into lower number migrations, and put everything you need done into higher numbered files. Now you can --fake the lower number ones, and run the higher numbered ones as normal. Let’s say you have 10 changes you made to your models, and 5 of those changes are actually in the database already, but Django doesn’t know about them.. so when you run makemigrations, a new migration is created with all 10 changes. This will normally fail because the database server can’t for example add a column that already exists. Move these already-applied changes out of your new migration file, into the previous (already applied) migration file. Django will then assume that these were applied with the previous migration and will not try to apply them again. You can then migrate as normal and the new changes will be applied.

   If you don’t want to touch your older migration file, a cleaner way to do this is to first run makemigrations --empty appname to create an empty migration file. Then run makemigrations which will create another migration with all the changes that Django thinks need to be done. Move the already done migrations from that file into the empty migration you created.. then --fake that one. This will put Django’s understanding of what the database looks like will be in sync with reality and you can then migrate as normal, applying the changes in the last migration file.

2. Get rid of any new migrations you just created using makemigrations. Now, comment out or put back anything in your models that has not been applied to the database, leaving your code matching what’s actually in the database. Now you can do makemigrations and migrate appname --fake and you will get things back in sync. Then uncomment your new code and run ‘makemigrations’ then migrate as normal and the changes will be applied. If the changes are small (for example, adding a few fields), sometimes this is easiest. If the changes are large, it isn’t….

3. You can go ahead and (carefully) make the database changes yourself, bringing the database up to date. Now just run migrate --fake and if you didn’t mess up then everything will be ok. Again, this is easy for smaller changes, not as easy for complicated ones.

4. You can run manage.py sqlmigrate > mychanges.sql. This generates mychanges.sql containing all the SQL Django WOULD have executed against the database. Now edit that file to remove any changes that have already been applied, leaving what needs to be done. Execute that SQL using pgadmin or psql (you’re using postgresql I hope). Now the changes have all been made.. so you can run manage.py migrate --fake, this will bring Django into sync with reality and you should be all set. If your SQL skills are sufficient, this is probably the most straightforward solution.

I should add two warnings:

First, if you apply a later migration, eg 0003_foobar.py, and then things don’t work out and you decide to try going back and apply 0002_bazbuz.py, then Django will TAKE STUFF OUT OF YOUR DATABASE. For example a column you might have added in 0003 will be dropped along with its data. Since you say you can’t lose data, be very careful about going back.

Second, do not rush into running --fake migrations. Make sure that the entire migration you are about to fake is actually in the database already. Else it gets very confusing. If you do regret faking migrations and don’t want to roll back, you can erase django’s knowledge of the faked migration by deleting that row from the django_migrations table. It is ok to do this.. if you understand what you are doing. If you know that the migration really was not applied, then it’s ok.