Maintain or migrate EF6-based applications with realistic guidance on what to keep, what to modernize, and when EF Core is or is not the right next step. Use when working in an EF6 codebase or planning a data layer migration.
Audit current EF6 usage before planning any migration. Identify which features the codebase depends on:
// Common EF6-specific patterns to inventory:
// - EDMX designer models (check for *.edmx files)
// - ObjectContext vs DbContext usage
// - Lazy loading with virtual navigation properties
// - Database.SqlQuery<T>() for raw SQL
// - Stored procedure mappings in model
// - Spatial types (DbGeography, DbGeometry)
Decide runtime vs ORM migration separately:
| Path | When to use |
|---|---|
| Keep EF6 on .NET Framework | Legacy app with no runtime pressure |
| EF6 on modern .NET | Runtime upgrade needed, ORM migration too risky |
| EF6 → EF Core | Clean data layer, no EDMX, minimal stored-procedure mapping |
For maintenance work — keep EF6 stable:
DbContext over ObjectContext for new codeAsNoTracking() for read-only queries[ConcurrencyCheck] or IsRowVersion()For migration work — validate each slice:
dotnet ef migrations add succeeds, queries produce equivalent results, lazy loading behavior matches expectationsDo not promise EF Core features to EF6 codebases — EF6 is stable and supported but not on the innovation path. Keep expectations realistic.
flowchart LR
A["Audit EF6 usage"] --> B{"EDMX or complex mappings?"}
B -->|Yes| C["High migration cost — consider keeping EF6"]
B -->|No| D["Evaluate EF Core migration"]
D --> E["Migrate one context at a time"]
E --> F["Integration test against real DB"]
C --> G["Modernize runtime only"]
F --> H["Validate query equivalence"]
G --> H