After a system has gone through many migrations, and evolved enough for a second version, does it make sense to keep the old migrations around? I mean, old versions will use them to upgrade to the new one, sure, but should a fresh install have its database go through all the "historical" changes before arriving at the current shape? My gut feeling is that a fresh install should create the database "as it is", not go through every mistake that was made in the product lifecycle until reaching a stable condition.

I've recently asked a question on SO about splitting a django app into multiple ones. Problem is: after I've done that I'll never be able to remove the old app, since the other ones' past migrations still refer to it, and would break without it, even if the current version of my project does not use it anymore. OTOH if I "rewrote the history" in a major update I could pretend that the broken app never existed in the first place, which I believe would make the code cleaner (past revisions would still exist in version control though).

The above scenario is just an example, but I'm interested in arguments about the general case: have fresh installs create the database as it is, or go through every migration ever done in the product lifecycle?

1 Answer 1


Yes, it's a good idea to clean up migration history. Having numerous migrations is really error prone. So it's good idea to make the current state of your servers into the new initial migration.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.