EF6 to EF Core: 5 query translations that quietly break in production

Agave Information Soultions, LLC — Wed, 03 Jun 2026 05:08:00 +0000

Most teams plan an EF6 to EF Core migration as "swap the package, fix some namespaces, ship it." For straightforward CRUD codebases that's mostly true. For anything with real query complexity, you will hit a handful of translation differences that the upgrade tooling does not warn you about. The queries compile fine, the unit tests pass against an in-memory provider, and then production explodes the first time someone hits the page that runs the report.

These are the five that bit us hardest on real migrations. None of them are obvious from reading the official "what's new" page, and a couple of them are silent regressions in behavior rather than visible errors.

1. Client-side evaluation does not silently rescue you anymore

EF Core 1.x and 2.x had a feature called automatic client evaluation. If part of your LINQ query could not be translated to SQL, EF Core would happily run that part in memory after fetching the rest of the data from the database. It logged a warning, but the query worked.

EF Core 3.0 changed the default to throw instead of silently falling back. Code that ran fine for two years suddenly throws InvalidOperationException: The LINQ expression could not be translated.

The worst version of this is a query like:

csharp
var customers = ctx.Customers
    .Where(c => c.DisplayName.NormalizeForSearch() == query.NormalizeForSearch())
    .ToList();

NormalizeForSearch() is a custom C# extension method. EF6 happily fetched every row, ran the method on each one in memory, and filtered. The query was a full table scan and stayed quietly slow for years. After the EF Core upgrade it throws at runtime.

The remediation is not "add .AsEnumerable() before the Where" even though that "works." That just preserves the original full-table-scan behavior with the original O(n) memory cost. The right fix is to push the normalization into the query itself using EF.Functions.Like or a normalized column maintained at write time. Either of those produces real SQL with real index usage.

GroupBy translates much less aggressively

EF6 translated almost any GroupBy you threw at it. EF Core is far more conservative — for years, it required your GroupBy to fit a narrow shape (group key + aggregate functions) and would throw if you tried to project the group elements directly.

This works in both:


var totals = ctx.Orders
    .GroupBy(o => o.CustomerId)
    .Select(g => new { CustomerId = g.Key, Total = g.Sum(o => o.Amount) })
    .ToList();

This worked in EF6 but did not in EF Core 3-5, and only partially works in EF Core 7+:


var groups = ctx.Orders
    .GroupBy(o => o.CustomerId)
    .Select(g => new { CustomerId = g.Key, Orders = g.ToList() })
    .ToList();

The second one is asking for "give me each group along with the list of items in that gr# LINQ but hard to express in standard SQL. EF Core 7 added partial support via SQL Server window functions; older versions throw.

For migration purposes, audit every GroupBy in the codebase before you flip the switch. The shape that breaks most often is grouping followed by projecting the actual group elements rather than aggregations.

Restructuring usually means doing the grouping client-side after a flat query, or rewrifor aggregates.

String comparisons changed collation behavior

EF6 ran string comparisons through SQL Server with the database's default collation, whie accent-insensitive on most installations. EF Core leaves the comparison semantics up tothe provider, and the defaults are different across providers.

Where(c => c.Email == "foo@bar.com")

against a Latin1_General_CI_AS database returns rows where Email equals FOO@BAR.COM because the SQL collation is case-insensitive. The same query against PostgreSQL
returns zero rows because PostgreSQL is case-sensitive by default. If your application wver provision a PostgreSQL instance, you will spend a confused afternoon.

EF Core 5+ exposes EF.Functions.Collate for explicit collation control, and EF.Functionsttern matching that works the same across providers. Use those instead of relying on thedatabase default if your code might run against more than one provider.

A subtler form: string.Equals(c.Name, query, StringComparison.OrdinalIgnoreCase) translated to ordinary = in EF6 (the comparison enum was just ignored), but in EF Core it can throw "could not be translated" depending on version. Same shape of bug as #1.

DateTime.Now lands client-side in confusing ways

DateTime.Now evaluated in the context of a LINQ query does not have a consistent transla and providers.

var recent = ctx.Orders
    .Where(o => o.CreatedAt > DateTime.Now.AddDays(-7))
    .ToList();

EF6 translated this to WHERE CreatedAt > DATEADD(day, -7, GETDATE()) on SQL Server, whicery time. EF Core sometimes evaluates DateTime.Now once on the client at query construction time, then sends a constant to SQL. If your app builds the query at 12:00 and executes it at 12:30, EF6 uses 12:30, EF Core often uses 12:00.

For most queries this 30-minute drift does not matter. For session expiry, rate limiting, scheduled job pickups, or audit windows, it matters a lot.

The deterministic pattern: capture the time explicitly in a local variable and pass it as a parameter. Or use EF.Functions.GetUtcDate() to force server-side evaluation. Or move the time calculation into a
database function and call it explicitly. Any of those produces predictable behavior.

Lazy loading is off by default and the fix is not what you think

EF6 enabled lazy loading by default if your navigation properties were marked virtual. Ty fetches it.

EF Core does not enable lazy loading by default. The migration path that the documentatirosoft.EntityFrameworkCore.Proxies and call UseLazyLoadingProxies() on the options. That technically restores lazy loading, but it makes every navigation access into a separate database round trip — exactly the N+1 problem the rest of the EF Core team is trying to push you away from.

The better migration path is to audit where your code was relying on lazy loading and convert those sites to either explicit Include calls or projection into DTOs. It is more work, but the resulting queries
are faster, the N+1 patterns become visible at code review time instead of in production table.

If you do install the lazy loading proxies as a "get the migration unblocked" bridge, to put a real plan in place to remove it. The longer you ship on lazy proxies, the more code grows to depend on the implicit fetch behavior and the harder removal gets.

The pattern across all five

Every one of these breakages comes from the same root: EF6 was very permissive about hiding the gap between LINQ semantics and SQL semantics, and EF Core is less so. EF Core fails loudly (or silently
differently) in places where EF6 would have happily run something inefficient.

That sounds like a regression. It is actually the right tradeoff. The EF6 queries that "l table scans, N+1 patterns, or subtly wrong results that nobody noticed because the database was small enough that performance didn't expose them. EF Core's stricter posture forces those decisions to surface during migration instead of in production a year later when the data has grown.

The practical migration playbook:

Turn on LogTo for Microsoft.EntityFrameworkCore.Query.QueryCompilationStarting events during integration tests so you can see what each query actually translates to.
Run a load test against representative data volume before declaring the migration don the dev database often fail on production volume after the EF Core change.
Audit every GroupBy, every Where with custom methods, every navigation property access, and every DateTime.Now reference.
Treat Microsoft.EntityFrameworkCore.Proxies as a bridge, not a destination.

The "swap the package and ship it" plan turns into a multi-week project for non-trivial modernization is one of the things we work on most often at Agave Information Solutions(https://agaveis.com/dotnet-modernization). If you are heading into one of these migrations and want a sanity check on your pattern audit, the .NET Modernization (https://agaveis.com/dotnet-modernization)
page has more on how we approach it.

Agave Information Solutions

Agave Information Soultions, LLC — Wed, 03 Jun 2026 04:58:25 +0000

30 years on the Microsoft stack. Started writing .NET when the framework was still in beta in 2001.

Founded Tempest Telecom in 1996. We built the first Internet roaming service to provide access on all 7 continents, and a unified AAA platform that combined voice, dialup, WiFi, and satellite into one experience. The 2+ petabyte video platform that came out of that work is where I learned that query plans behave non-linearly at scale, and why backup strategy is architecture.

Founded Agave Information Solutions in Scottsdale in 2008. Today we modernize legacy .NET Framework applications onto modern .NET 10/9/8 with AI-ready architecture, design databases that need to handle real volume, and ship the kind of senior-engineering work most boutique shops outsource.

I write here about .NET migrations, EF Core gotchas, SQL Server query plans, AI integration into legacy stacks, and the lessons from running production systems at scale for a long time.

Find me elsewhere:

DEV Community: Agave Information Soultions, LLC

EF6 to EF Core: 5 query translations that quietly break in production

1. Client-side evaluation does not silently rescue you anymore

Agave Information Solutions