Von EF6 auf EF Core: was sich ändert, was bricht und wie der Umstieg sicher gelingt

In der Datenschicht geht eine .NET-Modernisierung leise schief. Die Masken sehen aus wie vorher, der Build ist grün, und eine Abfrage, die früher eine Bestellung mit ihren Positionen geladen hat, lädt jetzt die Bestellung ohne sie. Microsoft sagt es klar: EF Core ist eine komplette Neuentwicklung von Entity Framework, und einen direkten Upgrade-Pfad von EF6 gibt es nicht.

Die gute Nachricht: Sie müssen nicht alles auf einmal machen.

Müssen Sie jetzt umsteigen?

Nicht unbedingt. EF6 läuft auch auf modernem .NET: Version 6.5.2, erschienen im April 2026, ist mit .NET 10 kompatibel. EF Core dagegen läuft nur auf modernem .NET, nicht auf .NET Framework. Daraus ergibt sich die sichere Reihenfolge:

1. Die Anwendung von .NET Framework auf .NET 10 umstellen und EF6 behalten.
2. Danach von EF6 auf EF Core wechseln, Bereich für Bereich.

Zwei große Änderungen in einem Release machen es schwer zu erkennen, was ein Problem verursacht hat. Eine nach der anderen hält jeden Schritt überprüfbar. Wie man den ersten Schritt angeht, steht im Artikel über den Umstieg von .NET Framework auf .NET 10.

Warum überhaupt auf EF Core, wenn EF6 weiterläuft? Weil die gesamte Weiterentwicklung in EF Core stattfindet und EF6 keine neuen Funktionen mehr bekommt. In der Praxis heißt das: bessere Performance, Massenänderungen und -löschungen ohne Laden der Daten in den Speicher (ExecuteUpdate, ExecuteDelete) und die Werkzeuge, auf denen der Rest von .NET aufbaut. Microsoft nennt einen Kunden, bei dem eine schwere Abfrage nach dem Umstieg dank Query Splitting 40-mal weniger Last verursachte.

Die Reihenfolge, die funktioniert

1. Schritt 1Bestandsaufnahme der Datenschicht
2. Schritt 2EF6 auf .NET 10
3. Schritt 3EF Core Bereich für Bereich
4. Schritt 4EF6 entfernen

Schritt 3 ist möglich, weil EF6 und EF Core in derselben Anwendung nebeneinander laufen können. Bestellungen können auf EF Core wechseln, während die Rechnungsstellung noch mit EF6 läuft, und jeder Bereich geht für sich in Produktion.

Die Bestandsaufnahme in Schritt 1 beantwortet die Fragen, die den Aufwand bestimmen:

• Liegt das Modell in einer EDMX-Datei aus dem Designer oder im Code?
• Verlässt sich der Code auf Lazy Loading?
• Wie viel rohes SQL, Entity SQL und wie viele Stored Procedures gibt es?
• Welche Abfragen sind geschäftskritisch: Rechnungen, Lager, Lohn?
• Gibt es Integrationstests gegen eine echte Datenbank?

Unterschiede, die das Verhalten ohne Fehlermeldung ändern

Die meisten Unterschiede zeigen sich als Compilerfehler, und das sind die leichten. Diese hier kompilieren und verhalten sich trotzdem anders:

In EF6	In EF Core	Was zu tun ist
Lazy Loading funktioniert mit virtuellen Navigationseigenschaften	Aus, außer Sie fügen das Paket Microsoft.EntityFrameworkCore.Proxies hinzu und rufen UseLazyLoadingProxies() auf	Verknüpfte Daten explizit mit Include laden oder Proxies bewusst einschalten
Manche C#-Funktionen werden in SQL übersetzt	Nicht alle; ein nicht übersetzbarer Ausdruck wirft erst zur Laufzeit eine Ausnahme	Jeden Abfragepfad in Tests durchlaufen, nicht erst in Produktion
Änderungserkennung über den ganzen Graphen, häufig	Pro Entität und seltener	Code prüfen, der Entitäten ändert und sich auf automatische Erkennung verlässt
Verwaiste Kindzeilen bleiben erhalten	Abhängige Zeilen ohne Elternteil werden gelöscht	Beziehungen prüfen, in denen Kinder ihr Elternteil verlieren können
Data Annotations werden beim Speichern validiert	Keine Validierung beim Speichern	In der Anwendung vor dem Speichern validieren

Lazy Loading sollten Sie zuerst prüfen. In EF6 lädt dieser Code die Bestellpositionen beim ersten Zugriff. In EF Core ohne Proxies ist order.Lines einfach nicht geladen, und die Summe ist falsch, ohne jede Fehlermeldung:

var order = db.Orders.Single(o => o.Id == id);
// EF6 lädt hier die Positionen. EF Core ohne Proxies nicht.
var total = order.Lines.Sum(l => l.Amount);

Explizites Laden ist klarer und meist auch schneller:

var order = db.Orders
    .Include(o => o.Lines)
    .Single(o => o.Id == id);

Was es einfach nicht gibt

• EDMX. EF Core hat keinen Designer und liest keine EDMX-Dateien. Stattdessen wird das Modell aus der bestehenden Datenbank erzeugt und ab dann im Code gepflegt:

  dotnet ef dbcontext scaffold "Server=...;Database=Shop;Trusted_Connection=True;" Microsoft.EntityFrameworkCore.SqlServer

• Entity SQL und ObjectContext. Abfragen in Entity SQL wandern zu LINQ oder rohem SQL, und Code, der über IObjectContextAdapter auf den ObjectContext zugreift, muss neu geschrieben werden.

• Die Migrationshistorie. EF Core kann EF6-Migrationen nicht fortsetzen. Wenden Sie die letzte EF6-Migration an, legen Sie in EF Core eine neue erste Migration an und machen Sie von dort weiter. Datenbank und Daten bleiben, wie sie sind.

• Datenbank-Initialisierer und automatische Migrationen. Schemaänderungen laufen über explizite Migrationen.

Rohes SQL funktioniert weiterhin, mit sichereren Standards. FromSql macht aus interpolierten Werten SQL-Parameter:

var orders = await db.Orders
    .FromSql($"EXECUTE dbo.GetOpenOrders {customerId}")
    .ToListAsync();

Wie Sie prüfen, dass sich die Daten nicht geändert haben

„Es kompiliert“ beweist hier nichts, und Microsofts eigener Leitfaden sagt dasselbe. Was funktioniert:

1. SQL vergleichen. Das SQL protokollieren, das EF6 und EF Core für die kritischen Abfragen senden, und vergleichen. EF Core zeigt es mit ToQueryString() oder LogTo.
2. Gegen eine echte Datenbank testen, nicht gegen eine In-Memory-Datenbank. Unterschiede beim Laden und Löschen zeigen sich erst mit echten Tabellen und Beziehungen.
3. Ergebnisse vergleichen. Summen und Zahlen aus Rechnungsstellung, Lager oder Lohn, vorher und nachher, auf derselben Kopie der Produktionsdaten.
4. Bereich für Bereich releasen und in den ersten Tagen Fehler und langsame Abfragen in Produktion beobachten.

Wie lange es dauert

Grobe Richtwerte, wenn die Anwendung bereits auf modernem .NET läuft:

• ein kleines Modell, im Code konfiguriert, mit wenig rohem SQL: einige Tage
• eine typische Geschäftsanwendung mit EDMX-Modell, Lazy Loading und Stored Procedures: 2 bis 6 Wochen
• ein großes System mit Hunderten Entitäten, Entity SQL und ohne Tests: 2 bis 4 Monate, Bereich für Bereich, neben der normalen Entwicklung

Das Mapping selbst ist selten der langsame Teil. Das sind die Verhaltensunterschiede und die Tests, die belegen, dass sie behandelt sind.

Läuft die Datenschicht auf EF Core, sind die häufigsten Performance-Probleme in EF Core das Nächste, was sich zu prüfen lohnt.

Wie wir arbeiten

ProCoding ist ein .NET-Studio aus Split, Kroatien, und in der Datenschicht verbringen wir viel Zeit: EF-Core-Performance, Migrationen und die Übernahme von Systemen, die niemand anfassen will. Wir beginnen mit einer Bestandsaufnahme Ihrer Datenschicht, schlagen die Reihenfolge vor und stellen Bereich für Bereich um, mit Tests, die zeigen, dass sich die Daten nicht geändert haben. Allein, mit Ihrem Team oder als .NET Freelancer in Ihrem Team. Mehr zur Modernisierung älterer .NET-Anwendungen auf unserer Seite zu Blazor und Migration. Der erste Schritt ist ein kostenloses 30-minütiges Gespräch.

Quellen

• Port from EF6 to EF Core, Microsoft Learn
• Detailed cases for porting from EF6 to EF Core, Microsoft Learn
• Port an EF6 EDMX-based model to EF Core, Microsoft Learn
• What’s new in EF6, Microsoft Learn
• Lazy loading of related data, Microsoft Learn
• Client vs. server evaluation, Microsoft Learn