Question: Is it possible (and safe) to create multiple migration paths?

I have a solution with EF6-based database (code first) that has evolved a lot since the start of the project.

The large number of migrations causes the dll to grow large and creation of a new database to become very slow.

Is it possible to add a new ‘initial’ migration that results in the same state as the latest migration, and keep both migration-paths in the assembly?

Eg:

   -> MInitial -> M2 -> M3 -> .. Mn -> MCurrent 
   add:                                    *
   ->                                  MInitial2
     (and in the future:)                  *     -> MNext

An installation that is currently at M3 (or M2 / Mn) should follow the first migration-path (install all migrations up to Mcurrent). A new installtion should use MInitial2 to get to the current state.

Of course, future migrations should be ‘compatible’ with both MCurrent and MInitial2.

Thanks, Erik

_Sorry for copying my original post from StackOverflow, but nobody commented on that post https://stackoverflow.com/questions/51855918/entity-framework-6-is-it-possible-and-safe-to-create-multiple-migration-path_

[ajcvickers]

@CZEMacLeod Sounds good.

[CZEMacLeod]

@ErikvdBurgwal @ajcvickers I have this approach in one of my projects. All the V1 migrations (V1.0 Initial…V1.1…V1.2…V1.n and a final V2.0) get moved to a ‘legacy’ V1 project along with an inherited DAL and a migrations configuration which includes an override to ensure the same context key. In the main app include a V2.0 Initial migration and edit it to have the same ID as the final V2.0 migration in the V1 project. The final output should be the same. In the DBInitializer for the main DBContext, do a call to GetPendingMigrations and check for the V1.0 Initial migration by name. If it exists, create an instance of the V1 DBContext and trigger it’s migrations (ignoring any AutomaticMigrationsDisabledException thrown as we may now be on V2.1 or higher). Then get the migration history table and delete all V1.x migrations for the current ContextKey leaving only the V2.0 Initial migration in the history. Since the migration for V2.0 exists the main DBContext now has its ‘first’ migration applied and the state is consistent. Now, whether it was on any V1.x state or empty, you can simply let the V2 migrations proceed. It will apply V2.0 initial if required, then any V2.1, V2.2 etc. after it. There were a few tricks I had to pull to get this to work cleanly, and it is all testing, testing, testing after that, but it definitely makes life easier than applying 20+ migrations for a ‘new’ empty system (in my case). You can repeat this when you get to V3.0 and allow any V1.x->V2.0 then any V2.x->V3.0 as well as Initial->V3.0 and then V3.x->V3.latest to keep things clean.