Datenmigration in die Cloud: Governance vor der Migration
Daten ohne Governance in die Cloud zu migrieren ist wie umziehen, ohne zu wissen, was in jeder Kiste ist. Das Ergebnis ist vorhersehbar: duplizierte Daten, verwaiste Tabellen, PII in Umgebungen, die keine Compliance erfüllen, unterbrochene Abhängigkeiten und monatelange Post-Migrations-Bereinigung, die hätte vermieden werden können.
Dieser Leitfaden schlägt einen anderen Ansatz vor: die Grundlagen der Governance vor der Migration zu etablieren, nicht danach. Das Pre-Migrations-Inventar, das Mapping von Abhängigkeiten und die Klassifizierung sensibler Daten sind Schritte, die die meisten Organisationen entdecken, dass sie sie gebraucht hätten, wenn es bereits zu spät ist. Sie vorher durchzuführen reduziert Risiko, Kosten und Migrationszeit.
Warum Governance vor der Migration, nicht danach
Der Hauptgrund ist, dass die Migration von Daten ohne ihr Kennen die bestehenden Probleme verstärkt. Wenn du nicht weißt, welche Tabellen veraltet sind, wirst du veraltete Tabellen migrieren. Wenn du nicht weißt, welche Felder PII enthalten, wirst du PII in einer Cloud-Umgebung exponieren, die möglicherweise zugänglicher ist. Wenn du keine Abhängigkeiten zwischen Tabellen kennst, wirst du nachgelagerte Pipelines unterbrechen, von denen du nicht wusstest, dass sie existierten.
Die Kosten der Datenbeinigung und -organisation nach der Migration sind 3 bis 5 Mal höher als davor. In der Cloud hat jede gespeicherte Tabelle Kosten (Storage), jede Abfrage Kosten (Compute), und jedes falsch migrierte Datum erzeugt Korrekturarbeit in einer neuen Umgebung, in der das Team noch lernt. Mit Governance zu migrieren bedeutet, nur das zu migrieren, was man braucht, gut dokumentiert und korrekt klassifiziert.
Zudem bieten Cloud-Plattformen (BigQuery, Snowflake, Redshift, Databricks) native Governance-Fähigkeiten (Labels, Zugriffsrichtlinien, Audit-Logs), die während der Migration viel einfacher korrekt zu konfigurieren sind als rückwirkend. Wenn du mit einem sauberen Inventar und Sensibilitätsklassifizierungen in die Cloud kommst, kannst du diese Fähigkeiten vom ersten Tag an nutzen.
Pre-Migrations-Inventar: Was du hast und was du brauchst
Das Pre-Migrations-Inventar beantwortet drei Fragen: Welche Daten haben wir? Welche werden benötigt? Und welche können wir zurücklassen? Ein mit deinen On-Premise-Quellen verbundener Datenkatalog extrahiert automatisch die Metadaten aller deiner Tabellen: Name, Schema, Volumen, letzte Aktualisierung, Spalten und Beziehungen.
Mit dem vollständigen Inventar klassifiziere jedes Asset in eine von drei Kategorien. „Migrieren": aktive Assets mit bekannten Konsumenten und Geschäftswert. „Archivieren": historische Assets, die aus Compliance-Gründen benötigt werden, aber nicht für den Betrieb (in Cold Storage in der Cloud verschieben). „Löschen": veraltete Assets ohne Konsumenten oder Aufbewahrungsanforderungen. Bei einer typischen Migration können zwischen 20 % und 40 % der Assets archiviert oder gelöscht werden, was Umfang und Kosten der Migration reduziert.
Für jedes als „migrieren" klassifizierte Asset dokumentiere: den verantwortlichen Eigentümer, die bekannten Konsumenten (Teams und Dashboards), die Frische-Anforderungen (muss in Echtzeit, täglich oder wöchentlich aktualisiert werden?) und die Sicherheitsanforderungen (Enthält es PII? Welches Vertraulichkeitsniveau?). Diese Dokumentation leitet Architekturentscheidungen in der Cloud.
Mapping von Abhängigkeiten mit Lineage
Daten-Lineage ist vor einer Migration kritisch, weil es nicht offensichtliche Abhängigkeiten aufzeigt. Eine Tabelle, die unwichtig erscheint, könnte 15 Views und 3 Executive-Dashboards speisen. Wenn du diese Tabelle falsch oder mit einer Schemaänderung migrierst, brechen 15 nachgelagerte Prozesse ohne Vorwarnung.
Pre-Migrations-Lineage wird durch Analyse der SQL-Abfragen, die gegen deine Datenquellen ausgeführt werden, der View-Definitionen, der ETL-Jobs und der BI-Tool-Verbindungen aufgebaut. Das Ergebnis ist ein Abhängigkeitsgraph, der für jede Tabelle zeigt, was sie speist (Upstream) und was sie konsumiert (Downstream). Dieser Graph ist die Grundlage für die Planung der Migrationsreihenfolge.
Die Migrationsreihenfolge muss den Abhängigkeiten folgen: zuerst Quelltabellen (ohne Upstream-Abhängigkeiten im Migrationsumfang), dann abgeleitete Tabellen, die von ihnen abhängen, und schließlich Konsumenten (Dashboards, Berichte, APIs). In umgekehrter Reihenfolge zu migrieren erzeugt Zeitfenster, in denen nachgelagerte Prozesse auf eine Quelle zeigen, die nicht mehr existiert oder ein anderes Schema hat.
Klassifizierung sensibler Daten vor der Migration
Daten ohne Klassifizierung ihrer Sensibilität in die Cloud zu migrieren ist ein direktes regulatorisches Risiko. PII-Daten, die in einer On-Premise-Umgebung durch den Unternehmensnetz-Perimeter geschützt waren, werden in der Cloud einem anderen Zugriffsmodell ausgesetzt. Zugriffs-, Verschlüsselungs- und Aufbewahrungsrichtlinien müssen definiert werden, bevor die Daten in die neue Umgebung gelangen.
Die Pre-Migrations-Klassifizierung identifiziert jedes Feld, das personenbezogene Daten enthält (Name, E-Mail, Ausweisnummer, Telefon, IP-Adresse), sensible Finanzdaten, Gesundheitsdaten oder andere regulierte Daten. Für jedes klassifizierte Feld wird definiert: Sensibilitätsniveau (öffentlich, intern, vertraulich, eingeschränkt), Zugriffsrichtlinie (welche Rollen können es sehen), Verschlüsselungsrichtlinie (im Ruhezustand und bei der Übertragung) und Aufbewahrungsrichtlinie (wie lange wird es aufbewahrt).
Automatische PII-Erkennungstools können das gesamte Inventar scannen und automatisch Felder markieren, die personenbezogene Daten enthalten. Dies wandelt einen manuellen Prozess von Wochen (jede Spalte jeder Tabelle überprüfen) in einen stundenlangen Scan um. Das Ergebnis ist eine Sensibilitätskarte, die die Konfiguration von Zugriffsrichtlinien in der Cloud-Umgebung vom ersten Moment an leitet.
Migrationsplan mit integrierter Governance
Ein Migrationsplan mit integrierter Governance hat vier Phasen. Phase 1 (Woche 1–2): Inventar und Klassifizierung. Verbinde einen Datenkatalog mit deinen On-Premise-Quellen, extrahiere vollständige Metadaten, klassifiziere Assets (migrieren/archivieren/löschen), identifiziere PII und weise Eigentümer zu. Ergebnis: definierter und dokumentierter Migrationsumfang.
Phase 2 (Woche 3–4): Abhängigkeits-Mapping und Reihenfolgeplan. Erstelle das Lineage aller Assets im Umfang, identifiziere kritische Abhängigkeiten, definiere die Migrationsreihenfolge (Quellen zuerst, Abgeleitete danach, Konsumenten zuletzt). Validiere mit den Eigentümern jeder Domäne, dass der Plan korrekt ist. Ergebnis: validierte Migrationssequenz.
Phase 3 (Woche 5–8): Migration in Wellen. Migriere in Wellen entsprechend der Lineage-Reihenfolge. Verifiziere für jede Welle: korrektes Schema im Ziel, vollständige Daten (Datensatzanzahl), bestandene Qualitätsregeln, konfigurierte Zugriffsrichtlinien und wiederverbundene nachgelagerte Pipelines. Nutze den Katalog als Wahrheitsquelle für den Status jedes Assets.
Phase 4 (Woche 9–10): Validierung und Dekommissionierung. Führe Qualitätsregeln parallel (On-Premise vs. Cloud) aus, um Konsistenz zu verifizieren. Bestätige mit den Konsumenten, dass Dashboards und Berichte korrekt funktionieren. Trenne die On-Premise-Quellen erst, wenn die Validierung abgeschlossen ist. Dokumentiere die endgültige Architektur im Katalog.
Post-Migration: Monitoring und kontinuierliche Governance
Die Migration endet nicht, wenn die Daten in der Cloud ankommen. Der Post-Migrations-Zeitraum (erste 3–6 Monate) ist kritisch, um Probleme zu erkennen, die bei der ersten Validierung nicht aufgetreten sind: langsamere Abfragen als erwartet, Compute-Kosten, die Prognosen überschreiten, intermittierend fehlschlagende Qualitätsregeln und neue Daten, die ohne Governance erstellt werden.
Konfiguriere aktives Monitoring für die ersten Monate: Datenqualitäts-Alarme für migrierte Tabellen, Monitoring von Storage- und Compute-Kosten nach Domäne, automatische Erkennung neuer Tabellen oder Spalten ohne Dokumentation und Verfolgung der tatsächlichen Nutzung migrierter Assets (um Tabellen zu identifizieren, die migriert wurden, aber niemand konsumiert).
Etabliere den Governance-Prozess für die neue Umgebung vom ersten Tag an. Jede neue Tabelle muss einen Eigentümer, eine Beschreibung und eine Sensibilitätsklassifizierung haben, bevor sie in Produktion geht. Qualitätsregeln müssen als Teil der Pipeline konfiguriert werden, nicht als nachträglicher Zusatz. Der Datenkatalog sollte die erste Anlaufstelle für jeden sein, der Daten in der neuen Cloud-Umgebung finden, verstehen oder nutzen möchte.
Daten mit Governance in die Cloud zu migrieren ist kein Luxus: Es ist die effizienteste Art, es zu tun. Das Pre-Migrations-Inventar reduziert den Umfang (und die Kosten), indem es veraltete Assets eliminiert. Das Abhängigkeits-Mapping verhindert Vorfälle durch Definition der korrekten Reihenfolge. Die Sensibilitätsklassifizierung gewährleistet Compliance vom ersten Tag an. Und das Post-Migrations-Monitoring erkennt Probleme, bevor sie das Unternehmen beeinflussen.
Organisationen, die Governance in ihren Migrationsplan integrieren, berichten von 30–40 % weniger Post-Migrations-Vorfällen, 20–30 % Kostenreduzierung beim Storage (durch Nicht-Migrieren veralteter Daten) und einer erheblich kürzeren Time-to-Value, weil Teams Daten vom ersten Tag in der neuen Umgebung finden und nutzen können.