It’s quite an elaborate topic if I went around discussing Django version migrations. But a part of it is moving away from South and use Django’s internal migration capabilities. I did some things incorrectly when we migrated, but it’s a lesson learned and worth sharing.
- After Go-Live, the production database from old server was taken and moved to the new dev server for testing. makemigrations were run on the dev server that created the initial migration files. The migrations (fake) were ran on the dev server. The same steps were carried on for local machines, staging and production servers.
The right way:
- During the cutover, the database backup from the old server should have been applied on a local development machine first and makemigrations should have been run locally. The migration files thus created should have been checked into the repository (GIT or whatever). Now the fake migrations should have been run locally.
- Other users, dev, staging and production machines should have pulled from the repository (GIT) to get the migration files. This way, all files would be in sync and makemigrations wasn’t required to be run on all machines. Only running fake migration on all servers would have sufficed.
- Going forward, any changes made on the local development machines would have resulted in the normal steps of makemigrations and migrate (not fake this time). After the migration files were pushed to the repository (GIT), the source would have been pulled on other dev/stage/production machines and just running migrate would have been the right course of action.
After I realized I had to make model changes, I ran makemigrations on my local machine that re-created the migration files and then ran migrate –fake to ensure that everything is in sync. I committed the files to the repository (GIT). Then I ran made my model changes for the new DB fields and ran makemigrations again which created new migration files. After this, I ran migrate which updated the changes to the database schema and I committed the new migrations to the repository (GIT) as well.
Useful link from StackOverflow regarding the error – column name of relation django_content_type does not exist