title: Recommended way to clean old Entity Framework Core migrations
body: <p>After developing our application for a while we've accumulated quite a bit of EFCore database migrations. Since EFCore adds a snapshot of the entire db model to every migration, this code adds up quite a bit. After analysis about 80% of our compile time is spend on the migrations (compiling + Roslyn analyzers).</p>
  
  <p>So it's time to clean up some old migrations! But what's the best way to do this? There doesn't seem to be any official guidance on it...</p>
  
  <p>We don't need any rollbacks (we only roll forward), so that makes things more simple. We do need to support creating a database from scratch, and updating a database from the last few migrations.</p>
  
  <p>What I've tried:</p>
  
  <ol>
  <li><p>The nuclear option seems to be to delete all migrations and the model snapshot, and creating a new initial migration. While this is fine, it seems a bit dangerous. With this approach we need to be <em>very</em> careful that every part of the database schema is part of the code model. One edge case we for example ran into is that EFCore doesn't support checked constraints yet. So we added a checked constraint in a migration, but not in the code model. So when creating a new initial migration, the checked constraint was not part of it.</p></li>
  <li><p>As an experiment, I've tried to delete the model snapshot from all old migrations, since the snapshots are 90% of the code which cause the long compile time. I figured out, that EFCore only uses the snapshot as a compare tool to make a new migration. After deleting the snapshot, the old migrations were however no longer executed when they ran on a fresh database.</p></li>
  </ol>
  
  <p>So is there any better way to accomplish what I want?</p>