There is no conflict in the database when you are switching to the new way of dealing with the database schema changes, as the South migration history is saved in the south_migrationhistory database table; the Django migration history is saved in the django_migrations database table. The only problem is that the migration files for South have a different syntax than the Django core migrations; therefore, the South migrations have to be completely removed and replaced with Django migrations.

Thus, at first, we delete the South migration files (or they can be moved to a separate directory as backups, if preferred). Then, the makemigrations command recognizes the empty migrations directories and creates new, initial Django migrations for each app. Once these migrations are faked, the further Django migrations can be created and applied, as needed.