Datenmigration: Bestände prüfbar in ein neues System überführen

Eine Datenmigration überführt Bestände aus einem Altsystem in eine neue Anwendung: Stammdaten, Belege, Historie. Übertragen wird dabei nicht eins zu eins, denn Felder, Schlüssel und Regeln beider Systeme stimmen nie vollständig überein. Der Aufwand liegt selten im Schreiben des Importers, sondern im Prüfen des Ergebnisses.

Datenmigration: Definition und Abgrenzung

Der Begriff bezeichnet den einmaligen, vollständigen Umzug eines Datenbestands mit anschließender Abschaltung der Quelle. Davon zu trennen ist die dauerhafte Kopplung zweier Systeme, bei der beide Seiten bestehen bleiben und laufend Daten austauschen; die Grundlagen dazu stehen im Artikel Schnittstelle (EDV). Und wieder etwas anderes ist die Archivierung, bei der ein Bestand nur noch lesbar erhalten bleibt.

Die Unterscheidung ist keine Wortklauberei. Sie legt fest, ob ein Rückweg existiert, wie lange zwei Systeme nebeneinander laufen und wer in dieser Zeit welche Daten pflegen darf. Wird eine in die Jahre gekommene Anwendung abgelöst, gehört der Umzug zum größeren Vorhaben der Legacy-Modernisierung.

Bestandsaufnahme, Feldabbildung und Schlüssel

Vor jeder Abbildung steht die Frage, was überhaupt vorhanden ist. Ein Profiling beantwortet sie mit Zahlen statt mit Annahmen: Wie viele Datensätze führt jede Tabelle, wie oft ist ein Feld leer, welche Werte kommen tatsächlich vor, welcher Zeichensatz liegt zugrunde, wie viele Verweise zeigen ins Leere.

Typische Funde sind Felder, die zweckentfremdet wurden — eine Bemerkungsspalte, in der ein Sachbearbeiter seit Jahren Liefertermine notiert —, Datensätze ohne gültige Zuordnung und mehrfach angelegte Partner. Jeder Fund führt zu einer Entscheidung: übernehmen, bereinigen, zurücklassen. Was hier nicht gezählt wurde, wird später geschätzt, und geschätzte Bestände lassen sich nicht abnehmen.

Das Kernstück ist eine Tabelle, die jedem Feld der Quelle ein Feld des Ziels zuordnet und dazu die Umformung nennt. Umzurechnen sind meist Datums- und Zahlenformate, Währungs- und Steuerangaben, Einheiten, Zeichensätze sowie Kennzeichen, die in der Quelle als freier Text und im Ziel als feste Auswahl geführt werden.

Am Schlüssel entscheidet sich, ob das Ergebnis prüfbar bleibt. Bewährt hat sich, die natürliche Kennung der Quelle — Belegnummer, Kundennummer — im Ziel als Referenzfeld mitzuführen. Danach lässt sich jeder Datensatz beiden Seiten zuordnen, ein Lauf lässt sich wiederholen, ohne dass ein zweiter Eintrag entsteht, und eine Abweichung lässt sich bis zur Zeile zurückverfolgen. Ebenso gehört festgelegt, was mit Sätzen geschieht, die sich nicht abbilden lassen: Sie kommen auf eine Klärliste und nicht in eine Ausnahmeregel im Code.

Probeläufe und ein prüfbares Abnahmekriterium

Ein Umzug wird nicht einmal ausgeführt, sondern mehrfach geprobt — auf einer Kopie, mit dem echten Bestand, mit demselben Programm, das später auch den scharfen Lauf macht. Jeder Probelauf endet mit einer Gegenüberstellung auf drei Ebenen: Zählungen je Objektart, Summen je Zeitraum und Partner sowie eine Stichprobe, die jemand fachlich Zuständiges von Hand ansieht.

Daraus wird das Abnahmekriterium, und es wird vor dem Start formuliert. Brauchbar ist nicht „die Daten sind übernommen“, sondern: jede Rechnung liegt genau einmal vor, die Monatssummen beider Seiten sind identisch, jede offene Position trägt denselben Saldo, und für jede verbliebene Abweichung existiert ein Eintrag in der Klärliste. Wie eine solche Formulierung vertraglich wirkt, behandelt der Artikel Abnahme.

Umstellungspunkt, Rückweg und Historie

Für den Umstellungspunkt gibt es drei Muster: die Umstellung an einem Stichtag, der Parallelbetrieb beider Anwendungen über einen begrenzten Zeitraum und die stufenweise Übernahme nach Mandant, Standort oder Objektart. Für alle drei gilt dasselbe Handwerk: eine Schreibsperre in der Quelle, ein Nachlauf für die Bewegungen seit dem letzten Probelauf und ein Prüfergebnis, bevor die ersten Anwender auf das neue System gelassen werden.

Der Rückweg gehört zum Entwurf und nicht zur Improvisation. Vor dem Start steht fest, bis zu welchem Zeitpunkt und anhand welcher Beobachtung zurückgegangen wird und wer diese Entscheidung trifft. Für die Historie gilt eine eigene Antwort: Nicht jeder Bestand muss in die neue Anwendung, ein lesbarer Archivzugang kann genügen — was steuerlich aufzubewahren ist, klärt der Auftraggeber mit seiner Beratung und nicht der Importer.

Wie wir eine Datenmigration im Projekt schneiden

Wir behandeln den Umzug als eigenen Liefergegenstand mit eigenen Kriterien und nicht als Anhängsel der Entwicklung: erst Profiling und Abbildungstabelle, dann ein wiederholbarer Lauf, dann Proben, deren Ergebnis der Auftraggeber selbst nachzählen kann. Das Programm, das die Übernahme ausführt, bleibt danach bestehen und wird weiter getestet, weil es in fast jedem Projekt ein zweites Mal gebraucht wird. Den Umstellungspunkt legen wir mit dem Fachbereich fest und nicht mit dem Kalender der Entwicklung, weil im Zweifel dort jemand nachzählen muss. Welche Arbeiten um einen solchen Umzug herum liegen, steht auf der Seite Integrationen.