10. Juli 2026 · Morten Babakhani
In Projektplänen steht Datenmigration als ein Arbeitspaket unter zwanzig. In der Realität entscheidet sie über den Termin — weil sie erst spät ernst genommen wird und dann alles gleichzeitig auffällt.
Fehler eins: zu spät mit echten Daten testen
Migrationen werden gern mit einem Auszug getestet, den jemand freundlich vorbereitet hat. Dieser Auszug enthält keine Altfälle, keine Sonderzeichen, keine Datensätze aus einer Fusion von 2009 und keine Personen mit drei parallelen Verträgen.
Diese Fälle sind es aber, die die Migration aufhalten. Und sie sind nicht die Ausnahme: In gewachsenen Konzernbeständen sind fünf bis zehn Prozent der Datensätze in irgendeiner Form besonders.
Nehmen Sie den ersten Probelauf mit dem vollständigen Bestand vor, so früh wie möglich, auch wenn das Zielsystem noch nicht fertig konfiguriert ist. Sie testen zuerst die Daten, nicht das System.
Fehler zwei: bereinigen und migrieren vermischen
Der Wunsch ist verständlich: Wenn man schon alles anfasst, könnte man es gleich aufräumen. Praktisch führt es dazu, dass niemand mehr weiß, ob eine Abweichung im Ziel ein Migrationsfehler oder eine gewollte Bereinigung war.
Trennen Sie beides. Bereinigen im Quellsystem, vor der Migration, mit einem eigenen Nachweis. Danach migrieren — und im Ziel muss stehen, was in der Quelle stand. Diese Regel macht die Abnahme prüfbar.
Fehler drei: keine Zählung als Nachweis
„Sieht gut aus” ist keine Abnahme. Was Sie brauchen, sind Zahlen, die vor und nach der Migration übereinstimmen müssen — und zwar vorher festgelegt.
Anzahl Personen je Status. Anzahl Verträge. Summe der Entgeltbestandteile je Art. Anzahl Dokumente je Dokumentart. Anzahl Abwesenheiten je Jahr. Bei jeder Abweichung muss es eine dokumentierte Erklärung geben — nicht ein Achselzucken.
Diese Zählungen kosten einen Tag Vorbereitung und ersparen die Diskussion, ob die Migration gelungen ist.
Was zusätzlich hilft
Ein Feldmapping, das jemand pflegt. Nicht als einmaliges Dokument, sondern als Arbeitsmittel mit Stand und Verantwortlichem. In jedem Projekt entstehen während der Tests Änderungen; wenn sie nicht im Mapping landen, sind sie beim nächsten Lauf verloren.
Ein Rückweg. Was passiert, wenn nach dem Produktivlauf ein systematischer Fehler auffällt? Wer diese Frage vorher beantwortet hat, geht ruhiger in das Wochenende der Umstellung.
Historie mit Maß. Die Versuchung ist groß, zwanzig Jahre Historie mitzunehmen. Klären Sie je Datenart, wofür die Historie gebraucht wird. Für Auskünfte genügt häufig ein Archiv mit Lesezugriff — das ist erheblich günstiger als eine vollständige Übernahme in das neue Datenmodell.
Der Probelauf, der sich bezahlt
Ein Probelauf ist erst dann einer, wenn er mit dem vollständigen Bestand läuft und ein Ergebnis erzeugt, das man prüfen kann. Der Ablauf, der sich bewährt hat: laden, zählen, Abweichungen klassifizieren, Fehlerliste priorisieren, korrigieren, wiederholen.
Entscheidend ist die Klassifizierung. Jede Abweichung bekommt eine von drei Einordnungen: Fehler im Werkzeug, Fehler in den Quelldaten, gewollte Abweichung. Die erste Gruppe korrigiert die IT, die zweite der Fachbereich im Quellsystem, die dritte wird dokumentiert und beim nächsten Lauf nicht wieder diskutiert.
Rechnen Sie mit drei Läufen. Zwei reichen, wenn der Bestand sauber ist — das ist er selten.