Datenmigration aus Altsystemen: Wie Daten den Umzug sicher überstehen

Wer alte Software ablöst, denkt zuerst an die neue Oberfläche. An schnellere Ladezeiten. An modernere Funktionen. Dann kommt die Frage, die alles bremst: Was passiert mit den Daten?

Datenmigration aus einem Altsystem ist kein Nebenprojekt. Sie ist oft der aufwändigste und riskanteste Teil jeder Software-Modernisierung. Und genau dort passieren die meisten Fehler.

Dieser Artikel zeigt, was eine Datenmigration aus Altsystemen so schwierig macht, welche Phasen seriös vorgehen, und wie Sie verhindern, dass beim Umzug Daten verloren gehen oder verfälscht ankommen.

Was ist Datenmigration und warum ist sie bei Altsystemen besonders komplex?

Datenmigration bedeutet: Daten aus einem bestehenden System in ein anderes übertragen. Das klingt wie Kopieren und Einfügen. Ist es aber nicht.

In Altsystemen haben sich Datenstrukturen über Jahre entwickelt. Oft ohne Plan. Oft ohne Dokumentation. Was 2008 als schnelle Lösung gebaut wurde, hat sich bis heute fortgepflanzt. Das Ergebnis: Tabellenstrukturen, die kaum jemand noch versteht. Felder, die umgewidmet wurden. Doppelte Einträge. Inkonsistente Formate.

Ein neues System kennt diese Eigenheiten nicht. Es erwartet saubere, strukturierte Daten. Die Lücke zwischen dem, was das Altsystem liefert, und dem, was das neue System braucht, ist die eigentliche Herausforderung.

Hinzu kommt: Viele Altsysteme laufen produktiv. Sie können nicht einfach abgeschaltet werden. Die Migration muss parallel zum laufenden Betrieb stattfinden. Das erhöht die Komplexität erheblich.

Was passiert wenn die Migration schief geht?

Die Schäden sind vielfältig.

Datenverlust ist das Schlimmste. Einträge, die seit Jahren im System stehen, fehlen plötzlich. Kundendaten, Bestellhistorien, Verträge. Was nicht mehr da ist, lässt sich selten vollständig rekonstruieren.

Datenverfälschung ist hinterhältiger. Die Daten sind noch da, aber falsch. Adressen wurden beim Import getauscht. Preisfelder haben das falsche Format. Dezimaltrennzeichen wurden nicht korrekt umgewandelt. Solche Fehler fallen oft erst Wochen nach dem Go-Live auf, wenn ein Kunde reklamiert oder eine Rechnung nicht stimmt.

Betriebsausfälle entstehen, wenn die Migration länger dauert als geplant und das neue System schon abgelöst werden soll, das alte aber noch gebraucht wird. Wer keinen klaren Plan hat, steht zwischen zwei Systemen, die beide nicht richtig funktionieren.

Compliance-Probleme kommen dazu, wenn bei der Migration personenbezogene Daten nicht korrekt behandelt werden. Die DSGVO (Datenschutz-Grundverordnung) gilt auch für den Daten-Umzug. Wer Kundendaten ohne Protokoll und Kontrolle verschiebt, riskiert eine Beanstandung.

Die fünf Phasen einer sicheren Datenmigration

Sorgfalt ist kein Luxus. Sie ist der einzige Weg, der wirklich funktioniert.

Phase 1: Bestandsaufnahme und Analyse

Bevor eine einzige Zeile migriert wird, muss klar sein, was überhaupt da ist.

Welche Daten liegen in welchem Format vor? Welche Felder werden tatsächlich genutzt, welche sind veraltet oder leer? Gibt es Doppeleinträge? Wie sind Beziehungen zwischen Tabellen aufgebaut?

Diese Analyse ist mühsam. Sie lässt sich nicht überspringen. Wer sie auslässt, kauft sich später Probleme. Oft werden bei dieser Phase technische Schulden sichtbar, die sich über Jahre angesammelt haben: inkonsistente Felder, unklare Datentypen, redundante Strukturen.

Phase 2: Datenbereinigung

Altsysteme enthalten selten saubere Daten. Kundenadressen mit Tippfehlern. Felder, die zweckentfremdet wurden. Einträge, die doppelt vorhanden sind. Vor der Migration werden diese Daten bereinigt.

Das ist kein optionaler Schritt. Ein neues System, dem schlechte Daten übergeben werden, rechnet auch schlechte Ergebnisse aus. Garbage in, garbage out, wie es im Englischen heißt. Übersetzt: Wer Datenmüll eingibt, bekommt Datenmüll zurück.

Die Bereinigung geschieht idealerweise im Altsystem, bevor der eigentliche Umzug beginnt. So bleibt das neue System von Anfang an sauber.

Phase 3: Mapping und Transformation

Das neue System hat andere Felder, andere Strukturen, andere Logik als das alte. Beim Mapping wird festgelegt, welches Feld aus dem Altsystem welchem Feld im neuen System entspricht.

Das klingt technisch. Ist es auch. Aber die Entscheidungen dahinter sind oft geschäftlich: Was machen wir mit Feldern, die im neuen System keine direkte Entsprechung haben? Was passiert mit veralteten Kategorien? Wer trifft diese Entscheidungen?

Hier braucht es Fachkenntnis auf beiden Seiten: jemand der das Altsystem kennt und jemand der das neue System versteht. Und jemand der die Geschäftslogik kennt.

Zusätzlich werden Transformationen definiert: Datumsformate anpassen, Währungsbeträge umrechnen, Freitextfelder strukturieren. Alles, was das neue System erwartet und das alte nicht liefert.

Phase 4: Testmigrationen

Keine echte Migration ohne Probelauf. Zuerst werden Testdaten migriert, dann geprüft, ob alles korrekt angekommen ist.

Das ist kein einmaliger Vorgang. Seriöse Datenmigration durchläuft mehrere Testzyklen. Nach jedem Lauf wird geprüft: Sind alle Einträge da? Stimmen die Werte? Funktionieren die Beziehungen zwischen Datensätzen?

Testmigrationen zeigen auch, wie lange der echte Umzug dauert. Bei großen Datenmengen kann das ein entscheidender Faktor sein. Wer weiß, dass die Migration sechs Stunden dauert, kann ein Wartungsfenster planen. Wer das nicht weiß, wird im schlechtesten Fall von der eigenen Laufzeit überrascht.

Phase 5: Go-Live und Nachkontrolle

Die eigentliche Migration findet in einem festgelegten Fenster statt. Idealerweise nachts oder am Wochenende, wenn der Betrieb ruhig ist.

Direkt nach dem Go-Live beginnt die Kontrolle. Stichproben werden gezogen. Geschäftskritische Datensätze werden manuell geprüft. Das Altsystem wird noch einige Wochen parallel betrieben, um im Notfall zurückwechseln zu können.

Diese Parallelphase ist keine Schwäche. Sie ist ein Sicherheitsnetz. Wer das Altsystem zu früh abschaltet, hat keinen Rückweg.

Was Entscheider häufig unterschätzen

Der Zeitaufwand ist fast immer größer als erwartet. Das liegt nicht daran, dass irgendjemand schlecht schätzt. Es liegt daran, dass Altsysteme Überraschungen bereithalten.

Daten die angeblich sauber sind, sind es nicht. Felder, die laut Entwickler nie genutzt wurden, enthalten doch Einträge. Formate, die eigentlich standardisiert sein sollten, sind es nicht.

Wer das weiß und entsprechend plant, ist im Vorteil. Wer auf den besten Fall hofft, verliert Zeit und Budget.

Außerdem: Eine Datenmigration ist keine rein technische Aufgabe. Sie braucht Fachleute, die das Geschäft verstehen. Daten sind nicht abstrakt. Sie repräsentieren Kunden, Bestellungen, Verträge, Abrechnungen. Wer nur technisch denkt, übersieht geschäftliche Zusammenhänge.

Was einen guten Dienstleister auszeichnet

Nicht jede Agentur hat Erfahrung mit Altsystemen. Die Fähigkeit, ein neues System aufzubauen, bedeutet nicht automatisch, dass jemand die Fallstricke alter Datenstrukturen kennt.

Fragen Sie konkret: Welche Systeme wurden in der Vergangenheit migriert? Wie wird mit unvollständigen Daten umgegangen? Gibt es einen Rollback-Plan, wenn etwas schiefläuft?

Wer auf diese Fragen pauschale Antworten gibt, hat vermutlich wenig echte Erfahrung. Wer konkret antwortet und eigene Schwierigkeiten nennt, hat die Praxis dahinter.

Fazit: Datenmigration ist planbar, wenn man früh anfängt

Datenmigration aus einem Altsystem muss nicht scheitern. Sie scheitert, wenn sie zu spät begonnen wird, zu wenig Zeit eingeplant wird oder die Datenqualität des Altsystems nicht ernst genommen wird.

Wer früh anfängt, gründlich analysiert und Testmigrationen ernst nimmt, bringt seine Daten sicher ans Ziel. Ohne Verlust, ohne Verfälschung, ohne unerwarteten Ausfall.

Sprechen Sie uns an. Das Erstgespräch ist kostenlos. Wir schauen uns Ihre Datenbasis an und sagen Ihnen ehrlich, womit Sie es zu tun haben und wie ein realistischer Migrationsplan aussieht.