KI-gestützte Datenmigrationsvalidierung

Das echte Ausmaß des Problems

Datenmigrationsprojekte gelten intern oft als reine Logistics-Aufgabe: Daten von A nach B bewegen. Die eigentliche Schwierigkeit liegt nicht im Transport, sondern in der Verifikation, und hier klafft eine gefährliche Lücke zwischen dem, was Teams prüfen, und dem, was tatsächlich geprüft werden müsste.

Eine viel zitierte Zahl, meist Gartner zugeschrieben, sagt, dass gut 80 Prozent der Datenmigrationsprojekte Budget oder Zeitplan reißen. Die Primärstudie ist nicht öffentlich, wir konnten sie nicht prüfen, im Umlauf ist die Zahl vor allem über Blogs von Tool-Anbietern. Den Mechanismus dahinter kennt jeder, der eine Migration begleitet hat: Datenqualitätsprobleme, die erst nach dem Go-live sichtbar werden.

Das strukturelle Problem ist einfach beschreibbar: Manuelle Stichprobenvalidierung erfasst nur einen Bruchteil der Datensätze. Niemand kann 480.000 Kundensätze, 2 Millionen Transaktionszeilen oder 80.000 Produktstämme manuell prüfen. Also prüft man das Schema (stimmt die Spaltenanzahl?), einen Rowcount (stimmt die Zeilenanzahl?) und ein paar Stichproben aus gut sichtbaren Testfällen. Das erfasst grobe Fehler, aber nicht die subtilen.

Was bleibt unentdeckt:

• Transformationsfehler bei Wertemappings (Code A aus System 1 entspricht Code B in System 2, aber nur meistens, nicht immer)
• Encoding-Probleme bei Umlauten, Sonderzeichen oder Datumformaten zwischen Legacy-Datenbank und moderner Plattform
• Referentielle Integrität, Fremdschlüssel zeigen auf Datensätze, die nicht migriert wurden oder anders heißen
• Statistische Verteilungsabweichungen, die Durchschnittswerte im Zielsystem liegen 12 Prozent niedriger, obwohl jeder einzelne Datensatz valide aussieht
• Semantische Degradierung in Freitext-Feldern, Produktbeschreibungen wurden durch Encoding-Konversionen inhaltlich verändert

Keiner dieser Fehler ist im Migrationslog sichtbar. Keiner wirft eine Fehlermeldung. Sie tauchen erst auf, wenn jemand mit einem konkreten Anliegen im neuen System nachschaut.

Mit vs. ohne KI, ein ehrlicher Vergleich

Belastbare Vergleichszahlen zu Stichprobentiefe und Fehlerquoten nach dem Go-live haben wir nicht gefunden. Die Tabelle beschreibt den Unterschied, nicht seine Größe.

Einschätzung auf einen Blick

Zeitersparnis, niedrig (2/5) Bei der ersten Migration spart das Framework keine Zeit, sein Aufbau kostet 3 bis 6 Wochen, ungefähr so viel wie eine gründliche manuelle Prüfung. Der Gewinn liegt in der Abdeckung: jeder Datensatz statt einer Stichprobe. Zeit spart es ab der zweiten Migration auf dasselbe Zielsystem, dann 1 bis 2 Wochen statt wieder sechs. Anwendungsfälle wie KI-gestützte Code-Reviews oder KI für technischen Kundensupport sparen täglich Zeit, Migrationsvalidierung nur je Projekt.

Kosteneinsparung, mittel (3/5) Der Hebel ist asymmetrisch: Ein Fehler nach dem Go-live kostet Korrekturbuchungen, Rückfragen, manchmal Vertragsstrafen, und je nach System ein Vielfaches der Prüfung vorher. Wie viel, ist nicht belegt, die oft genannten sechsstelligen Beträge sind Beraterangaben, keine Studie. Der Fall aus dem Einstieg, drei falsche Provisionsabrechnungen, kostet eher Tage als Hunderttausende. Gespart wird außerdem nur die Differenz: Auch ein vor dem Go-live gefundener Fehler muss korrigiert werden, nur billiger.

Schnelle Umsetzung, mittel (3/5) Das Validierungs-Framework braucht einmalig 3–6 Wochen Developer-Aufwand: Tools installieren, Datenbankverbindungen einrichten, Qualitätsregeln definieren, in die CI/CD-Pipeline integrieren. Anschließend ist es für jede weitere Migration wiederverwendbar. Das ist kein Overnight-Start, aber deutlich einfacher als AIOps-Produktionsmonitoring (Score 2) oder Release-Management-Automatisierung (Score 1).

ROI-Sicherheit, mittel (3/5) Der Nutzen ist real, aber die Kausalität ist schwer zu belegen: War der verhinderte Schaden tatsächlich ein schwerer Fehler, oder wäre er ohnehin aufgefallen? Du kannst die Fehler zählen, die das System vor dem Go-live findet, aber wie groß der Schaden geworden wäre, wenn sie unentdeckt geblieben wären, bleibt Schätzung. Deshalb ist die ROI-Sicherheit nur mittel.

Skalierbarkeit, mittel (3/5) Dasselbe Framework validiert Migration Nummer zwei und Nummer fünf ohne proportional steigende Kosten. Aber Datenmigration ist kein kontinuierlicher Betrieb, es sind diskrete Projekte. Die Skalierbarkeit ist pro Unternehmen begrenzt auf die Anzahl der jährlichen Migrationsprojekte, nicht auf unbegrenztes Wachstum wie beim Ticketing-System oder Code-Review-Assistant.

Richtwerte, stark abhängig von Systemgröße, Migrationskomplexität und vorhandener Infrastruktur.

Was die Validierung konkret macht

Der technische Ansatz lässt sich in drei Schichten zerlegen, die aufeinander aufbauen:

Schicht 1, Statistische Profil-Vergleiche Bevor irgendjemand einzelne Datensätze anschaut, vergleicht das System statistische Kennzahlen zwischen Quell- und Zielsystem: Mittelwerte, Mediane, Standardabweichungen, Nullquoten, Werteverteilungen pro Spalte. Wenn ein Betragsfeld im Altsystem einen Durchschnittswert von 4.200 Euro hat und im Zielsystem plötzlich 380 Euro, ist das ein Signal, auch wenn jeder einzelne Datensatz technisch valide ist. Tools wie Great Expectations oder Soda Core automatisieren genau das: einmal konfiguriert, läuft dieser Vergleich bei jeder Testmigration in Minuten.

Schicht 2, Regelbasierte Geschäftslogik-Assertions Jedes Unternehmen hat implizite Regeln, die im Altsystem erzwungen wurden: Debitorensalden sind immer positiv, Lieferdaten liegen nach Bestelldaten, Provisionsstufen gehören zu einem definierten Wertebereich. Diese Regeln werden als explizite Assertions formuliert und nach jeder Testmigration geprüft. Das klingt banal, ist aber genau das, was im Projekt von Thomas Berger fehlte. Die Regel „Provisionsstufen B und C müssen ihren Quellwerten entsprechen” hätte den Fehler in der ersten Testmigration gefunden.

Schicht 3, Semantische Textprüfung für Freitext-Felder Wenn Produktbeschreibungen, Kundennamen oder Notizfelder zwischen Systemen übertragen werden, können Encoding-Konversionen Texte inhaltlich verändern: Umlaute werden zu Fragezeichen, Zeilenumbrüche verschwinden, Sonderzeichen werden falsch interpretiert. Soll der Text identisch bleiben, reicht ein exakter Vergleich, etwa ein Hash je Datensatz in Quelle und Ziel: schneller und genauer als jedes Modell, und er skaliert auf Millionen Zeilen. NLP-basierte Einbettungsmodelle, die semantische Ähnlichkeit berechnen, lohnen sich dort, wo Texte beim Umzug absichtlich verändert werden, etwa gekürzt, umformatiert oder übersetzt. Dann ist ein Ähnlichkeitswert unter einer Schwelle, die ihr an Stichproben festlegt, ein Hinweis auf Verluste.

Die drei Schichten werden in eine automatisierte Pipeline eingebettet, die bei jeder Testmigration läuft, ähnlich wie Unit-Tests in der Softwareentwicklung. Das Ergebnis ist ein strukturierter Validierungsbericht: welche Checks bestanden haben, welche fehlgeschlagen sind und wie viele Datensätze betroffen sind.

Die stille Gefahr: Was manuelle Stichproben nicht sehen

Das gefährlichste an Datenmigrationsfehlern ist nicht ihre Existenz, es ist ihre Unsichtbarkeit. Migrationstools melden keinen Fehler, wenn ein Zahlenwert durch eine fehlerhafte Konvertierungsformel systematisch falsch skaliert wird. Das System funktioniert, die Logs sind grün, das Dashboard zeigt Erfolg.

Es gibt drei Kategorien stiller Fehler, die in der Praxis am häufigsten unentdeckt bleiben:

Verteilungsverschiebungen ohne einzelne Fehler. Stell dir vor, ein Betragsfeld wird durch einen Trennzeichen-Fehler falsch interpretiert: Aus 1.234,50 Euro werden 123.450 Euro, weil beim Import beide Trennzeichen verloren gehen. Jeder einzelne Datensatz ist technisch valide, liegt in einem akzeptablen Wertebereich, und der Rowcount stimmt. Nur die statistische Verteilung liegt um Faktor 100 daneben. Manuelle Stichproben entdecken das nicht, wenn die Tester glatte Beträge ohne Nachkommastellen wählen, die in beiden Formaten gleich aussehen.

Referentielle Integritätsverluste im Verborgenen. In Altsystemen gibt es oft Datensätze, die auf Lookup-Tabellen verweisen, die im Zielsystem leicht anders heißen. Der Fremdschlüssel existiert, der referenzierte Datensatz auch, aber die Verbindung ist gebrochen, weil der Schlüsselraum migriert wurde. In Berichten taucht diese Zeile dann als „unbekannte Kategorie” oder Leerzeile auf, ohne Fehlermeldung. Erst Monate nach dem Go-live, wenn jemand nach einem Drill-down sucht, fällt auf, dass 3.400 Transaktionen keiner Kostenstelle mehr zugeordnet sind.

Encoding-Schäden in Textfeldern. Encoding-Konversionen zwischen Altsystemen (oft Windows-1252 oder Latin-1) und modernen Systemen (UTF-8) erzeugen charakteristische Muster: Umlaute werden zu Fragezeichen, das Eurozeichen zu einem obskuren Sonderzeichen, Apostroph-Varianten zu lesbaren Zeichen, die aber die Datenbanksuche brechen. Diese Schäden sind in einem Textfeld mit 200 Zeichen unsichtbar, bis jemand den Volltextsearch auf „Müller” benutzt und 0 Ergebnisse bekommt, obwohl 47 Einträge vorhanden sein sollten.

Alle drei Kategorien haben gemeinsam: Sie erzeugen keine Fehlermeldung im Migrationsprotokoll. Sie erscheinen erst, wenn ein echter Nutzer ein echtes Geschäftsproblem damit lösen will. Und dann ist der Go-live bereits passiert.

Konkrete Werkzeuge, was wann passt

Die Werkzeugwahl für Migrationsvalidierung hängt stark davon ab, was du migrierst, in welche Zielinfrastruktur und wie viel Entwicklerkapazität du hast.

Great Expectations (GX Core), wenn du eine SQL-Datenbank prüfst Das meistgenutzte Open-Source-Framework für Datenqualitätsprüfungen. GX Core läuft komplett kostenlos (Apache-2.0-Lizenz), verbindet sich direkt mit PostgreSQL, SQL Server, MySQL, Snowflake und den meisten Cloud-Warehouses. Du definierst Qualitätsregeln als „Expectations”, z.B. „Kundennummern sind eindeutig”, „Betragsfeld hat keine negativen Werte”, und bekommst nach jeder Testmigration einen HTML-Bericht mit exakten Verletzungszahlen. Einschränkung: erfordert Python-Kenntnisse und direkten Datenbankzugang. Keine grafische Oberfläche in der Open-Source-Version. GX Cloud (verwalteter Dienst mit UI) kostet ab ca. 500 USD/Monat.

Soda Core, wenn du YAML statt Python bevorzugst Funktional ähnlich wie Great Expectations, aber die Qualitätsregeln werden als YAML-Dateien statt Python-Code geschrieben. Das macht sie zugänglicher für Teams, die kein Python können oder wollen. Soda Core hat native Reconciliation-Checks, du kannst zwei Datenbanken direkt miteinander vergleichen, ohne eigene SQL-Queries zu schreiben. Kostenlos (Open Source). Soda Cloud (UI + Alerting) hat einen kostenlosen Plan, der Team-Plan kostet 750 US-Dollar im Monat.

dbt Tests, wenn du sowieso dbt in der Pipeline nutzt Wenn deine Datentransformationen in dbt laufen, hast du bereits ein eingebautes Test-Framework. dbt-Tests prüfen Uniqueness, Not-Null, Referentielle Integrität und Custom SQL-Assertions als Teil des regulären Build-Prozesses. dbt test läuft nach jedem dbt run automatisch. Erfordert keine zusätzlichen Tools. dbt Core ist Open Source und kostenlos, dbt Cloud Developer-Plan ebenfalls kostenlos (Einschränkungen bei Modellanzahl).

Datafold, wenn du Warehouse-zu-Warehouse migrierst und SQL-Code übersetzen musst Datafold kombiniert KI-gestützte SQL-Dialekt-Übersetzung mit automatischem Cross-Database-Diffing. Wenn du von Oracle oder SQL Server nach Snowflake oder Databricks migrierst und dabei komplexe Stored Procedures in dbt-Modelle überführen musst, automatisiert Datafold sowohl die Code-Übersetzung als auch die Validierung der Datenparität. Pricing ist outcome-basiert je Migrationsprojekt, kein öffentlicher Listenpreis. Sinnvoll ab mittlerer Migrationskomplexität, wenn Developer-Kapazität für manuelle SQL-Übersetzung zu teuer ist.

Ataccama ONE, wenn du Governance und MDM brauchst Für Unternehmen mit komplexen Master-Data-Management-Anforderungen, Stammdaten müssen über mehrere Quellsysteme hinweg konsolidiert, dedupliziert und validiert werden. Ataccama bietet KI-gestützte Regel-Generierung und Anomalieerkennung, aber zu Enterprise-Preisen (typisch 90.000–250.000 USD/Jahr). Sinnvoll für Konzerne, für KMU mit einer einzigen Migration fast nie wirtschaftlich.

Wann welches Tool:

• Einzelne SQL-Datenbank validieren → Great Expectations oder Soda Core
• dbt bereits im Einsatz → dbt Tests reichen für einfache Prüfungen, Great Expectations für statistische Tiefe
• Warehouse-Migration mit Code-Übersetzung → Datafold
• Enterprise mit MDM-Anforderung → Ataccama ONE

Das Framework in der CI/CD-Pipeline

Der eigentliche Wert der KI-gestützten Validierung liegt nicht im einmaligen Einsatz, sondern in der Integration als automatischer Schritt bei jeder Testmigration. Ähnlich wie Unit-Tests in der Softwareentwicklung, niemand führt Tests manuell vor jedem Commit aus, sie laufen automatisch in der Pipeline.

Das funktioniert so: Sobald eine neue Testmigration abgeschlossen ist (im Staging oder Pre-Prod), triggert die CI/CD-Pipeline automatisch den Validierungslauf. Das Ergebnis erscheint als strukturierter Report, grüne und rote Checks, mit exakten Zahlen zu verletzten Datensätzen. Erst wenn alle kritischen Checks grün sind, kann die Migration für den nächsten Schritt freigegeben werden.

Praktisch umsetzen mit den genannten Tools:

# Beispiel: GitHub Actions Schritt für Great Expectations
- name: Run data validation
  run: |
    python -m great_expectations checkpoint run post_migration_checkpoint
  env:
    DATABASE_URL: ${{ secrets.STAGING_DB_URL }}

Was die Integration bringt: Die Validierung läuft nicht mehr als separate manuelle Aufgabe „irgendwann vor dem Go-live”, sondern als Pflicht-Gate nach jeder Testmigration. Teams sehen sofort, welche Checks fehlschlagen, und zwar Tage bis Wochen vor dem Go-live, nicht danach.

Ein wichtiger Punkt: Die Pipeline-Integration macht das Framework wiederverwendbar. Die Erwartungen, die du für Migration A definiert hast, sind der Ausgangspunkt für Migration B, angepasst an die neue Zieldatenstruktur, aber nicht bei null begonnen. Das ist der Skalierungseffekt, der die Initialinvestition von 3–6 Wochen über mehrere Projekte amortisiert.

Datenschutz und Datenhaltung

Validierungstools verarbeiten produktive Unternehmensdaten, oft Kundenstammdaten, Finanztransaktionen, Personaldaten. Das hat DSGVO-Relevanz.

Open-Source-Tools (Great Expectations, Soda Core, dbt Core) laufen in deiner eigenen Infrastruktur. Sie sehen keine Daten außerhalb deines Netzwerks, keine Cloud-Verbindung, kein Drittanbieter-Server. Du brauchst keinen gesonderten Auftragsverarbeitungsvertrag (AVV) für das Tool selbst, nur für die Infrastruktur, auf der es läuft. Das ist der sauberste Weg für sensible Daten.

GX Cloud und Soda Cloud (die verwalteten Varianten) senden Metadaten und Validierungsergebnisse in US-Cloud-Infrastruktur. Wichtig: In der Standardkonfiguration werden keine Nutzdaten übertragen, nur statistische Ergebnisse. Aber du solltest prüfen, ob auch anonymisierte Stichproben übertragen werden, das ist konfigurierbar. Für beide Dienste gilt: AVV nach Art. 28 DSGVO erforderlich, Standardvertragsklauseln bei US-Verarbeitung.

Datafold verarbeitet Verbindungsmetadaten und Diff-Ergebnisse in US-Cloud. Für die tatsächliche Datenbankverbindung hast du die Wahl zwischen direktem Zugang (Daten bleiben in deinem System) und Metadaten-only-Modus. Kläre das im Vertrag.

Empfehlung für Unternehmen mit besonders sensiblen Daten (Gesundheit, Finanzen): Nutze ausschließlich Self-Hosted-Varianten. Great Expectations Core und Soda Core laufen auf deiner eigenen Infrastruktur, lokal, auf einem deutschen Cloud-Anbieter oder on-prem.

Was es kostet, realistisch gerechnet

Einmalige Aufbaukosten Das Validierungs-Framework mit Great Expectations oder Soda Core aufzubauen, Datenbankverbindungen einrichten, erste Expectations definieren, Pipeline-Integration, dauert realistisch 3–6 Wochen eines Data-Engineers oder Senior-Developers. Bei einem internen Tagessatz von 600–900 Euro entspricht das 9.000–27.000 Euro Opportunitätskosten. Externe Beratung für den Aufbau: 15.000–40.000 Euro, abhängig von Migrationsumfang und Systemkomplexität.

Tool-Lizenzkosten für den Einstieg: 0 Euro (Great Expectations Core, Soda Core, dbt Core sind kostenlos).

Laufende Kosten pro Migrationsprojekt

• Validierungslauf in Pipeline: Infrastrukturkosten für Rechenzeit, typisch 50–300 Euro pro Testmigration je nach Datenmenge und Cloud-Anbieter
• Data-Engineer für Pflege und Anpassung der Expectations: ca. 1–3 Tage je Migration
• GX Cloud, falls benötigt: Team-Plan auf Anfrage, typischerweise ab 500 US-Dollar im Monat
• Soda Cloud, falls benötigt: Team-Plan 750 US-Dollar im Monat

Was dagegensteht: Die vermiedenen Kosten Die kennst nur du. Belastbare Studien zu Schadenshöhen nach Migrationsfehlern haben wir nicht gefunden, Beraterangaben reichen bis in sechsstellige Beträge. Rechne mit eurem eigenen letzten Fall: Wie viele Personentage hat die Datenkorrektur im Betrieb gekostet, wer musste Kunden oder Mitarbeitenden etwas erklären, gab es Vertragsstrafen oder blockierte Lieferungen? Und zieh ab, was dieselbe Korrektur vor dem Go-live gekostet hätte, gespart wird nur die Differenz.

Wie du den Nutzen tatsächlich misst Nicht durch Berechnungen, sondern durch Counting: Wie viele Checks schlagen in der Pre-Go-live-Phase fehl? Was wäre jeder dieser Fehler wert gewesen, wenn er erst nach dem Go-live aufgefallen wäre? Das ergibt eine konkrete Liste mit konkreten Beträgen, kein theoretischer ROI, sondern ein Protokoll verhindeter Schäden.

Typische Einstiegsfehler

1. Nur das Schema validieren, nicht die Werte. Der häufigste Einstiegsfehler: Teams prüfen, ob alle Spalten übertragen wurden und ob die Datentypen stimmen. Das ist notwendig, aber nicht hinreichend. Ein Integer-Feld kann korrekt vom Typ Integer sein und trotzdem den falschen Wert haben. Die Werteebene, statistische Verteilungen, Wertebereichsprüfungen, Geschäftslogik-Assertions, ist der eigentliche Validierungsaufwand. Wer damit nicht anfängt, validiert effektiv nichts.

2. Expectations ohne Domain-Wissen definieren. Great Expectations und Soda Core können Erwartungen aus dem Quell-Datenprofil automatisch generieren, das ist ein guter Startpunkt. Aber die generierten Regeln kennen die Geschäftslogik nicht. „Bestellbeträge sind größer als null” ist automatisch ableitbar. „Bestellbeträge für Sonderkunden dürfen negativ sein, weil das Gutschriften sind” ist nicht ableitbar, und fehlt dann in der Validierung. Mindestens eine Person aus der Fachabteilung muss die generierten Expectations reviewen, bevor sie als maßgeblich gelten.

3. Nur auf den Staging-Daten, nicht auf Produktionsdaten testen. Staging-Daten sind oft bereinigt, vereinfacht oder alt. Die wirklich problematischen Datensätze, Sonderfälle, historische Ausnahmen, manuelle Korrekturen, sind nur in den Produktionsdaten. Wenn du ausschließlich auf synthetischen oder bereinigten Staging-Daten testest, findest du die interessanten Fehler nicht. Mindestens ein Testlauf auf einem anonymisierten Vollabzug der Produktionsdaten ist Pflicht, bevor der Go-live-Termin festgelegt wird.

4. Das Framework wird für eine Migration gebaut, dann nicht weiterentwickelt. Das ist der Wartungsfehler. Nach der ersten Migration liegen 80 Expectations für System A in der Pipeline. Migration B geht auf dasselbe Zielsystem, aber von einer anderen Quelle. Niemand passt die Expectations an, man verwendet sie unverändert. Die Folge: irrelevante Checks schlagen fehl (weil das Schema der neuen Quelle anders ist), echte Fehler bleiben unentdeckt. Jede Migration braucht einen kurzen Review-Schritt: Welche bestehenden Checks sind weiter relevant, was muss angepasst werden, was muss neu dazu?

Was mit der Einführung wirklich passiert, und was nicht

Die Technik ist das Einfachste an diesem Vorhaben. Die Menschen sind das Schwierigere.

Die Spannung zwischen IT und Fachbereich. Data-Engineers bauen das Framework, aber die Geschäftslogik-Regeln kommen aus dem Fachbereich, von Buchhaltern, Vertriebsleiterinnen, Supply-Chain-Verantwortlichen. Diese Personen haben in der Regel weder Zeit noch Lust, sich in die technische Konfiguration von Validierungstools einzuarbeiten. Was funktioniert: ein Workshop von 2–3 Stunden, in dem IT die fachlichen Prüfanforderungen als Fragen stellt und der Fachbereich antwortet, ohne je ein YAML-File zu öffnen. Die IT übersetzt die Antworten in Expectations. Das ist der einzige realistische Weg, wie Geschäftslogik in automatisierte Validierung gelangt.

Die „das läuft schon irgendwie”-Mentalität. Migrationsprojekte stehen unter Zeitdruck. Wenn die Validierung in der letzten Woche vor Go-live 23 fehlgeschlagene Checks meldet und der Go-live-Termin steht, ist die Versuchung groß, diese Checks als „unkritisch” zu klassifizieren, damit der Termin gehalten werden kann. Das ist genau das Verhalten, das schwerste Post-Go-live-Fehler produziert. Was dagegen hilft: Checks vor dem Projekt in drei Kategorien aufteilen, Go/No-Go-Blocker, Warnung, Informational. Diese Klassifikation muss vor dem Zeitdruck entstehen, nicht während.

Der Erkenntnisgewinn, den niemand erwartet. Fast immer entdeckt das Validierungs-Framework Probleme, die nichts mit der Migration zu tun haben, sondern mit der Qualität der Quelldaten. Duplikate, die seit Jahren im System sind. Fehlende Pflichtfelder bei 12 Prozent der Kundensätze. Referenzierte Kostenstellen, die seit zwei Jahren nicht mehr existieren. Das ist kein Fehler des Systems, das ist wertvolles Feedback über den Zustand deiner Daten, und eine Gelegenheit, sie vor der Migration zu bereinigen, statt das Problem in das neue System mitzunehmen.

Realistischer Zeitplan mit Risikohinweisen

Wichtig: Das Framework ist nach diesem Aufbau wiederverwendbar. Migration Nummer zwei mit demselben Zielsystem braucht nur noch 1–2 Wochen für Anpassung und Lauf, nicht wieder sechs Wochen.

Häufige Einwände, und was dahintersteckt

„Wir haben das doch immer schon manuell gemacht und es hat gereicht.” Das stimmt für einfache Migrationen kleiner, gut strukturierter Datenbestände. Es stimmt nicht mehr, sobald Datenvolumen, Systemkomplexität oder Fehlerkosten steigen. Die Frage ist nicht, ob manuelle Stichproben funktionieren, sie funktionieren für einen Teil der Fehler. Die Frage ist, ob du mit dem Teil einverstanden bist, der nicht gefunden wird. Wer eine SAP-S/4HANA-Migration mit 2 Millionen Datensätzen manuell validiert, entscheidet implizit, fast alle ungeprüft zu lassen.

„Das kostet zu viel Developer-Zeit.” Der Aufbau kostet 3–6 Wochen Developer-Aufwand, das stimmt. Aber diese Kosten stehen gegen das Risiko eines Post-Go-live-Vorfalls, der Wochen bis Monate Developer-Zeit für Rollback oder Datenkorrektur beanspruchen kann, plus Fachabteilungszeit, plus externe Beratung, plus Reputationsschaden. Die ehrliche Frage ist nicht, ob das Framework zu teuer ist, sondern wie hoch du die Wahrscheinlichkeit und Kosten eines schweren Migrationsfehlers einschätzt. Wenn die Antwort „niedrig und günstig” ist, brauchst du kein Framework. Wenn die Antwort „unklar” ist, solltest du anfangen.

„Wir haben für das ERP-Projekt kein KI-Budget.” Die Basistools, Great Expectations Core, Soda Core, dbt Tests, sind Open Source und kostenlos. Was du brauchst, ist Developer-Zeit, keine Lizenzen. Der KI-Anteil ist der statistisch-analytische Teil (Verteilungsvergleiche, semantische Textprüfung mit Embeddings), er läuft über Open-Source-Bibliotheken wie scikit-learn und sentence-transformers, ebenfalls kostenlos.

Woran du merkst, dass das zu dir passt

• Du planst eine ERP-, CRM- oder Datenbank-Migration in den nächsten 6–18 Monaten, egal ob On-Prem zu Cloud oder Systemwechsel
• Euer Datenbestand umfasst mehr als 100.000 Datensätze in den migrierten Kerntabellen, alles darunter lässt sich noch halbwegs manuell prüfen
• Es gibt IT-Kapazität für 3–6 Wochen Framework-Aufbau, mindestens ein Data-Engineer oder erfahrener Developer
• Die Fehlerkosten sind erheblich, ein Post-Go-live-Fehler würde mehr als 20.000–30.000 Euro kosten oder Kundenprozesse direkt beeinträchtigen
• Du hast die Quelldaten nicht vollständig unter Kontrolle, Legacy-Systeme mit jahrzehntelangem Datenbestand, manuelle Korrekturen, Altlasten

Wann es sich (noch) nicht lohnt, drei harte Ausschlusskriterien:

1. Unter ca. 100.000 Datensätzen in den Kerntabellen. Dann ist manuelle Validierung mit gezielten SQL-Queries realistisch umsetzbar. Der Framework-Aufbau übersteigt den Nutzen für kleine Migrationen. Stattdessen: strukturierte Checkliste mit 20–30 manuellen Prüfabfragen.

2. Kein Developer-Zugang zur Datenbank. Great Expectations, Soda Core und dbt benötigen direkten Lesezugang zur Quelldatenbank. Wenn das aus technischen oder organisatorischen Gründen nicht möglich ist, strenge Netzwerkisolation, keine Entwicklungsumgebung, ist das Framework-Setup nicht ohne erhebliche Vorarbeit zu realisieren.

3. Keine Kapazität für Quelldaten-Bereinigung. Das Validierungs-Framework findet Fehler, aber es behebt sie nicht. Wenn die Quelldaten in einem Zustand sind, der erhebliche Bereinigung erfordert, und dafür keine Ressourcen da sind, erzeugt das Framework mehr Frustration als Nutzen. Der erste Schritt ist dann Datenbereinigung, nicht Validierungsautomatisierung.

Das kannst du heute noch tun

Lade Great Expectations herunter, kostenlos, Open Source, kein Vendor-Lock-in. Richte eine Verbindung zu deiner Quelldatenbank ein (PostgreSQL, SQL Server, MySQL, alle unterstützt). Führe einen automatischen Profiling-Lauf auf eurer wichtigsten Datentabelle aus: Du bekommst sofort einen HTML-Report mit Nullquoten, Werteverteilungen und Inkonsistenz-Indikatoren je Spalte.

Das dauert einen halben Tag für einen erfahrenen Developer. Was du danach weißt: In welchem Zustand sind eure Quelldaten wirklich, bevor die Migration beginnt und die Probleme ins neue System wandern.

Für die Analyse spezifischer Migrationsprobleme hilft dieser Prompt als Ausgangspunkt:

Quellen & Methodik

• Gut 80 % gescheiterte Migrationsprojekte: meist Gartner zugeschrieben; die Primärstudie ist nicht öffentlich, wir haben sie nicht geprüft. Sekundärzitate bei solix.com und curiositysoftware.ie.
• Schadenshöhen nach Migrationsfehlern und Stichprobentiefe: keine veröffentlichte Primärstudie gefunden, deshalb nennt die Seite keine Zahlen.
• Great Expectations (GX Core), Soda Core: Open-Source-Projekte, beide Apache-2.0-lizenziert. Preise der Cloud-Varianten laut unseren Toolseiten (Great Expectations Mai 2026, Soda Core Juli 2026).
• Datafold Migration Agent: Produktdokumentation und Blog-Posts von datafold.com (2024); Pricing auf Anfrage beim Anbieter.
• dbt Tests: Open-Source-Dokumentation, dbt Labs (Stand Mai 2026).
• DSGVO Art. 28 (AVV): Datenschutz-Grundverordnung in der aktuell gültigen Fassung.

Du planst eine Migration in den nächsten 12 Monaten und fragst dich, welche Fehler euer spezifisches Quellsystem typischerweise produziert? Meld dich, das klären wir in einem kurzen Gespräch.