Wie planen und prüfen Sie eine Datenmigration?

Was müssen Sie über Ihre Daten wissen, bevor der Umzug beginnt?

Jeder Umzug beginnt mit einer nüchternen Bestandsaufnahme: Welche Tabellen existieren, wie viele Datensätze enthalten sie, wer schreibt hinein und wer liest heraus. Diese Liste erstellt niemand aus dem Gedächtnis — sie entsteht am laufenden System.

Der zweite Schritt heißt Datenprofilierung. Dabei sehen Sie sich pro Feld an, welche Werte tatsächlich vorkommen: Wie viele Einträge sind leer, welche Formate mischen sich, wie lang ist der längste Wert, wie viele verschiedene Ausprägungen gibt es? Ein Feld „Land“ mit siebenundvierzig Schreibweisen für Deutschland ist keine Seltenheit.

Bei einem technischen Großhändler fanden sich in einem Freitextfeld für Lieferbedingungen elf Varianten derselben Klausel, drei davon mit Tippfehlern. Solche Funde entscheiden, ob ein Feld direkt übernommen oder über eine Übersetzungstabelle vereinheitlicht wird.

• Zählen Sie Datensätze pro Tabelle und halten Sie den Stand mit Zeitstempel fest.
• Erfassen Sie Füllgrad, Wertebereich und Formatvarianten je Feld.
• Markieren Sie Felder ohne erkennbare Nutzung — sie sind Kandidaten für den Verzicht.
• Dokumentieren Sie, welche Systeme lesend auf den Bestand zugreifen; sie müssen später ebenfalls umgestellt werden.

Ebenso wichtig ist die Frage nach den Nebenschauplätzen. Neben der Hauptdatenbank existieren fast immer Tabellenblätter auf Netzlaufwerken, ein Postfach mit Freigaben und eine kleine Nebenanwendung, die eine Abteilung sich selbst gebaut hat. Diese Quellen tauchen in keinem Systemplan auf und fallen erst beim ersten produktiven Arbeitstag im neuen System auf.

Wie entsteht eine Mapping-Tabelle, mit der alle arbeiten können?

Die Mapping-Tabelle ist das zentrale Arbeitsdokument. Sie listet jedes Quellfeld, sein Ziel im neuen Datenmodell, die Umwandlungsregel und die verantwortliche Person aus dem Fachbereich. Eine Tabellenkalkulation genügt vollkommen, solange es nur eine einzige gültige Fassung davon gibt.

Vier Zielzustände decken fast alle Fälle ab: Ein Feld wird eins zu eins übernommen, es wird umgerechnet oder umgeschlüsselt, es wird aus mehreren Quellfeldern zusammengesetzt, oder es entfällt bewusst. Der vierte Fall braucht immer eine Begründung und eine Freigabe — sonst diskutieren Sie nach dem Umzug über verschwundene Angaben.

Bauen Sie das Zieldatenmodell nicht als Kopie des alten. Ein Umzug ist die seltene Gelegenheit, historisch gewachsene Sammelfelder aufzuteilen und Schlüssel sauber zu definieren. Wer die alte Struktur unverändert übernimmt, übernimmt auch sämtliche Kompromisse, die zu ihr geführt haben.

Zwei Angaben pro Zeile werden gern vergessen und sparen später Stunden: der Umgang mit Leerwerten und der Umgang mit unbekannten Schlüsseln. Was geschieht, wenn ein Pflichtfeld im Ziel leer ankommt — Abbruch, Ersatzwert, Nachbearbeitungsliste? Und was, wenn eine Bestellung auf einen Lieferanten verweist, den es im Stammdatenbestand nicht mehr gibt?

Jedes Feld, das niemand im Fachbereich erklären kann, ist ein Kandidat für den Papierkorb — nicht für das neue System.

Bereinigen Sie vor oder nach dem Umzug?

Vorher. Ein Umzug verstärkt jeden Mangel im Bestand, weil das Zielsystem in der Regel strenger prüft als das alte. Was dort jahrelang als leeres Pflichtfeld durchging, blockiert im neuen System den Import — und zwar mitten im Migrationsfenster, wenn niemand Zeit für Grundsatzfragen hat.

Die wiederkehrenden Baustellen sind überschaubar, aber zäh:

• Dubletten: derselbe Geschäftspartner mehrfach angelegt, oft mit unterschiedlichen Bankverbindungen.
• Pflichtfelder: im Ziel verbindlich, in der Quelle jahrelang optional geführt.
• Formate: Datumsangaben, Telefonnummern und Steuernummern in gemischten Schreibweisen.
• Zeichensätze: Umlaute und Sonderzeichen aus älteren Kodierungen, die als Fragezeichen oder Kästchen ankommen.
• Zeitzonen: Zeitstempel ohne Zonenangabe, die beim Umzug um eine oder zwei Stunden verrutschen.

Bereinigen sollte der Fachbereich, nicht der Dienstleister. Wer entscheidet, welche von zwei Kundenadressen gilt, muss den Kunden kennen. Planen Sie diese Arbeit als eigene Aufgabe mit Terminen ein, sonst geschieht sie in den letzten drei Tagen vor dem Umstellungswochenende — oder gar nicht.

Nehmen Sie die komplette Historie mit oder archivieren Sie sie?

Nicht alles muss in das neue System. Sinnvoll ist eine Dreiteilung: aktive Bestände wandern vollständig, abgeschlossene Vorgänge der letzten Jahre wandern in reduzierter Form, alles Ältere geht in ein rein lesendes Archiv.

Eine Steuerberatungskanzlei etwa braucht Mandantenstammdaten und offene Fälle im Tagesgeschäft, muss aber auch auf zehn Jahre zurückliegende Unterlagen zugreifen können. Ein schlankes Archiv mit Suchfunktion erfüllt das oft besser als der Versuch, jede historische Buchung in ein neues Datenmodell zu pressen.

Damit rücken Aufbewahrungsfristen und Löschkonzept ins Bild. Handels- und steuerrechtliche Fristen geben vor, was Sie aufbewahren müssen; der Grundsatz der Speicherbegrenzung aus der DSGVO fordert umgekehrt, personenbezogene Daten nicht länger vorzuhalten als nötig. Ein Umzug ist der praktischste Zeitpunkt, beides in Regeln zu gießen — die konkrete Ausgestaltung klären Sie mit Ihrem Datenschutzbeauftragten und gegebenenfalls rechtlichem Beistand, nicht mit dem Entwicklungsteam.

• Legen Sie je Datenart fest, wie lange sie im aktiven System bleibt.
• Bestimmen Sie, was archiviert und was beim Umzug bewusst nicht übernommen wird.
• Halten Sie fest, wer Archivbestände einsehen darf und wie der Zugriff protokolliert wird.

Wie viele Testläufe brauchen Sie und womit testen Sie?

Testen Sie mit einer Kopie des Produktivbestands, nicht mit einem handverlesenen Ausschnitt. Nur echte Bestände enthalten die Sonderfälle, an denen Importe scheitern: den Eintrag von 1998 ohne Kundennummer, den Namen mit Apostroph, den Betrag mit fünf Nachkommastellen.

Zwei vollständige Durchläufe sind das Minimum, drei bei größeren Beständen üblich. Der erste Lauf legt die Fehler offen, der zweite prüft die Korrekturen, der dritte ist die Generalprobe unter Zeitmessung. Notieren Sie die Laufzeit jedes Durchgangs — sie bestimmt, wie lang Ihr Migrationsfenster ausfallen muss.

Führen Sie zu jedem Lauf ein Fehlerprotokoll, das nicht nur zählt, sondern gruppiert. Fünfhundert abgewiesene Datensätze sehen dramatisch aus und gehen oft auf drei Ursachen zurück. Erst die Gruppierung zeigt, ob Sie ein Datenproblem, ein Regelproblem oder einen Programmierfehler vor sich haben — und wer es beheben muss.

Enthält der Bestand personenbezogene Angaben, gehört die Testumgebung ebenso geschützt wie die Produktion, oder die Inhalte werden vor dem Test ersetzt. Ein Testsystem mit echten Personaldaten und offenem Zugang ist ein Risiko, das sich mit wenig Aufwand vermeiden lässt.

Mit welchen Prüfungen belegen Sie, dass nichts verloren ging?

Der Nachweis läuft über drei Ebenen, die sich gegenseitig absichern: Mengen, Summen und Stichproben. Jede allein ist täuschbar, zusammen sind sie belastbar.

• Mengenabgleich: Datensatzzahlen je Tabelle in Quelle und Ziel, inklusive Erklärung für jede bewusste Abweichung.
• Summenabgleich: Kontrollsummen über betragsführende Felder, etwa offene Posten, Lagerwerte oder Jahresumsätze.
• Stichproben: dreißig bis fünfzig Datensätze, vom Fachbereich ausgewählt und Feld für Feld verglichen.
• Randfälle: der älteste Eintrag, der längste Text, der größte Betrag, der Datensatz mit den meisten Verknüpfungen.
• Beziehungsprüfung: keine Rechnung ohne Kunde, keine Position ohne Auftrag, keine verwaiste Verknüpfung.

Protokollieren Sie die Ergebnisse als Abnahmedokument mit Datum und Unterschrift. Das klingt bürokratisch, erspart aber die Diskussion, die drei Monate später zuverlässig kommt, wenn jemand eine Zahl vermisst.

Wie planen Sie Migrationsfenster und Rückabwicklung?

Das Migrationsfenster ist der Zeitraum, in dem die Quelle eingefroren und das Ziel noch nicht freigegeben ist. Seine Länge ergibt sich aus der gemessenen Laufzeit der Generalprobe plus Prüfzeit plus Puffer — nicht aus dem Wunschtermin der Projektleitung.

• Frieren Sie die Quelle nachweislich ein: Schreibrechte entziehen, nicht nur per Rundmail bitten.
• Legen Sie einen Zeitpunkt fest, zu dem über Freigabe oder Rückabwicklung entschieden wird.
• Halten Sie das Altsystem lesbar und unverändert, bis die Abnahme vollständig durch ist.
• Definieren Sie, welche Nacherfassung nötig wird, falls im Fenster doch gearbeitet wurde.

Planen Sie außerdem die ersten Tage nach der Freigabe mit. Wer im neuen System arbeitet, findet in der ersten Woche Auffälligkeiten, die keine Prüfung vorher zeigt: eine falsch zugeordnete Preisliste, eine vertauschte Anrede, ein Feld an ungewohnter Stelle. Eine benannte Anlaufstelle und ein einfaches Meldeformular verhindern, dass diese Beobachtungen in Flurgesprächen versickern.

Eine Rückabwicklung ist nur so gut wie ihr letzter Test. Spielen Sie sie mindestens einmal durch, bevor Sie sie brauchen — mit Stoppuhr, damit Sie wissen, ob der Rücksprung noch in das Wochenende passt.

Welchen Anteil am Projektbudget nimmt die Datenmigration ein?

Bei gewachsenen Beständen liegt der Migrationsanteil erfahrungsgemäß bei 10 bis 25 Prozent der Gesamtsumme. Bei einer individuellen Anwendung im Rahmen von 15.000 bis 250.000 € sind das je nach Größe wenige tausend bis mehrere zehntausend Euro — ein Posten, der ins Angebot gehört und nicht in eine Sammelzeile.

Nach oben treiben ihn viele Quellsysteme, fehlende Schlüssel zwischen den Beständen, Freitextfelder mit fachlicher Bedeutung und eine Historie, die vollständig mitwandern soll. Nach unten wirkt jede Vorarbeit, die Ihr Team selbst leistet: bereinigte Stammdaten, entschiedene Feldabbildungen, benannte Ansprechpartner je Datenbereich.

Ein Hinweis zur Angebotsprüfung: Eine Pauschale für „Datenübernahme“ ohne Mengengerüst ist meist entweder deutlich zu hoch kalkuliert oder eine spätere Nachtragsquelle. Belastbar wird die Zahl erst, wenn Tabellenanzahl, Datensatzmengen, Anzahl der Quellsysteme und der Umfang der Historie darin benannt sind.