Migrating from EF5 to EF6 with existing migrations

Question

Context:

I currently have a system built on Entity Framework 5, which we'd like to upgrade to 6.

However, it already has dozens of migrations applied. And not just that, we have unit tests that verify all migrations by creating a test database and updating to latest and back to initial, to ensure all Up and Down migrations can be properly applied.

From what I've been reading, if migrations have different EF version numbers, Update-database fails to cross that boundary, meaning, the unit test covering all migrations would never pass. I could be mistaken and EF migrations might be backwards-compatible.

Question:

In that scenario, would it be wiser to actually merge all old migrations into one large InitialCreate migration (recreated using EF6), deleting the MigrationHistory table and "fake-apply" the migration to the live database (by commenting out the code of that migration temporarily) to get the new history entry?

And second of all, is this something we'll have to do again when updating EF in the near future? If that's the case then it might seem like EF is missing some support regarding cross-version migrations.

Answer 1

I had also done same thing today (5-May-2014) and did not face issue mentioned by you and had used steps suggested in http://msdn.microsoft.com/en-us/library/upgradeef6.aspx so my old migrations still remains the same.

Though i faced some other issues related to
- Miniprofiler (need to use new with EF6 support)
- and one issue related to re-creation of all index after upgrading.

Answer 2

I ultimately ended up implementing what I described above in the question itself. All this was done AFTER migrating everything to EF6.

In my case I not only needed to apply this to my local database but to a live database as well.

The steps I used to accomplish that where the following (hopefully I'm not forgetting any, since this was a while back):

Backup your databases (both local and live), just in case you need to undo this.

First we need to create one merged migration for the entire database.

1. Change your ConnectionString to point to a new blank database.
2. Physically delete all migrations from your solution, as well as your initial creation one.
3. Run Add-Migration InitialCreate, which should add a migration to regenerate the entire database.

Now you don't really want to run that migration. In my case I only need that for unit tests, or to create new databases from scratch.

So then we continue:

1. Change your ConnectionString back to your local database.
2. Physically delete the MigrationHistory table in the database (or possibly just remove the rows, I can't recall exactly).
3. Comment out ALL the code whithin the InitialCreate migration, to make sure it will do nothing when applied.
4. Run Update-Database, which should add an entry to the MigrationHistory table simulating an initial creation of the database.
5. Uncomment the code in the InitialCreate migration.

The same process can be applied for the Live database. You can point to it in the ConnString, manually remove migration history, comment the implementation of the migration and apply it, to simulate creation, then uncomment.

From then on, the database and migrations should be in sync, and unit tests (on a separate database) should be able to call Down() and Up() on all migrations and still function properly.