Self-Made-Lösungen für Migrationen sind riskant. Setze auf Tools!

Stell dir den Horror vor: Gerade ist die Migration produktiv abgeschlossen, da taucht in den Daten ein stiller Fehler auf. Weil Kundenadressen in unterschiedlichen Logiken erfasst wurden, erhalten tausende Kunden fälschlicherweise Umzugsbriefe und -emails. Schlimmer noch: Der Fehler reproduziert sich in diesem Moment unwiderruflich in die Umsysteme. Der Schaden ist angerichtet.

Zugegeben, nicht jede von Hand gescriptete Migration muss in diesem Albtraum enden, aber das Risiko ist doch erheblich. Besonders, wenn die Daten komplexe fachliche Zusammenhänge abbilden, viele Sonderkonstellationen enthalten oder in grossen Mengen vorkommen. Im Finanz- und Versicherungssektor ist dies rasch der Fall. Ausserdem können Unterschiede in den Logiken und Zuordnungen zwischen Quell- und Zielsystem die Legacy-Ablösung erheblich erschweren.

Wir führen seit 37 Jahren Migrationen von hochkomplexen Daten durch und setzen nur ganz selten auf eigenentwickelte Scripts. Hier sind die Gründe weshalb:

Lösung trübt die Analyse

Ob selbstgeschriebene Python- oder SQL-Scripts oder Migrationstool: Jede Migration beginnt mit einer Datenanalyse. Darum können wir uns bei der Datenanalyse ganz auf den Inhalt konzentrieren. Wer die Scripts selbst schreibt, behält die Frage nach der Machbarkeit und dem Lösungsweg ständig im Hinterkopf. Erste Vorstellungen von Lösungswegen können einen Bias produzieren, bei dem Probleme relativiert oder nicht mehr als solche wahrgenommen werden. Ein Lösungsweg setzt sich unbewusst im Kopf fest, von dem das Team nur noch schwer abrückt.

Wer handgescriptet arbeitet, beginnt mit einem strukturlosen weissen Blatt. Die Mechanik einer toolgestützten Migration verlangt, dass wir uns systematisch mit den Dateninhalten, Abhängigkeiten, fachlichen Regeln und Zielstrukturen auseinandersetzen. So werden blinde Flecken in der Datenqualität aufgedeckt, die sonst gerne übersehen werden. Das führt zu Folgefehlern oder verhindert gar eine Datenmigration. Bei Eigenentwicklungen ist die Datenanalyse Teil des Codes. Wertelisten der Quell und Zielattribute müssen von Hand überall verteilt im Code gepflegt werden, was aufwändig und sperrig ist.

Im Fall von nag nxT leistet das Tool bei der Datenanalyse wertvolle Dienste: Es liefert Informationen, etwa zu Datenstrukturen, Dateninhalte, Relationsverhältnisse und fachliche Zusammenhänge. Handgescriptete Migrationen laufen Gefahr, die Daten nur selektiv und punktuell zu analysieren und nur auf bereits bekannte Probleme zu fokussieren.

Best Practice ist es, die Analysephase sauber von der Umsetzung zu trennen und rein fachlich anzugehen. Sie darf auf keinen Fall als Overhead wahrgenommen werden, sondern als fachliche Entscheidungsgrundlage. Datenqualitätsprobleme sollten nicht erst während der Umsetzung entdeckt werden.

Selbst nach einer anfänglichen Datenanalyse kann man während der Umsetzung auf weitere Probleme in den Daten stossen: Falsch belegte Felder, Sonderlogiken aus Altsystemen oder mehrdeutige Zustände. Dass Ausnahmen vorkommen, ist der Regelfall, keine Besonderheit.

Aus unserer Erfahrung müssen die Analyse der Daten, die Umsetzung der Transformationsregeln und die technische Ausführung der Migration strikt getrennt sein.

1. Analyse
   • Wie steht es um die Datenqualität?
   • Welche Ausprägungen, Muster, oder Ausreisser kommen vor?
2. Regeln / Modell
   • In welchen Zielstrukturen werden die Quelldaten gegossen?
   • Welche fachlichen Besonderheiten müssen auf dem Weg von der Quelle ins Ziel berücksichtigt werden?
3. Technische Ausführung
   • Wie werden Daten physisch bewegt?

Ein Migrationstool wie nag nxT hilft, diese Phasen sauber zu trennen. Taucht ein Sonderfall auf, wird die Analyse ergänzt, die Regel angepasst und die Umsetzung bleibt so unverändert.

Bei individuellen Migrationslösungen sind Datenzugriff, Transformationslogik und fachliche Regeln eng gekoppelt. Das ist besonders dann der Fall, wenn sich die Analyse – wie beschrieben – in die Programmierung verschoben hat. So müssen Sonderfälle mit komplexen Logikbäumen nachgebildet werden. Es können Seiteneffekte entstehen, die langwierige Korrekturarbeiten nach sich ziehen. Die Komplexität steigt mit jedem Sonderfall überproportional.

Nachvollziehbar ohne Code-Kenntnisse

Selbst wenn du Sonderfälle mit Scripts erfolgreich auffangen kannst, leidet die Transparenz darunter. Mit einem Tool bleiben alle Transformationsregeln, Mappingtabellen, Regeldefinitionen, Selektionskriterien und Validierungsregeln sichtbar. Denn alle Anpassungen werden dort explizit beschrieben und historisiert, damit die Nachvollziehbarkeit jederzeit gegeben ist.

Im Code sind Anpassungen hingegen nur mit Aufwand herauslesbar. Das erschwert die Zusammenarbeit mit Fachpersonen, die die Modifizierungen nicht nachvollziehen können. Ohne Übersetzungsleistung der Techniker in Form von diszipliniert nachgeführten Dokumentationen bleiben Anpassungen bei handgescripteten Migrationen undurchsichtig. Fachliche Reviews der Umsetzung werden automatisch zu Code-Reviews. Das führt zu einem Kontrollverlust, den es zu vermeiden gilt. Mit einem Tool sind die Regeln leicht auffindbar, Entscheidungen auch ohne Code-Kenntnisse nachvollziehbar und die Migration damit reproduzierbar.

Umgekehrt bedeutet die Nachvollziehbarkeit auch, dass Fachwissen von Personen unabhängig ist. Ein gutes Migrationstool wie nag nxT (mehr dazu erfährst du hier) produziert automatisch eine Dokumentation der vorgenommenen Änderungen. Das Projekt kann deshalb problemlos in andere Hände gegeben werden. Dazu kommt, dass für das Tool einerseits ein solides Handbuch existiert, ein KI-Chatbot, der Fragen schnell beantwortet und von uns als Hersteller supportet wird. Selbstgeschriebene Scripts hingegen sind stark von ihren Entwicklern abhängig. Wenn nebenher keine minutiöse Dokumentation mitgeschrieben wird, bleibt ein grosser Teil der Kenntnisse in den Köpfen des IT-Mitarbeitenden. Bei Problemen muss das IT-Team automatisch mit dem Code arbeiten, kann selbst kein Handbuch zurate ziehen oder auf externen Support zurückgreifen.

Wann du kein Migrationstool brauchst

Selbst gescriptete Migrationen sind nicht per se auszuschliessen. Tools wie nag nxT sind für in gewissen Fällen zu umfassend. Für kleinere Datenmengen mit nur wenigen Abhängigkeiten, Sonderfällen oder nur geringen Compliance-Ansprüchen produzieren Migrationstools mehr Aufwand als Nutzen. Bei solchen kleineren, einfacheren Projekten empfehlen wir tatsächlich auf selbst entwickelte Scripts zurückzugreifen. Analyse, Regeln und Umsetzung sollten trotzdem streng getrennt bleiben und das Projekt gut dokumentiert sein. Weitere Informationen zu Datenmigrationen findest du im Buch «Herausforderung Datenmigration», in dem wir Erkenntnisse aus 37 Jahren Migrationserfahrungen teilen.