Zum Hauptinhalt springen

Case Study: Risikoarme SQL-Datenbank-Migrationen mit Entity Framework Core

Diese Case Study beschreibt, wie sich SQL-Datenbank-Migrationen mit Entity Framework Core in Enterprise-Umgebungen kontrolliert, reviewbar und reproduzierbar umsetzen lassen.

In mehreren B2B-Projekten – u. a. im Auftrag eines Maschinenbaukonzerns mit Microsoft SQL Server sowie in eigenen Projekten mit PostgreSQL und MySQL – habe ich Datenbankstrukturen kontrolliert und reproduzierbar migriert.

Mein Grundsatz: Migrationen müssen planbar, reviewbar und reproduzierbar sein – nicht „Black Box“ zur Deploy-Zeit.

Warum ich keine Runtime-Migration in Production verwende​

Das automatische Anwenden von Migrationen über context.Database.Migrate() zur Laufzeit ist bequem – aber in Enterprise-Umgebungen mit klaren Sicherheits- und Betriebsrichtlinien problematisch.

Typische Risiken​

  • Erhöhte Rechte für die Anwendung erforderlich
    Die App benötigt DDL-Rechte (CREATE/ALTER/DROP).
    In produktiven Umgebungen gilt jedoch das Prinzip Least Privilege – die Anwendung darf keine Tabellenstruktur ändern.

  • Race Conditions bei mehreren Instanzen
    In skalierenden Umgebungen können mehrere App-Instanzen parallel versuchen, Migrationen auszuführen.

  • Keine Review-Möglichkeit des generierten SQL
    SQL wird direkt ausgeführt, ohne vorherige technische Prüfung.

  • Fehlende Planbarkeit bei großen Tabellen
    Längere Locks oder blockierende DDL-Operationen können produktive Systeme beeinträchtigen.

  • Aufwändige Fehlerbehebung im Live-Deploy
    Schlägt eine Migration in CI/CD fehl, entstehen oft:

    • Fix-Migrationen
    • Pipeline-Restarts
    • manuelle Reparaturen
    • zunehmender Stage-Drift zwischen DEV/TEST/PROD

Diese Erfahrungen habe ich in realen Enterprise-Deployments mehrfach beobachtet.

Mein Migrations-Workflow (kontrolliert & reviewbar)​

Stattdessen verwende ich einen kontrollierten, artefaktbasierten Ablauf:

  1. Add-Migration erstellen
  2. Generierten C#-Migrationscode prüfen und ggf. anpassen
  3. SQL-Skript generieren (dotnet ef migrations script)
  4. Skript prüfen und bei Bedarf ergänzen
  5. Skript als Release-Artefakt bereitstellen
  6. Migration kontrolliert in DEV ausführen
  7. Nach erfolgreicher Validierung identisches Artefakt in TEST und PROD verwenden

Down-Migration in DEV​

Falls eine Migration fehlerhaft ist, verwende ich gezielt eine Down-Migration in DEV, um:

  • Schema-Fehler zu korrigieren
  • DDL-Reihenfolge anzupassen
  • Datenmigration zu verbessern
  • Performance-Auswirkungen zu prüfen

Erst wenn die Migration stabil ist, wird sie für höhere Stages freigegeben.

Datenmigration als Bestandteil der Migration​

Schema-Änderungen erfordern häufig begleitende Datenanpassungen.

Gängige Praxis:

  • Neue Spalte hinzufügen
  • Daten via UPDATE transformieren
  • Indizes neu erstellen
  • Alte Spalte entfernen

Diese SQL-Schritte werden bewusst und nachvollziehbar in Migrationen integriert – nicht implizit zur Laufzeit ausgeführt.

Sicherstellung synchroner Stages (DEV / TEST / PROD)​

  • Verwendung derselben Migration-Assembly als Source of Truth
  • Nutzung idempotenter SQL-Skripte
  • Kontrolle über __EFMigrationsHistory
  • Keine automatischen Schemaänderungen durch die App

Das Ergebnis: keine Stage-Drift, keine impliziten Strukturabweichungen.

Release-Artefakt statt Black Box​

Migrationen werden als Build-Artefakt erzeugt, z. B.:

  • efcore-idempotent.sql
  • optional: EF Migration Bundle

Dieses Artefakt:

  • stammt exakt aus dem Build der Applikation
  • wird versioniert und archiviert
  • wird in TEST und PROD identisch angewendet

Dadurch bleibt die Datenbankstruktur reproduzierbar und auditierbar.

Beispielhafte Projektstruktur​

MySolution/
  src/
    MyApp.Persistence.SqlServer/
      AppDbContext.cs
      Migrations/
        20260301_AddFoo.cs
        AppDbContextModelSnapshot.cs

  db/
    migrations/
      sqlserver/
        2026-03-01_efcore-idempotent.sql

Primär werden Änderungen im Migration-C#-Code vorgenommen.

Falls SQL manuell angepasst werden muss (z. B. für Datenmigration oder DDL-Reihenfolge), wird dieses Skript zusätzlich versioniert.

Fazit​

Ich setze Entity Framework Core Migrationen nicht als „automatischen Mechanismus“, sondern als kontrolliertes Architekturwerkzeug ein.

  • Keine unnötigen DDL-Rechte für Produktionsanwendungen
  • Reviewbare und testbare Migrationen
  • Down-Migration als Sicherheitsnetz in DEV
  • Synchronität zwischen DEV, TEST und PROD
  • Planbare Änderungen auch bei großen Tabellen

Gerade in Enterprise-Umgebungen reduziert dieser Ansatz Risiken erheblich und sorgt für stabile, nachvollziehbare Deployments.