Datenmigration beim Umstieg auf neue Software: warum wir die Datensätze dreimal zählen

Wenn eine Organisation auf ein neues System umsteigt, spricht sie vor allem über dessen Funktionen. Bildschirme, Berichte, mobile App. Wie die Daten aus dem Altsystem übernommen werden, kommt dagegen meist ganz zum Schluss und wird mit „Wir machen einen Import“ abgehakt.

Genau dort geraten Projekte ins Stocken. Der Code läuft, die Bildschirme sind fertig, aber ein Teil der Kundendatensätze kommt unvollständig an. Und niemand weiß, wie viele fehlen und warum.

In diesem Beitrag beschreibe ich, was wir vor, während und nach der Migration prüfen.

Zuerst die Bestandsaufnahme

Die Migration beginnt bei uns nicht mit der ersten Codezeile, sondern mit einer Liste. Welche Tabellen gibt es im Altsystem, wie viele Datensätze enthält jede, was bedeutet welches Feld, welches wird nicht mehr genutzt.

Die häufigste Überraschung auf dieser Liste: Dieselbe Information wird an zwei Stellen gespeichert. Die Adresse des Kunden steht sowohl in der Kundentabelle als auch in der Rechnungstabelle, und beide stimmen nicht überein. Welche als richtig gilt, ist keine technische Entscheidung, sondern eine Entscheidung der Organisation. Diese Frage muss vor der Migration gestellt werden.

Die zweite Überraschung: Das Altsystem ist eine Excel-Datei. In Excel ist jedes Feld ohne feste Regel ein Feld, in das eines Tages jemand „vorübergehend“ etwas anderes geschrieben hat. Da tauchen Zeilen auf, in deren Datumsspalte „keins“ steht, und Zellen mit zwei Nummern in der Telefonspalte.

Feldzuordnung

Zwei Systeme speichern Daten nicht auf dieselbe Weise. Das Altsystem hat vielleicht ein einziges Feld „Vor- und Nachname“, das neue zwei getrennte Felder. Die Stadt ist im Altsystem vielleicht Freitext, im neuen wird sie aus einer Liste ausgewählt.

Für jedes Feld schreiben wir eine Zuordnungsregel: altes Feld, neues Feld und die Umwandlung dazwischen. Datensätze, die nicht zur Regel passen, werden nicht stillschweigend korrigiert. Sie landen auf einer separaten Liste. Diese Liste gehen wir gemeinsam mit der Organisation Eintrag für Eintrag durch.

Stillschweigende Korrektur wirkt verlockend, ist aber das Schlimmste, was man bei einer Migration tun kann. Ein fehlerhafter Datensatz war im Altsystem fehlerhaft. Wird er bei der Migration auf Basis einer Vermutung korrigiert, entsteht im neuen System ein Datensatz, der richtig aussieht, aber falsch ist. Das bemerkt danach niemand mehr.

Dreimal zählen

Um nach der Migration „abgeschlossen“ sagen zu können, zählen wir die Datensätze an drei Punkten.

Erstens die Quelle. Die Zahl der Datensätze im Altsystem, die übernommen werden müssen, Tabelle für Tabelle.

Zweitens die Übertragung. Die Zahl der Datensätze, die das Migrationsskript gelesen, umgewandelt und auf die separate Liste aussortiert hat.

Drittens das Ziel. Die Zahl der Datensätze, die im neuen System tatsächlich angelegt wurden.

Die Quelle muss der Summe aus übertragenen und aussortierten Datensätzen entsprechen. Die übertragenen Datensätze müssen dem Ziel entsprechen. Gehen diese beiden Gleichungen nicht auf, ist die Migration nicht abgeschlossen, so klein die Abweichung auch sein mag. Eine Abweichung von einigen hundert Datensätzen bedeutet, dass die Historie von einigen hundert Kunden verloren ist.

Dass die Zahlen stimmen, reicht allein nicht aus. Die Zahlen können stimmen und der Inhalt trotzdem beschädigt sein. Deshalb öffnen wir zufällig ausgewählte Datensätze in beiden Systemen nebeneinander und vergleichen sie Feld für Feld. Für kritische Felder wie Beträge und Datumsangaben berechnen wir außerdem Summen und Kennwerte auf beiden Seiten gesondert.

Testmigration und Rückfallplan

Die echte Migration führen wir nicht zum ersten Mal am echten Stichtag durch. Vorher machen wir mit einer Kopie der Daten mindestens zwei Testmigrationen. Bei jedem Test messen wir die Dauer, prüfen die aussortierten Datensätze und korrigieren die Zuordnungsregeln.

Vor der echten Migration wird ein Rückfallplan schriftlich festgehalten. Was geschieht, wenn die Migration abbricht oder die Zahlen nicht stimmen? Bis zu welchem Punkt kann man zum Altsystem zurückkehren? Wer trifft diese Entscheidung? Werden diese Fragen erst am Tag der Migration gestellt, fallen die Antworten hastig aus.

Für kurze Zeit beide Systeme gemeinsam

Wo möglich, bleibt das Altsystem nach dem Start des neuen Systems für kurze Zeit schreibgeschützt erreichbar. Wirkt ein Datensatz unvollständig oder falsch, kann man im Altsystem nachsehen und vergleichen.

Das Ende dieser Phase wird von Anfang an festgelegt. Sonst laufen beide Systeme monatelang nebeneinander, und die Diskussion, welches das richtige ist, beginnt von vorn.

Nicht übernehmen ist auch eine Entscheidung

Nicht jeder alte Datensatz muss in das neue System übernommen werden. Wer Daten mit abgelaufener Aufbewahrungsfrist in das neue System überträgt, bewahrt sie unnötig weiter auf. Bei personenbezogenen Daten kann daraus zusätzlich ein Pflichtverstoß werden.

Die Migration ist ein guter Zeitpunkt für dieses Aussortieren. Wir ermitteln die Datensätze mit abgelaufener Aufbewahrungsfrist, nehmen sie mit Zustimmung der Organisation von der Migration aus und dokumentieren die Löschung. So startet das neue System sauber.

Kurz gesagt

Eine Datenmigration ist kein Import, sondern ein kleines Projekt. Eine Migration ohne Bestandsaufnahme, Feldzuordnung, Zählung in drei Stufen, Testmigration und Rückfallplan kostet das neue System schon am ersten Tag Vertrauen.