Daten aus Altsystemen migrieren, ohne den Betrieb zu stören

Warum Datenmigration das teuerste Stück am neuen System ist

Wenn ein KMU auf eine neue Software umzieht, dreht sich in den ersten Gesprächen fast alles um Funktionen. Welche Masken, welche Workflows, welche Schnittstellen. Die Daten kommen als Nebensatz vor: die übernehmen wir dann halt. Dieser Nebensatz ist regelmässig der Teil, der das Projekt sprengt.

Daten aus Altsystemen zu migrieren heisst: bestehende Datensätze aus einem alten System herauslösen, sie verständlich machen, in die Struktur des neuen Systems übersetzen und dort so einsetzen, dass die Arbeit am nächsten Morgen weiterläuft. Klingt nach Kopieren. Ist es nie. Die alte Datenbank hat über Jahre Eigenheiten angesammelt, die niemand mehr dokumentiert hat. Felder, die mal für das eine und mal für etwas ganz anderes benutzt wurden. Kundennummern, die doppelt vergeben sind. Ein Statusfeld mit elf Werten, von denen real nur drei vorkommen.

Die neue Software baust du einmal. Die Daten musst du verstehen, bevor du sie anfassen kannst, und dieses Verstehen ist die eigentliche Arbeit. Genau deshalb ist die Migration im Budget oft der Posten, der unterschätzt wird, und im Zeitplan der, der überzieht.

Was deine Daten so teuer macht

Die Kosten einer Migration hängen kaum an der Menge. Eine Million sauber strukturierter Zeilen ist billiger umzuziehen als zwanzigtausend, die von Hand gepflegt wurden. Ein paar Treiber bestimmen, ob du mit einem überschaubaren Aufwand davonkommst oder in einen monatelangen Klärungsprozess gerätst.

Datenqualität ist der grösste Hebel. Wo Mitarbeitende über Jahre in Freitextfelder geschrieben haben, wo Adressen mal mit, mal ohne Land erfasst sind, wo eine Firma unter drei Schreibweisen existiert, musst du Regeln finden, prüfen und anwenden. Jede dieser Regeln ist eine Entscheidung, und jede Entscheidung braucht jemanden aus dem Fachbereich, der sie verantwortet.

Strukturbruch ist der zweite. Das alte System hat Adresse und Person vielleicht in einem Datensatz vermischt. Das neue trennt sie sauber. Diese Übersetzung, das Mapping, ist nicht mechanisch, sondern eine inhaltliche Aufgabe. Wenn ein Feld im Altsystem drei Dinge gleichzeitig bedeutet, musst du es aufdröseln, bevor es ins neue passt.

Verflechtung ist der dritte. Daten hängen zusammen: ein Auftrag gehört zu einem Kunden, eine Rechnung zu einem Auftrag, eine Zahlung zu einer Rechnung. Reisst du einen Strang heraus, ohne die Verbindungen mitzuziehen, hast du am Ende Rechnungen ohne Kunde. Diese Beziehungen über Systemgrenzen hinweg sauber zu halten, ist anspruchsvoller als das Übertragen einzelner Tabellen.

Deshalb kostet die Migration oft mehr als das Programm. Software lässt sich planen, weil du sie selbst gestaltest. Daten musst du erst freilegen, und was du findest, kennst du vorher nicht. Wenn dein Kernsystem heute eine Excel-Landschaft ist, die niemand mehr überblickt, kennst du dieses Gefühl bereits.

Der Ablauf: bereinigen, abbilden, in Etappen umziehen, parallel laufen, prüfen

Eine Migration, die den Betrieb nicht stört, folgt einer Reihenfolge. Sie lässt sich nicht abkürzen, ohne dass die abgekürzten Schritte später als Störung zurückkommen.

Bereinigen, bevor du etwas bewegst

Der erste Schritt findet noch im alten System statt, oder in einer Kopie davon. Du verschaffst dir einen Überblick: Welche Tabellen gibt es, wie voll sind die Felder, wo stehen Dubletten, wo Leerstellen, wo Werte, die keiner Regel folgen. Profiling nennt man das. Das Ergebnis ist eine nüchterne Bestandsaufnahme statt einer Vermutung.

Dann räumst du auf. Manches lässt sich automatisch korrigieren: Datumsformate vereinheitlichen, Leerzeichen entfernen, Länderkürzel ergänzen. Anderes braucht eine fachliche Entscheidung: Sind diese beiden Kunden dieselbe Firma? Gehört dieser Auftrag noch ins neue System oder ist er Archiv? Je mehr du im Altsystem bereinigst, desto weniger Müll trägst du in das neue, das du gerade sauber aufbaust. Eine Migration ist die einmalige Chance, Altlasten loszuwerden, statt sie mitzunehmen.

Abbilden, also das Mapping festlegen

Jetzt legst du fest, welches Feld im alten System auf welches im neuen wandert, und nach welcher Regel. Das Mapping ist ein Dokument, an dem Technik und Fachbereich gemeinsam arbeiten. Hier fallen die Fälle auf, die vorher unsichtbar waren: ein Status im Altsystem, für den es im neuen keine Entsprechung gibt; ein Pflichtfeld im neuen, das im alten leer bleiben durfte. Jeder solche Fall ist eine Entscheidung, die getroffen werden muss, bevor die erste Zeile umzieht.

In Etappen umziehen statt alles auf einmal

Die Versuchung, an einem Wochenende alles umzulegen, ist gross. Der Big-Bang funktioniert, wenn die Datenmenge klein und sauber ist und das Risiko überschaubar bleibt. Bei gewachsenen Beständen ist die etappenweise Migration robuster. Du beginnst mit den Stammdaten, also Kunden, Artikel, Lieferanten. Erst wenn die sitzen, kommen die Bewegungsdaten: Aufträge, Rechnungen, Belege. So findest du Fehler im Kleinen, korrigierst die Mapping-Regel und wendest sie erneut an, statt am Montagmorgen vor einem System zu stehen, in dem nichts stimmt und niemand weiss, wo es gekippt ist.

Parallel laufen lassen, damit niemand stillsteht

Der Schritt, der über stört den Betrieb oder stört ihn nicht entscheidet, ist der Parallelbetrieb. Für eine begrenzte Zeit laufen altes und neues System nebeneinander. Die Migration läuft als wiederholbarer Vorgang, ein Skript, das du immer wieder anstossen kannst und das jedes Mal dasselbe Ergebnis liefert. Du spielst die Daten in eine Testumgebung des neuen Systems, prüfst, korrigierst, spielst neu ein. Erst wenn ein Durchlauf sauber durchläuft, planst du den Umstieg. Dann ist der eigentliche Wechsel kein Sprung ins Ungewisse, sondern die x-te Wiederholung eines Vorgangs, den du schon kennst.

Prüfen, mit Zahlen statt mit Gefühl

Nach jedem Durchlauf wird abgeglichen. Stimmt die Anzahl der Datensätze? Ergibt die Summe aller offenen Rechnungen im neuen System denselben Betrag wie im alten? Stichproben aus dem Fachbereich: Der Mitarbeiter, der Kunde Meier seit zehn Jahren betreut, schaut sich Meier im neuen System an und sagt, ob es passt. Diese Abnahme ist keine Formalität. Sie ist der Moment, in dem aus technisch übertragen ein fachlich korrekt wird, und nur die zweite Aussage zählt für den Betrieb.

Wann sich der Aufwand nicht lohnt

Nicht jede Migration ist die richtige Antwort. Es gibt Fälle, in denen du dir den ganzen Apparat sparst, und es ist deine Aufgabe, sie zu erkennen, bevor das Projekt läuft.

Wenn die Altdaten überwiegend Archiv sind, also Geschäftsvorfälle, die abgeschlossen sind und nur aus rechtlichen Gründen aufbewahrt werden müssen, brauchst du sie nicht im neuen System. Ein Schnitt ist oft die bessere Migration: Du startest das neue System mit sauberen Stammdaten und lässt das Alte als Nachschlage-Archiv weiterlaufen, schreibgeschützt. Wer eine alte Rechnung sucht, schaut dort nach. Das kostet einen Bruchteil und vermeidet, dass du Jahre an Altlasten in ein frisches System schleppst.

Manchmal ist die Datenqualität so schlecht, dass eine Bereinigung teurer würde als eine Neuerfassung der wirklich aktiven Datensätze. Wenn von zehntausend Kunden nur dreihundert noch Umsatz machen, migrierst du vielleicht nur diese dreihundert, und zwar von Hand und sauber. Und es gibt Fälle, in denen das alte System schlicht weiterläuft, weil es seinen Zweck erfüllt. Bevor du eine Migration startest, lohnt der nüchterne Blick darauf, ob das bestehende Standard-Tool nicht doch angepasst werden kann, statt alles neu aufzusetzen.

Der naheliegende Einwand lautet: Dann verlieren wir doch unsere Historie. Das stimmt nur, wenn man Migration mit Übertragung gleichsetzt. Die Historie bleibt verfügbar, sie liegt nur woanders. Entscheidend ist nicht, ob jedes Datum im neuen System steckt, sondern ob jeder, der etwas braucht, an einer definierten Stelle drankommt.

Warum der Betreiber die Migration anders plant als der Erbauer

Wer Software nur baut und übergibt, sieht die Migration als einmaliges Ereignis: Daten rein, Projekt abgenommen, fertig. Wer dieselbe Software danach betreibt, plant anders. Bei Wertstifter bauen und betreiben wir eigene Produkte, Wortfreunde und Reazon, und die laufen Tag für Tag mit echten Nutzern und echten Daten. Diese Erfahrung verändert, wie wir an eine Migration herangehen.

Ein Betreiber weiss, dass die Daten nach dem Umstieg nicht ruhen. Es treten Fälle auf, die kein Test gezeigt hat: ein Datensatz mit einem Sonderzeichen, das nirgends sonst vorkam, eine Beziehung, die in einem von zehntausend Fällen anders aussieht. Deshalb baut ein Betreiber die Migration so, dass sie wiederholbar und nachvollziehbar bleibt, mit Protokoll, was wohin gewandert ist und was übersprungen wurde. Dieselbe Sorgfalt, die einen Betrieb ab Tag eins produktionsreif macht, gilt für die Daten, mit denen er startet.

Am Ende ist die Frage nicht, ob du migrieren kannst, sondern ob du danach ruhig schlafen kannst. Eine Migration ist gelungen, wenn am Morgen nach dem Umstieg niemand merkt, dass etwas passiert ist, ausser dass die neue Software besser läuft. Dahin kommst du nicht mit einem Kopierbefehl, sondern mit Reihenfolge, Geduld und der Bereitschaft, die Daten ernster zu nehmen als das Programm, das sie verwaltet. Wenn du das Thema im grösseren Rahmen einer individuellen Lösung für dein KMU angehst, ist die Migration der Teil, den du zuerst durchdenken solltest, nicht zuletzt.