Update model with new object


I would need some recommendations on how to handle my migration.

Indeed, previously I had an object with a bunch of properties. Let’s call it ObjectA
Some of them need to be updated regularly and I would need to keep the history. we would then need to create a new object in a 1…n relation with ObjectA for each revision. we would end up like this:


This is not a problem but the tricky part comes when we would need to transfer the old properties to a new ObjectB. the next step would be to recreate a link of other objects in my model that previously were pointing to ObjectA that will now need to point to the objectB.

How could I “customize” or detail how to do my migration?
Should I update my model incrementally?

  • once to create my new objectB in my model

  • a script to initialize my objectB from objectA

  • update my model to create my link from different objects in my model to ObjectB

  • A script to point my different object/class to objectB

  • Update my model to remove my properties in ObjectA that are now covered in objectB and remove the links to objecA in other objects in my model.

I am not sure that my explanation is really clear. PLease let me know if it needs to be clarified.

Is it possible to do that in 1 step instead of all those steps?

thank you,


Unfortunately, your description of the situation is not clear to me.

Are you talking about keeping versioned copies of a model? If so, take a look at Django Packages : Versioning. (If you’re looking for a package to help you do something, djangopackages.org is a great place to start your search.)

If that’s not the situation, it might be more helpful if you provided the sample models and then addressed the issue in the context of those models.

(Also, your diagram was reformatted by the forum software. You can force the forum software to maintain your spacing by enclosing the block of text between lines of three backtick - ` characters. That means you’ll have a line of ```, then your text, then another line of ```.
This is also used when posting Python code since spaces are significant.)

Hi Ken,

yes this is a bit complicated to explain out of context.
a concrete example we could take a model like this:


  • Code
  • Description
  • Price

this model would need to become as below:


  • Code
  • Description


  • ProductCode
  • Price
  • CreationDate

This way, when the price is updated, we create a new entry in the prices object and we can keep the history of the prices.

In the example there are better ways to manage this but this is out of context to understand.
when doing my migration, I would need to

  • create a new price with the price already existing in the product object and a default date
  • remove the Price property in the Product object
  • Link a previous reference in other object to the price to the new price object instead of the Product as they should get the info from there and longer directly to the product.

I wonder if I need to do some iteration and manage it in several migrations

  • Migration1: Create the Price Class
  • Create all my prices
  • Migration2: Update other objects models to link to the price
  • Migration3: remove the Price property in my Product

or if there is a way to automatize this in a single migration?

I don’t know about doing this in a single migration, but I would look at it from the other direction.

Consider this:

  • Rename Product to Price. Your foreign keys will still be pointing to the right rows, you’ll just need to change the named references. (You’d be doing that anyway.)
  • Create the new Product model, adding an FK relationship from (new) Price to Product.
  • Iterate over all instances of Price, copying data to the new Product as appropriate and setting the FK.
  • Remove the now-unnecessary fields from Price.

It’s still multiple steps, but I believe it’s less risky than trying to update all the other models that might be referring to the original Product.

I wouldn’t try to do this in one migration. I’d be looking to do this in as “bullet-proof” a method as possible.


Yes indeed much easier and safer this way.

I’ll try this way