Good news, this means South now comes with Django by default. I use South in every new Django project anyway, because database migration versioning is so necessary.
The upgrade path is to delete all your old migrations and create a new initial one.
http://south.readthedocs.org/en/latest/releasenotes/1.0.html
"As part of providing a migration path for authors of third-party apps and libraries for Django, South will now first look for migrations in the south_migrations directory, and then fall back to the migrations directory if this is not found.
This is intended to alleviate the namespace clash between South and Django migrations; prior to this, both were looking for a directory called migrations, and so it was impossible to ship a third-party app with support for both South and Django 1.7.
The recommendation is that you move your South migrations into the south_migrations directory (existing users will not notice the change if they upgrade South first), and then start a new set of Django 1.7 migrations in a migrations directory (the default)."
1) ./manage.py migrate 2) pip uninstall south 3) ./manage.py migrate
Better yet would be to have either South or Django 1.7 migrations check for the other's existence and run both sets of migrations and not force South to be removed. This would make it a truly seamless transition for the system administrator.
The problem I envisage is that when you add 1.7 support to your app, you move your old migrations into south_migrations and start a clean migrations dir, as the instructions say - but what happens when your next release makes a database change? If you want to support all active versions (1.4, 1.6 and 1.7) you'd have to add a South migration and a 1.7 migration to support both groups of users - but then they no longer have a clean upgrade path from South to 1.7.
From reading the docs, it looks like 1.7 schema migrations may detect the changes have already been made and skip over them, but what will happen when you have data migrations too?
Does 1.7 figure out which operation you're up to by comparing your migrations to the database state, and starting migrations once the two match? What if at some point you return to an older set of model fields - does it match on the earliest or the latest?
I plan on avoiding the issue as long as possible: get my apps as feature complete as possible under South (with instructions for 1.7+ users for creating their own migrations), then bump the version when I switch from South to Django migrations. I'll then try to backport bugfixes to the South version (as long as they don't change the db) until support for Django 1.4 and 1.6 are dropped.