Introduction

With South, renaming a model field is not just a Python refactor. You need to update the model code and create a schema migration that renames the database column instead of dropping the old column and creating a new one. If you skip that distinction, South may treat the change as data loss.

Change the Model First

Suppose the original model looks like this:

class Customer(models.Model):
    full_name = models.CharField(max_length=100)

You want the field to be called name instead:

class Customer(models.Model):
    name = models.CharField(max_length=100)

At this point, South cannot safely infer that full_name and name are the same database column with a new label. Its auto-generated migration may try to delete one column and add another. That is why the migration needs manual editing.

Generate and Edit the South Migration

Create the migration in the normal way:

python manage.py schemamigration yourapp --auto

Then open the generated migration and replace the add-and-delete operations with a rename call. A manual South migration typically looks like this:

1from south.db import db
2from south.v2 import SchemaMigration
3
4class Migration(SchemaMigration):
5
6    def forwards(self, orm):
7        db.rename_column('yourapp_customer', 'full_name', 'name')
8
9    def backwards(self, orm):
10        db.rename_column('yourapp_customer', 'name', 'full_name')

The table name is the actual database table, usually app label plus model name in lowercase. The column names are the database column names, not necessarily the Python attribute names if db_column was customized.

Why Rename Is Better Than Delete and Add

A field rename preserves the existing data because the column itself stays in place. Only the column name changes. A delete-and-add migration is more dangerous because it can:

• remove existing values
• break constraints temporarily
• force you to write a data migration just to copy data that already exists

That is why db.rename_column is the key operation when the change is truly a rename.

Apply the Migration Carefully

Once the migration file is correct, run it as usual:

python manage.py migrate yourapp

After the migration, test the model from Django shell.

python manage.py shell

from yourapp.models import Customer
print(Customer.objects.values_list('name', flat=True)[:3])

If the data shows up under the new field name, the rename worked correctly.

Special Cases to Watch

If the field also changes type, nullability, or indexing, do not treat it as a pure rename. In that case, split the work into clear migration steps. Rename first if that is the real intent, then apply separate schema changes.

Also note that South is historical tooling from pre-Django-migrations projects. In older codebases that still carry South migrations, the right approach is usually to respect the existing workflow instead of mixing South and modern Django migration commands in the same app.

Common Pitfalls

• Letting South auto-generate a delete-and-add migration for what should be a rename.
• Renaming the Python field but forgetting to edit the migration file manually.
• Using the wrong database table or column name in db.rename_column.
• Combining a rename with other schema changes and making the migration harder to debug.
• Assuming South behaves like modern built-in Django migrations without checking the generated file.

Summary

• A South field rename should normally use db.rename_column.
• Change the model code, generate a migration, then edit the migration manually.
• A true rename preserves data better than deleting and re-adding the field.
• Verify the real table and column names before running the migration.
• Keep rename migrations small and explicit so rollbacks stay safe.