My incredibly lazy way of doing this:

1. Create a new model (User), extending AbstractUser. Within new model, in it’s Meta, override db_table and set to ‘auth_user’.

2. Create an initial migration using South.

3. Migrate, but fake the migration, using --fake when running migrate.

4. Add new fields, create migration, run it normally.

This is beyond lazy, but works. You now have a 1.5 compliant User model, which just uses the old table of users. You also have a proper migration history.

You can fix this later on with manual migrations to rename the table.

I think you’ve correctly identified that a migration framework like South is the right way to go here. Assuming you’re using South, you should be able to use the Data Migrations functionality to port the old users to your new model.

Specifically, I would add a forwards method to copy all rows in your user table to the new table. Something along the lines of:

def forwards(self, orm):
    for user in orm.User.objects.all():
        new_user = SiteUser(<initialize your properties here>)
        new_user.save()

You could also use the bulk_create method to speed things up.

I got tired of struggling with South so I actually ended up doing this differently and it worked out nicely for my particular situation:

First, I made it work with ./manage.py dumpdata, fixing up the dump, and then ./manage.py loaddata, which worked. Then I realized I could do basically the same thing with a single, self-contained script that only loads necessary django settings and does the serialization/deserialization directly.

Self-contained python script

## userconverter.py ##

import json
from django.conf import settings

settings.configure(
    DATABASES={ 
            # copy DATABASES configuration from your settings file here, or import it directly from your settings file (but not from django.conf.settings) or use dj_database_url
            },
    SITE_ID = 1, # because my custom user implicates contrib.sites (which is why it's in INSTALLED_APPS too)
    INSTALLED_APPS = ['django.contrib.sites', 'django.contrib.auth', 'myapp'])

# some things you have to import after you configure the settings
from django.core import serializers
from django.contrib.auth.models import User

# this isn't optimized for huge amounts of data -- use streaming techniques rather than loads/dumps if that is your case
old_users = json.loads(serializers.serialize('json', User.objects.all()))
for user in old_users:
    user['pk'] = None
    user['model'] = "myapp.siteuser"
    user['fields']["site"] = settings['SITE_ID']

for new_user in serializers.deserialize('json', json.dumps(old_users)):
    new_user.save()

With dumpdata/loaddata

I did the following:

1) ./manage.py dumpdata auth.User

2) Script to convert auth.user data to new user. (or just manually search and replace in your favorite text editor or grep) Mine looked something like:

def convert_user_dump(filename, site_id):
    file = open(filename, 'r')
    contents = file.read()
    file.close()
    user_list = json.loads(contents)
    for user in user_list:
        user['pk'] = None  # it will auto-increment
        user['model'] = "myapp.siteuser"
        user['fields']["site"] = side_id
    contents = json.dumps(user_list)
    file = open(filename, 'w')
    file.write(contents)
    file.close()

3) ./manage.py loaddata filename

4) set AUTH_USER_MODEL

*Side Note: One critical part of doing this type of migration, regardless of which technique you use (South, serialization/modification/deserialization, or otherwise) is that as soon as you set AUTH_USER_MODEL to your custom model in the current settings, django cuts you off from auth.User, even if the table still exists.*

We decided to switch to a custom user model in our Django 1.6/Django-CMS 3 project, perhaps a little bit late because we had data in our database that we didn’t want to lose (some CMS pages, etc).

After we switched AUTH_USER_MODEL to our custom model, we had a lot of problems that we hadn’t anticipated, because a lot of other tables had foreign keys to the old auth_user table, which wasn’t deleted. So although things appeared to work on the surface, a lot of things broke underneath: publishing pages, adding images to pages, adding users, etc. because they tried to create an entry in a table that still had a foreign key to auth_user, without actually inserting a matching record into auth_user.

We found a quick and dirty way to rebuild all the tables and relations, and copy our old data across (except for users):

• do a full backup of your database with mysqldump
• do another backup with no CREATE TABLE statements, and excluding a few tables that won’t exist after the rebuild, or will be populated by syncdb --migrate on a fresh database:
  • south_migrationhistory
  • auth_user
  • auth_user_groups
  • auth_user_user_permissions
  • auth_permission
  • django_content_types
  • django_site
  • any other tables that belong to apps that you removed from your project (you might only find this out by experimenting)
• drop the database
• recreate the database (e.g. manage.py syncdb --migrate)
• create a dump of the empty database (to make it faster to go round this loop again)
• attempt to load the data dump that you created above
• if it fails to load because of a duplicate primary key or a missing table, then:
  • edit the dump with a text editor
  • remove the statements that lock, dump and unlock that table
  • reload the empty database dump
  • try to load the data dump again
  • repeat until the data dump loads without errors

The commands that we ran (for MySQL) were:

mysqldump <database> > ~/full-backup.sql
mysqldump <database> \
    --no-create-info \
    --ignore-table=<database>.south_migrationhistory \
    --ignore-table=<database>.auth_user \
    --ignore-table=<database>.auth_user_groups \
    --ignore-table=<database>.auth_user_user_permissions \
    --ignore-table=<database>.auth_permission \
    --ignore-table=<database>.django_content_types \
    --ignore-table=<database>.django_site \
> ~/data-backup.sql

./manage.py sqlclear
./manage.py syncdb --migrate
mysqldump <database> > ~/empty-database.sql

./manage.py dbshell < ~/data-backup.sql

(edit ~/data-backup.sql to remove data dumped from a table that no longer exists)

./manage.py dbshell < ~/empty-database.sql
./manage.py dbshell < ~/data-backup.sql

(repeat until clean)