Verlustfreie Datenmigration: was der Begriff verlangt – und woran Systemwechsel scheitern

In vielen Unternehmen steht in den nächsten Monaten ein Systemwechsel an – ERP-Ablösung, Abschaltung einer historisch gewachsenen Eigenentwicklung, Umzug in die Cloud. Die Entscheidung für das neue System ist dabei selten das Problem. Zum Stolperstein wird fast immer das, was danach kommt: die Daten. Wer „verlustfreie Datenmigration“ ausschreibt, meint meistens etwas anderes, als der Begriff technisch hergibt. Dieser Beitrag klärt, was tatsächlich dahintersteckt, woran Projekte scheitern und womit man realistisch rechnen muss. Wie wir das in der Praxis umsetzen, steht auf unserer Seite zur Datenmigration.

Warum gerade jetzt so viele Systemwechsel anstehen

Der auffälligste Treiber ist ein Datum: Ende 2027 läuft die Mainstream-Wartung für SAP ECC 6.0 aus, danach gibt es nur noch kostenpflichtige Extended Maintenance. Die Computerwoche berichtete unter Berufung auf Gartner, dass Ende 2024 erst rund 14.000 von 35.000 ECC-Kunden migriert waren – und dass 40 bis 45 Prozent voraussichtlich auch über 2027 hinaus beim alten System bleiben werden.

Für den Mittelstand ist das weniger eine SAP-Frage als ein Symptom. Dieselbe Mechanik greift bei Windows- und Datenbank-Versionen, die aus dem Support fallen, bei CRM-Systemen, deren Hersteller auf ein reines Cloud-Modell umstellt, und bei Individualsoftware, die niemand mehr warten kann, weil die Entwickler von damals längst woanders arbeiten. Der Auslöser ist unterschiedlich, die eigentliche Arbeit ist jedes Mal dieselbe – und sie liegt in den Daten.

Die Auswahl des Zielsystems dauert Monate und bindet die Geschäftsführung. Die Datenmigration wird oft in einem Nebensatz des Lastenhefts abgehandelt. Genau umgekehrt verteilt sich das Projektrisiko.

Was „verlustfrei“ technisch wirklich bedeutet

Umgangssprachlich heißt verlustfrei: Es geht nichts verloren. Das ist als Anforderung wertlos, weil nicht überprüfbar. Belastbar wird der Begriff erst, wenn man ihn in drei Kriterien zerlegt.

Vollständigkeit ist das offensichtliche und einfachste. Jeder Datensatz, der im Altsystem fachlich relevant ist, existiert nach der Migration im Zielsystem. Prüfbar über Mengengerüste und Summenabgleiche – wenn im Altsystem 84.312 Belege liegen und im Zielsystem 84.107, muss die Differenz erklärbar sein, und zwar Satz für Satz.

Referenzielle und semantische Integrität ist der Teil, an dem es meistens hakt. Eine Rechnung ohne zugehörigen Kunden ist formal migriert und fachlich Müll. Schwieriger noch sind stille Bedeutungsverschiebungen: Ein Statusfeld mit fünf Ausprägungen im Altsystem trifft auf ein Zielsystem, das nur drei kennt. Technisch lässt sich das mappen. Ob die Auswertung danach noch dasselbe aussagt, entscheidet nicht die Technik, sondern die Fachabteilung.

Nachvollziehbarkeit heißt, dass für jeden Datensatz im Zielsystem dokumentiert ist, woher er stammt und welche Transformation er durchlaufen hat. Das ist keine Fleißaufgabe für die Projektakte, sondern die Voraussetzung dafür, überhaupt sinnvoll auf Fehler reagieren zu können – und in regulierten Bereichen schlicht Pflicht.

Woran Migrationen in der Praxis scheitern

Die Fehlerbilder wiederholen sich mit bemerkenswerter Zuverlässigkeit:

• Die Datenqualität wird zu spät geprüft. Dubletten, Karteileichen und uneinheitliche Schreibweisen entstehen über Jahre und fallen im Tagesgeschäft nicht auf, weil die Sachbearbeitung sie im Kopf korrigiert. Das Zielsystem kann das nicht. Wer erst beim Testlauf feststellt, dass ein Viertel der Kundenstammdaten unbrauchbar ist, hat den Zeitplan bereits verloren.
• Das Mapping bleibt lückenhaft. Felder ohne Entsprechung im Zielsystem werden gerne vertagt – und landen dann im Freitextfeld oder nirgends. Jedes nicht gemappte Feld ist eine bewusste Entscheidung oder ein späterer Datenverlust; ein Drittes gibt es nicht.
• Es gibt keinen echten Probelauf. Eine Migration mit 500 Testdatensätzen sagt nichts über Laufzeiten, Sperren und Speicherverhalten bei 5 Millionen. Belastbar ist nur die Probemigration auf Vollbestand, mit anschließendem Abgleich gegen das Altsystem.
• Der Rückweg ist nicht geplant. Wenn am Montagmorgen klar wird, dass es nicht läuft, entscheidet die Frage, ob man innerhalb weniger Stunden auf das Altsystem zurückkann, über Schadenshöhe und Nerven. Diese Antwort will man vor dem Go-Live kennen.

Wie lange dauert eine Datenmigration?

Die ehrliche Antwort: Das lässt sich ohne Blick auf zwei Größen nicht seriös sagen – die Zahl der zu migrierenden Datenobjekte und die Zugänglichkeit des Altsystems. Ein sauber dokumentiertes Quellsystem mit offener Datenbank verhält sich völlig anders als eine Anwendung, aus der man Daten nur über Reportexporte herausbekommt.

Was sich dagegen verlässlich sagen lässt, ist die Verteilung des Aufwands. Analyse, Mapping und Bereinigung beanspruchen regelmäßig ein Vielfaches der eigentlichen Überführung. Das Skript, das die Daten schreibt, ist in Tagen gebaut; die Klärung, was „aktiver Kunde“ in beiden Systemen bedeutet, dauert Wochen und braucht die Fachabteilung. Projekte geraten fast nie in Verzug, weil die Technik zu langsam war, sondern weil fachliche Entscheidungen nicht rechtzeitig getroffen wurden.

Ein Muster, das sich bewährt hat: Die Bereinigung startet parallel zur Auswahl des Zielsystems, nicht danach. Dubletten lassen sich im Altsystem beseitigen, lange bevor feststeht, wohin es überhaupt geht – und diese Arbeit ist in jedem Szenario nicht umsonst.

Was den Preis bestimmt

Von Pauschalpreisen für Datenmigrationen sollte man sich fernhalten, denn sie setzen voraus, dass jemand den Zustand der Daten bereits kennt. Genau das ist vor der Analyse nie der Fall. Die Kosten treiben im Wesentlichen vier Faktoren: die Anzahl unterschiedlicher Datenobjekte – nicht die Datenmenge, denn zehn Millionen Belege eines Typs sind einfacher als fünfzig verschiedene Objekttypen mit je tausend Sätzen; der Zustand der Altdaten; die Frage, wie viel Historie tatsächlich mitmuss; und die Zahl der angebundenen Umsysteme, deren Schnittstellen ebenfalls angepasst werden wollen.

Der wirksamste Kostenhebel liegt beim letzten Punkt. Die Frage „Brauchen wir wirklich zwölf Jahre Bewegungsdaten im neuen System?“ ist unbequem, weil sie niemand allein beantworten will. Sie zu stellen ist trotzdem lohnender als jede technische Optimierung – Historie, die in ein Archiv statt ins Produktivsystem wandert, kostet einen Bruchteil.

Wie wir vorgehen

Unser Ablauf folgt dem, was sich aus den Fehlerbildern oben ergibt. Am Anfang steht die Analyse: Struktur und Qualität der Quelldaten aufnehmen, Zielstruktur dagegenlegen, Mapping vollständig dokumentieren – einschließlich der bewussten Entscheidung, welche Felder nicht mitkommen. Es folgt die Bereinigung mit Dublettenabgleich, Normalisierung und Anreicherung, deren Ergebnis messbar sein muss und nicht behauptet. Und schließlich die Überführung über mindestens eine Probemigration auf Vollbestand mit anschließendem 1:1-Abgleich, bevor der kontrollierte Go-Live mit definiertem Rückweg stattfindet.

Danach beginnt der eigentliche Nutzen: Erst auf konsolidierten Daten lassen sich Auswertungen und Dashboards bauen, denen die Fachabteilung auch glaubt. Steht der Systemwechsel im Zusammenhang mit einem Umzug in die Cloud, greift das eng mit der Cloud-Migration ineinander – die Reihenfolge von Bereinigung und Umzug will dann bewusst festgelegt werden.

Fazit

Verlustfreie Datenmigration ist kein Werkzeug, das man kauft, sondern ein Nachweis, den man führt: Vollständigkeit, Integrität und Nachvollziehbarkeit, belegt durch einen Abgleich gegen das Altsystem. Der größte Hebel liegt dabei früher, als die meisten Projektpläne vorsehen – in der Datenbereinigung, die man beginnen kann, bevor das Zielsystem überhaupt feststeht. Wenn bei Ihnen ein Systemwechsel ansteht und Sie den Zustand Ihrer Daten realistisch einschätzen wollen, sprechen Sie uns an.

Weiterführende Quellen

• Computerwoche – S/4HANA-Migration stockt: Viele Kunden bleiben ECC auch nach 2027 treu
• SAP – Wartungsstrategie und Umstieg auf S/4HANA