Warum SAP S/4HANA-Datenmigrationen oft länger dauern als geplant

Sechs Monate Projektlaufzeit, alles im Plan: Die technische Migration steht, die Systeme sind konfiguriert, der Go-Live rückt näher. Und dann kommt der Moment, in dem jemand fragt: „Wie sieht es eigentlich mit den Daten aus?“ Was folgt, kennen viele Projektverantwortliche nur zu gut: Der Zeitplan gerät ins Rutschen, zusätzliche Ressourcen werden benötigt, die Kosten steigen. Nicht wegen der Technik, sondern wegen der Daten. Genauer gesagt: wegen Dubletten, wegen fehlender Governance und wegen einer SAP Business-Partner-Umstellung, die sich als deutlich aufwendiger entpuppt als gedacht.

Machen Sie Ihre Daten bereit für SAP S/4HANA, KI und Analytics – mit unserem Data Readiness Blueprint

Die Datenmigration ist in den meisten SAP S/4HANA-Projekten der Bereich mit dem größten Risiko für Verzögerungen – nicht weil geeignete Werkzeuge fehlen, sondern weil die Datenqualität in den Quellsystemen selten so gut ist, wie alle Beteiligten stillschweigend annehmen. Dieser Beitrag zeigt, wo die typischen Stolpersteine bei der Datenmigration nach SAP S/4HANA liegen und wie Sie ihnen begegnen können.

Stolperstein #1: Dubletten, die niemand auf dem Schirm hatte

In einem ERP-System, das über Jahre gewachsen ist, sammeln sich zwangsläufig doppelte Datensätze an. Kunden, die unter leicht abweichenden Namen angelegt sind, Lieferanten mit mehreren Einträgen pro Standort, Materialstammdaten mit inkonsistenten Bezeichnungen. Im Tagesgeschäft fällt das oft gar nicht auf, weil die Mitarbeiter wissen, welcher Datensatz der richtige ist.

Bei der Migration nach SAP S/4HANA funktioniert dieses implizite Wissen nicht mehr. Spätestens bei der Zusammenführung von Debitoren und Kreditoren zum SAP Business Partner tauchen diese Altlasten auf. Und dann stellt sich die Frage: Welcher Datensatz wird übernommen? Welche Datensätze werden zusammengeführt? Und wer entscheidet das?

Die Lösung liegt nicht im Migrationstool, sondern in einer systematischen Datenbereinigung vor dem eigentlichen Migrationsprojekt. Das bedeutet: Dubletten identifizieren, Regeln für die Zusammenführung definieren und mit den Fachbereichen abstimmen. Wer das erst während der Migration macht, verliert garantiert Zeit.

Stolperstein #2: Fehlende Data Governance

Viele Unternehmen haben keine klar definierten Verantwortlichkeiten für ihre Stammdaten. Es gibt keine verbindliche Definition, wie ein Kundenstammsatz auszusehen hat, welche Felder Pflicht sind und wer Änderungen freigeben darf. Die Folge: Jede Abteilung pflegt Daten nach eigenen Regeln, und im Laufe der Jahre entsteht ein Wildwuchs, der sich bei einer Migration rächt.

SAP S/4HANA verzeiht diesbezüglich weniger als das alte SAP ECC-System. Felder, die früher optional waren, sind jetzt Pflichtfelder. Datentypen, die früher toleriert wurden, führen jetzt zu Fehlern. Wer ohne saubere Governance-Struktur migriert, steht vor der Wahl: Entweder nachträglich Tausende von Datensätzen manuell nachbearbeiten oder mit einer schlechten Datenqualität im neuen System leben.

Der bessere Weg: Data Governance bereits im Vorfeld der Migration aufsetzen. Das muss kein riesiges Programm sein. Oft reicht es, für die wichtigsten Datenobjekte (Kunden, Lieferanten, Materialien) klare Regeln zu definieren, Data Owner zu benennen und ein einfaches Qualitäts-Monitoring einzuführen. Diese Grundlagenarbeit zahlt sich nicht nur bei der Migration aus, sondern auch im laufenden Betrieb.

Stolperstein #3: Unterschätzte SAP Business-Partner-Umstellung

In SAP ECC gab es Debitoren (Kunden) und Kreditoren (Lieferanten) als getrennte Stammdatenobjekte. In SAP S/4HANA existiert diese Trennung nicht mehr. Beide Objekte werden unter dem einheitlichen Konzept des SAP Business Partner zusammengeführt. Was sich in der Theorie logisch und modern anhört, ist in der Praxis einer der aufwendigsten Aspekte der Datenmigration.

Die Herausforderung liegt nicht nur in der technischen Umstellung. Es geht darum, bestehende Prozesse zu hinterfragen: Welche Rollen bekommt welcher Geschäftspartner? Wie werden Kunden behandelt, die gleichzeitig Lieferanten sind? Was passiert mit historischen Belegen?

Auf der Grundlage unserer Beratungserfahrung lässt sich sagen: Die SAP Business-Partner-Einführung benötigt in der Regel mehr Zeit als ursprünglich eingeplant. Vor allem dann, wenn die Datenbasis nicht sauber ist (siehe Stolpersteine #1 und #2). Wer früh mit einem Pilotlauf beginnt und die Ergebnisse sorgfältig prüft, vermeidet böse Überraschungen kurz vor dem Go-Live.

Was erfolgreiche Projekte anders machen

Datenmigrationsprojekte, die zeitlich und budgetmäßig im Rahmen bleiben, haben in der Regel eine Gemeinsamkeit: Sie behandeln das Thema Datenqualität nicht als Nebenaufgabe, sondern als eigenständiges Teilprojekt. Konkret heißt das: Die Datenmigration wird bereits in der Planungsphase als kritischer Pfad identifiziert. Es gibt ein dediziertes Team, das sich um Bereinigung, Mapping und Testmigration kümmert. Und es wird akzeptiert, dass Datenarbeit Zeit kostet, die sich nicht abkürzen lässt.

Außerdem investieren erfolgreiche Projekte in Testmigrationen. Nicht eine, nicht zwei, sondern so viele wie nötig, bis die Ergebnisse stimmen. Jede Testmigration deckt Probleme auf, die sich im Vorfeld nicht vorhersehen lassen. Je früher sie erkannt werden, desto günstiger ist die Lösung.

Und schließlich: Die Fachbereiche müssen eingebunden werden. Datenqualität ist kein reines IT-Thema. Die Fachbereiche wissen, welche Daten korrekt sind, welche veraltet sind und welche zusammengehören. Ohne dieses Wissen läuft keine Migration rund.

Fazit: Datenqualität – vom Nice-to-have zum Must-have

Die Datenmigration ist oft ein massiv unterschätzter Faktor in SAP S/4HANA-Projekten. Technisch sind die notwendigen Werkzeuge vorhanden, methodisch gibt es bewährte Vorgehensweisen. Was in vielen Projekten fehlt, ist die realistische Einschätzung des Aufwands und die Bereitschaft, in die Datenqualität zu investieren, bevor das eigentliche Migrationstool überhaupt zum Einsatz kommt.

Wer die oben beschriebenen Stolpersteine kennt und frühzeitig adressiert, spart sich nicht nur Verzögerungen und Zusatzkosten. Er legt auch die Grundlage für ein SAP S/4HANA-System, das von Anfang an mit verlässlichen Daten arbeitet – und damit für alle weiteren Themen wie Reporting, Automatisierung und künstliche Intelligenz.