Ein Datenmigrationsplan zwischen Systemen besteht nicht darin, Tabellen zu exportieren, Spalten anzupassen und Datensätze zu importieren. Der Wechsel betrifft die Bedeutung der Informationen, ihre Beziehungen, die Berechtigungen zu ihrer Nutzung und die Prozesse, die von ihnen abhängen. Ein Import kann ohne technische Fehler abgeschlossen werden und dennoch Aufträge ohne Positionen, Benutzer mit unzulässigem Zugriff, inkonsistente Beträge oder durch Status blockierte Abläufe hinterlassen, die das neue System anders interpretiert.
Die Migration muss als überprüfbarer betrieblicher Übergang behandelt werden. Das Ziel besteht nicht darin, dass die Daten im Zielsystem „vorhanden“ sind, sondern dass Personen und Systeme mit vollständigen, konsistenten, nachvollziehbaren und sicheren Informationen weiterarbeiten können. Dafür müssen der Umfang definiert, mit kontrollierten Daten erprobt, Ergebnisse abgeglichen, der Parallelbetrieb der Plattformen begrenzt und ein Rollback bereitgestellt werden, das den Betrieb und die während des Wechsels erzeugten Daten schützt.
Warum scheinbar korrekte Migrationen scheitern
Gesamtanzahlen sind meist die erste Kontrolle: Wenn im Quellsystem 10.000 Kunden und im Zielsystem 10.000 Kunden vorhanden sind, erscheint das Ergebnis zufriedenstellend. Diese Kontrolle belegt jedoch nicht, dass jeder Kunde die passenden Felder hat, seine Kontakte verknüpft sind, seine Berechtigungen korrekt sind oder seine historischen Vorgänge eingesehen werden können.
Die häufigsten Fehler entstehen durch semantische und operative Unterschiede:
- Ein Freitextfeld im Quellsystem wird im Zielsystem zu einer geschlossenen Liste, und einige Werte haben keine Entsprechung.
- Ein und derselbe Status steht je nach System für unterschiedliche Phasen; beispielsweise kann geschlossen „abgeschlossen“, „storniert“ oder „archiviert“ bedeuten.
- Beziehungen gehen verloren, weil neue Kennungen erzeugt werden, ohne eine verlässliche Zuordnung beizubehalten.
- Anhänge werden nicht übertragen, dupliziert oder verlieren Zugriffsberechtigungen.
- Die Geschäftsregeln des Zielsystems lehnen gültige historische Daten ab, etwa unvollständige Datumsangaben oder deaktivierte Datensätze.
- Benutzer validieren Hauptansichten, jedoch nicht die tatsächlichen Abläufe zum Erstellen, Ändern, Genehmigen, Abrechnen oder Bearbeiten.
Die Qualität einer Migration wird an der Kontinuität kritischer Prozesse gemessen, nicht allein am Erfolg einer Importaufgabe.
Umfang und Inventar vor der Transformation definieren
Das erste Ergebnisdokument muss einen expliziten Umfang enthalten. Entscheiden Sie für jede Entität, ob die gesamte Historie, nur ein Zeitraum, die aktiven Datensätze oder eine Kombination migriert wird. Berücksichtigen Sie Haupt- und abhängige Entitäten: Kunden, Produkte, Aufträge, Vorgänge, Benutzer, Dokumente, Kataloge, Konfigurationen und Auditprotokolle, sofern sie für den Betrieb oder zur Erfüllung interner Verpflichtungen erforderlich sind.
Es muss auch festgelegt werden, was nicht migriert wird. Es kann sinnvoller sein, sehr alte Ereignisse zu archivieren, bereinigte Duplikate auszuschließen, Anhänge in einem für Abfragen zugänglichen Repository aufzubewahren oder eine frühere Anwendung für einen begrenzten Zeitraum im schreibgeschützten Modus zugänglich zu lassen. Informationen auszuschließen bedeutet nicht, sie zu verlieren: Legen Sie fest, wo sie aufbewahrt werden, wer sie einsehen darf und wie lange.
Erstellen Sie für jeden Datenbestand ein Inventar von Quelle und Ziel. Es sollte mindestens Folgendes enthalten:
- Technischer Name und Bedeutung jedes Feldes.
- Format, Pflichtangabe, zulässige Werte und Validierungsregeln.
- Geschäftliche Kennung und technische Kennung.
- Beziehungen, Kardinalität und erforderliche Ladereihenfolge.
- Status des Datenelements: aktiv, historisch, storniert, gesperrt oder ausstehend.
- Fachlich Verantwortliche, die Regeln festlegen und Ausnahmen genehmigen.
- Vorgesehene Transformation, einschließlich Standardwerten und Normalisierungen.
Eine Zuordnungsmatrix macht diese Entscheidungen zu einem überprüfbaren Artefakt. Beispielsweise kann ein Status pendiente_revision in en_validacion überführt werden; gibt es keine Entsprechung, muss festgelegt werden, ob ein neuer Status erstellt, der Fall einer manuellen Warteschlange zugewiesen oder er mit Begründung ausgeschlossen wird. Es ist nicht ratsam, Entscheidungen dieser Art ohne Validierung durch die verantwortliche Person des Prozesses innerhalb des Migrationsskripts zu treffen.
Nachvollziehbarkeit, Beziehungen und Ausnahmen bewahren
Bewahren Sie nach Möglichkeit die stabilen Kennungen, die von anderen Prozessen, Berichten oder Integrationen verwendet werden. Wenn das Zielsystem neue Schlüssel verlangt, erstellen Sie eine Zuordnungstabelle zwischen der Kennung im Quell- und im Zielsystem. Diese Tabelle ist unerlässlich, um Beziehungen wiederherzustellen, Vorfälle zu untersuchen, vorübergehend zu synchronisieren und Entscheidungen rückgängig zu machen.
Die Nachvollziehbarkeit muss ein Ausführungsprotokoll mit Version des Extrakts, angewendeten Regeln, Datum, verantwortlicher Person sowie Anzahl der gelesenen, akzeptierten, abgelehnten und transformierten Datensätze umfassen. Ablehnungen sind kein technisches Detail: Klassifizieren Sie sie nach Ursache, Auswirkung und Behandlung. Eine fehlerhaft formatierte E-Mail-Adresse kann eine Korrektur oder einen Ausschluss erfordern; eine Rechnung ohne zugeordneten Kunden kann den Fortschritt verhindern, wenn sie einen kritischen Finanzprozess betrifft.
Definieren Sie außerdem einen Mechanismus zur Vermeidung von Duplikaten bei einer wiederholten Ladung. Eine idempotente Operation erkennt, ob ein Datensatz bereits verarbeitet wurde, und aktualisiert oder ignoriert ihn gemäß einer bekannten Regel, anstatt eine zweite Kopie zu erstellen. Dies ist besonders wichtig bei aufeinanderfolgenden Tests und bei einer möglichen Wiederaufnahme nach einem Fehler.
Mit repräsentativen Testmigrationen erproben
Führen Sie vor der Produktion Testmigrationen auf einer kontrollierten Kopie aus. Vermeiden Sie die Verwendung personenbezogener Daten in Umgebungen ohne angemessene Kontrollen; wenden Sie gegebenenfalls Anonymisierung oder Pseudonymisierung an und beschränken Sie den Zugriff. Der Test muss ein ausreichendes Volumen und genügend Vielfalt aufweisen, um Probleme aufzudecken: normale, historische, stornierte, unvollständige Datensätze, bekannte Duplikate, komplexe Beziehungen, Anhänge und Fälle mit besonderen Berechtigungen.
Ein guter Test folgt einer wiederholbaren Abfolge:
- Einen identifizierbaren Datenstand aus dem Quellsystem extrahieren.
- Die dokumentierten Transformationen anwenden.
- Unter Beachtung der Abhängigkeiten zwischen Entitäten laden.
- Automatische Integritätsprüfungen ausführen.
- Funktionale Szenarien mit verantwortlichen Benutzern validieren.
- Fehler erfassen, Regeln anpassen und wiederholen, bis die Abnahmekriterien erfüllt sind.
Kontrollieren Sie weit mehr als nur die Anzahl der Zeilen. Vergleichen Sie die Vollständigkeit von Pflichtfeldern, die Eindeutigkeit von Schlüsseln, Eltern-Kind-Beziehungen, Betragssummen, Datumsangaben, Status, Berechtigungen und Anhänge. Stimmen Sie bei Finanzdaten Gesamtsummen nach Zeiträumen und Kategorien ab. Wählen Sie bei Betriebsdaten Stichproben nach reproduzierbaren Kriterien aus und durchlaufen Sie die tatsächlichen Abläufe: einen Kunden finden, eine zulässige Angabe ändern, einen Vorgang erstellen, ihn genehmigen und in einem Bericht wiederfinden.
Die funktionale Validierung muss eine konkrete Frage beantworten: Kann das Team morgen seine kritischen Aufgaben ausführen, ohne das vorherige System als Quelle für Korrekturen zu verwenden?
Temporärer Parallelbetrieb ohne zwei Quellen der Wahrheit
Der Parallelbetrieb reduziert Risiken, kann jedoch das gefährlichste Problem schaffen: zwei bearbeitbare Systeme mit voneinander abweichenden Daten. Definieren Sie vor dem Wechsel für jede Entität und jeden Prozess eine Quelle der Wahrheit. Während des Übergangs besteht eine übliche Option darin, das vorherige System im Abfragemodus zu belassen und Neuanlagen sowie Änderungen im neuen System zu bündeln. Müssen beide Systeme Änderungen entgegennehmen, legen Sie fest, welche Felder jeweils bearbeitet werden dürfen, wie und wie häufig sie synchronisiert werden und wer Konflikte löst.
Eine bidirektionale Synchronisierung ohne klare Regeln vervielfacht in der Regel Duplikate, Überschreibungen und Unklarheiten. Bevorzugen Sie ein kurzes Parallelbetriebsfenster mit expliziten Grenzen und einem Abschalttermin. Wenn das vorherige System weiterhin Informationen erzeugen muss, identifizieren Sie die Unterschiede seit dem letzten Datenstand und testen Sie den Mechanismus für inkrementelle Ladungen, bevor Sie sich darauf verlassen.
Den Wechsel und einen wirklich tragfähigen Rollback planen
Der Umstellungsplan muss eine selektive Sperrung festlegen: Welche Vorgänge werden angehalten, wann, wer kommuniziert dies und welche vorübergehende Alternative besteht. Nicht alle Prozesse benötigen dasselbe Zeitfenster. Die Bearbeitung von Stammdaten kann gesperrt werden, während Abfragen oder nicht betroffene Aktivitäten weiterhin möglich sind.
Legen Sie Verantwortliche für die technische Durchführung, die fachliche Freigabe, die Kommunikation, die Bearbeitung von Vorfällen und die Autorisierung zum Fortfahren oder Anhalten fest. Die Fortschrittskriterien müssen beobachtbar sein: abgeschlossene Ladungen, genehmigte Abstimmungen, bestandene kritische Tests, überprüfte Zugriffe und keine blockierenden Vorfälle.
Ein Rollback bedeutet nicht immer, das Zielsystem zu löschen. Definieren Sie, was rückgängig gemacht wird, welche nach dem Wechsel neu erzeugten Daten erhalten bleiben müssen und wie sie bei Bedarf wieder in das vorherige System eingebracht würden. Bewahren Sie einen Wiederherstellungspunkt vor dem Wechsel, die Lade-Dateien und die Zuordnungstabellen auf und testen Sie die Rollback-Entscheidung in einem Testlauf. Es müssen konkrete Schwellenwerte für seine Aktivierung bestehen, etwa der Verlust von Beziehungen bei kritischen Entitäten, die Unmöglichkeit, einen wesentlichen Ablauf auszuführen, oder nicht erklärte Abweichungen bei sensiblen Daten.
Betrieb nach der Umstellung und Checkliste
Führen Sie nach dem Wechsel während der ersten Betriebszyklen einen intensiven Abgleich durch. Zentralisieren Sie Vorfälle in einer Warteschlange mit Priorität, Auswirkung, verantwortlicher Person und Lösungsfrist. Beobachten Sie Integrationsfehler, fehlgeschlagene Jobs, verweigerte Zugriffe, Antwortzeiten und anomale Abweichungen bei Volumina. Das vorherige System darf erst außer Betrieb genommen werden, wenn die Abfragefristen, Aufbewahrungspflichten und vereinbarten Abschlusskriterien erfüllt sind.
Prüfen Sie vor, während und nach der Produktion:
- Umfang, Ausschlüsse und fachlich Verantwortliche sind genehmigt.
- Eine Datenzuordnungsmatrix und eine Tabelle für Quell-Ziel-Schlüssel liegen vor.
- Transformationsregeln, Ausnahmen und Ablehnungen sind auditierbar.
- Die Tests umfassen repräsentative Fälle und vollständige kritische Abläufe.
- Der Abgleich überprüft Inhalt, Beziehungen, Berechtigungen und Geschäftsergebnisse.
- Der Parallelbetrieb weist jedem Datenelement eine einzige Quelle der Wahrheit zu.
- Der Wechsel verfügt über Zeitfenster, Kommunikationsmaßnahmen, Verantwortliche und Fortschrittskriterien.
- Der Rollback schützt die nach der Umstellung erzeugten Daten und verfügt über eine festgelegte Autorisierung.
- Für die Überwachung und die sichere Außerbetriebnahme des vorherigen Systems sind Verantwortliche und ein Termin festgelegt.
Eine ausgereifte Migration verlangt kein blindes Vertrauen in einen Import: Sie liefert Nachweise, um zu entscheiden, ob fortgefahren, korrigiert oder ein Rollback durchgeführt wird, ohne den Betrieb zu gefährden.