Entity Framework 6 to EF Core migration: when it pays off, how to do it and what it costs

A window manufacturer in northern Italy runs its management system on Entity Framework 6 since 2014: 118 entities, two DbContext classes, a hand-drawn EDMX model and 40 stored procedures. It works. The owner still asks: "If the developer leaves, or Microsoft stops updating the engine, what do we have left?".

The honest answer has three numbers. A project of that size moves from Entity Framework 6 to EF Core in about 32-49 person-days, so 19,200-29,400 euro at a reference rate of 600 euro a day. It is done piece by piece, one context at a time, without stopping the business. And the cost depends less on the number of entities than on how many queries rely on lazy loading, how many stored procedures exist and how far the database drifted from the code.

This is the short English version. The full guide (in Italian) covers the inventory script, the eight differences that break code, baseline migrations, characterization tests and the shared transaction between the two engines.

Is Entity Framework 6 still supported?

EF6 is in maintenance: security and compatibility fixes, no new features. Everything new, including performance work, goes to EF Core.

The gap grows every year: compiled models, split queries, new data types, JSON support. And recent EF Core runs only on modern .NET, so a team on .NET Framework 4.8 usually has to plan the data layer and the runtime together. The wider picture is in .NET Framework to .NET 10 migration.

What are the routes?

Four routes: harden EF6 and stay, run EF6 on modern .NET, migrate to EF Core one context at a time, or rewrite data access with raw SQL. For a system used every day the third one almost always wins.

The piece-by-piece route is the strangler idea applied to the data layer, described in the strangler fig pattern. If most logic already lives in stored procedures, see also Dapper versus Entity Framework.

How much does it cost?

About 120 entities, two contexts and 40 stored procedures: 32-49 person-days, 19,200-29,400 euro at 600 euro a day. A small model of twenty entities costs 4,800-7,200 euro.

• Inventory and measurement: 3-4 days.
• Characterization test net: 6-10 days.
• Model and mappings: 8-12 days.
• Query rewrites: 10-15 days.
• Migrations and database: 2-3 days.
• Rollout and monitoring: 3-5 days.

The biggest cost drivers are lazy loading, stored procedures with unmapped results, spatial types, complex inheritance and a database changed by hand for years.

Which differences break the code?

Eight: namespaces, model configuration, lazy loading, validation, direct SQL, database functions, many-to-many and inheritance, and delete behavior. Lazy loading is the one that bites most.

In EF Core lazy loading is off by default, so navigation properties stay null. Attribute validation also disappears silently at save time. Both are found by characterization tests: the same query run against EF6 and EF Core on the same data, with results compared.

Can EF6 and EF Core run together?

Yes: two contexts on one database. Each table has a single writing engine, only EF Core changes the schema, and operations spanning both share one transaction on the same connection.

The database itself does not change. You create a baseline migration for the current state and move on from there.

What is the rule in five lines?

If you touch the data layer more than six times a year, must reach modern .NET or have slow queries, migrate piece by piece with a test net. If the program is small and static, harden it and wait.

1. Count contexts, entities and stored procedures.
2. Count yearly changes and the people who really know the model.
3. Find the hard spots: lazy loading, spatial types, hand-written SQL.
4. List the other applications using the same database.
5. Budget 32-49 person-days per 120 entities with 40 stored procedures, and adjust.

Send me those numbers and in half an hour I tell you which route fits and what it costs. More on how I handle these projects: legacy software modernization.