EF6 to EF Core porting documentation outlines broken migration procedure

[mycroes]

The guide for porting from EF6 to EF Core mentions the possibility of migrating by using the existing database and removing the actual migration code from a new initial migration. From my personal attempt at doing this I'm however running into the following issues:

1. Table names in EF6 are based on type, in EF Core on DbSet property name
2. Primary keys and foreign keys in EF6 include dbo. in the constraint names (EF6: PK_dbo.Users, EF Core: PK_Users)
3. Foreign keys without foreign key property in EF6 generate names with underscore prefixes before the referenced table key column name, in EF Core the additional underscore is not there
4. Index names in EF Core include the table or entity name in the name (IX_TeamMembers_UserId), EF 6 uses the property name only (IX_UserId)
5. EF6 might have generated boolean columns as [bit] NOT NULL DEFAULT 0, EF Core omits the DEFAULT 0 for new tables (initial migration, so all tables are new). The DEFAULT 0 causes a constraint to be generated, which on migration down is removed by EF6 by looking up the constraint in sys.default_constraints, because the name is partially randomized. A new migration in EF Core that would remove the property would probably fail because the constraint is referencing the property

These are definitely not all. I think it's bad advice to tell people to migrate to EF Core like this, it will cause a lot of frustration when continuing development on the project that was migrated. Some of these issues can definitely be remedied using additional configuration in EF Core, which permits generation of a schema that is much closer to the original EF6 schema. However, when someone would remove that configuration to make use of EF Core defaults you'll again run into issues because you can't rename primary keys if a foreign key is referencing the table.

I think the only feasible approach is to ensure the EF Core model matches table names and column names from the EF6 model, creating a new database using EF Core migrations and copying the data (possibly inserting data with keys) from the old (EF6) to the new (EF Core) database.

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: e1226698-6874-6f8f-f716-1974152243fa
• Version Independent ID: 9e7bdb7a-d3dc-03a2-99f6-78aa46cc8357
• Content: Porting from EF6 to EF Core - Porting a Code-Based Model - EF
• Content Source: entity-framework/efcore-and-ef6/porting/port-code.md
• Product: entity-framework
• Technology: entity-framework-core
• GitHub Login: @ajcvickers
• Microsoft Alias: avickers

[rmmcgr]

I think it would be good to show a real-world example (in this article or another new one). I am part way through a migration of a mature, years-old, database that had many migrations that I am moving from EF6 to EF Core 7 and where we need to be able to support existing installations of our app (and database) and new installations.

The blog post below provided a good approach that helped immensely (just had to update the code examples for the slightly changed API surface in EF7).

https://www.mikee.se/posts/migrating_from_ef6_to_ef_core

Particularly useful was the tip about using the schema comparison tool in Visual Studio, some of the strategies to deal with making EF core conform to some of the old conventions from EF6 that need to be supported (until new migrations can be done in the future to update everything) and finally that need to manually create the new migrations table and seed it with the initial entry (obviously not running the whole "initial" migration itself).

[mycroes]

There are indeed some sensible points in the post linked by @rmmcgr. I ended the original issue text with stating the only feasible approach would be to copy the data, but of course my desire is to have an approach that works on the existing database.

If the conventions from EF6 could all be applied to the EF Core modelbuilder it would be possible to create a migration package that one could use for the initial migration, after that dropping the migration package should yield a migration to a database model that resembles what EF Core would normally do.

While I still hope this will happen (and sooner rather than later), the migration page is still online with the utterly broken advice of removing the initial migration up/down code.