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?