Migrating Data from old Database to new one

i am currently building a new version of a web application and i got an existing database. Now i want to have a new database for the new version, since the existing database is not quite optimal. I can’t alter the old one tho, since it’s currently still used in production.

Can i somehow build a new database table and fill it with altered versions of data from the old one?

For example lets imagine i got an old model:

class UserNumbers(model.Model):
    name=models.CharField(max_length=50, blank=True, null=True)
    phone_number1=models.CharField(max_length=50, blank=True, null=True)
    phone_number2=models.CharField(max_length=50, blank=True, null=True)
    phone_number3=models.CharField(max_length=50, blank=True, null=True)

and want to populate my new model:

from phone_field import PhoneField

class User(model.Model):
    name=models.CharField(max_length=50, blank=True, null=True)
class UserNumbers(model.Model):
    user_id = models.ForeignKey(User, on_delete=models.CASCADE)
    phone_number = PhoneField(help_text='Contact phone number')
    comment = models.CharField()

so is there some way like:

for data in UserNumbers_old:
    if data.phone_number1:

>Solution :

Yes, you can do that. But if you really have a production system going, the safest thing to do is to:

  • Create a new database, not just a new table.
  • Copy all the tables (backup from old, load into new; exact procedure will vary for MySQL vs. PostgreSQL, etc.) from the old database to the new database.
  • Use Django’s migrations to convert the table structures to optimize, add new fields, etc.
  • If the direct migrations don’t handle everything (e.g., based on this example, to create 1, 2 or 3 UserNumbers records per User depending on how many phone numbers are actually in the existing records), then you create a data migration to handle the conversion.

A data migration can do anything a regular Python program can do. But it has the advantage that some day when you want to upgrade the production system, you will be able to:

  • Backup (always, to be safe) the database
  • Run all the database structure and data migrations in one batch, with Django handling the details. You won’t have to remember that the data "migration" has to run between regular migrations 17 and 18 because it will actually be # 18 and the next regular migration will be 19, etc.
  • The migration won’t be dependent on having two different databases. Instead everything (whether in development (now) or production (later)) will be the one and only database as far as Django is concerned.

Leave a Reply