Applying migrations to a really out of sync database

I've inherited a database that's in pretty bad shape. Basically the following:

• Most apps don't have a migrations folder or have an outdated one
• The south migration history table is out of sync with the database
• The database tables do not match up with the current models in Django (although I know what has changed between the models and tables)

I'm not worried about preserving past migration history or anything like that, but I do need to preserve the data currently in the database. I'm kind of looking for a way to declare the current database state the initial state and move forward from there. If necessary I can modify the models so that the database tables match the current models since I assume that is necessary to get started.

I've been messing around with this for a few hours, and I'd appreciate any advice for getting this straightened out.

Additional Notes:

• The database is using sqlite
• Moving to Django 1.8 is on the table but not for a few months

Instructions for django 1.6 with South

I would suggest downloading a dump of the database (or at the schema) and creating a new database with that on your local machine using sqllite.

Then delete all the existing /migrations folders in all of your apps Then delete everything in in the database table south_migrations

Now disable all your 'new' model changes that aren't in the database

Then make the initial migrations again

./manage.py schemamigration myapp --initial

Then fake it all, because the structure is already there ./manage.py migrate --fake

Now your migrations are in sync with your production database.

Now re-enable your new models changes then create the migrate each app ./manage.py schemamigration myapp

Then migrate to the new changes ./manage.py migrate

Note: on your server and dev machine you will need to ensure that you also delete the any old .pyc files inside the 'migrations' folders before creating any new migrations.

As per e4c5's comments above, you are going to have to do some of those steps again when you move to django 1.7/1.8 (as South got integrated into Django in 1.7), so you might want to consider upgrading to 1.7 at the same time (although thats not necessarily a trivial upgrade...).