SAP Stammdaten Migration planen in 7 Schritten

Eine SAP Stammdaten Migration planen heißt nicht, Datenbestände rechtzeitig in ein Zielsystem zu laden. Entscheidend ist, ob Geschäftspartner, Materialien, Finanzobjekte und organisationsbezogene Daten am Go-Live-Tag fachlich korrekt, technisch konsistent und in den angebundenen Prozessen nutzbar sind. Fehler in diesen Grundlagen zeigen sich selten nur im Migrationstool. Sie führen zu gesperrten Aufträgen, falschen Bewertungen, fehlenden Berechtigungen oder manuellen Notprozessen im Betrieb.

Besonders bei S/4HANA-Transformationen wird die Stammdatenmigration deshalb zum Steuerungsthema. Das Ziel ist nicht die größtmögliche Übernahmequote. Ziel sind belastbare Daten, klar definierte Verantwortlichkeiten und ein kontrollierter Übergang, der sich testen, freigeben und im Bedarfsfall nachvollziehen lässt.

1. Migrationsumfang fachlich abgrenzen

Der erste Planungsfehler liegt häufig im Umfang. Wenn alle historisch vorhandenen Datensätze als migrationsrelevant gelten, wächst nicht nur das Datenvolumen. Auch Bereinigung, Mapping, Testaufwand und Abstimmungsbedarf steigen erheblich. Eine fachliche Abgrenzung trennt daher aktive, rechtlich oder betrieblich erforderliche Daten von Altbeständen ohne operative Funktion.

Diese Entscheidung muss je Objekt getroffen werden. Bei Geschäftspartnern können offene Belege, laufende Verträge, Kreditprüfungen und steuerliche Anforderungen relevant sein. Bei Materialien spielen Bestände, Disposition, Stücklisten, Klassifizierungen und Qualitätsdaten eine Rolle. Finanzstammdaten müssen mit Kontenplan, Buchungskreisen, Kostenrechnung und Reporting-Anforderungen abgestimmt werden.

Eine reine IT-Entscheidung reicht nicht aus. Fachbereiche, Datenverantwortliche und Prozessverantwortliche müssen dokumentieren, welche Objekte mit welchen Ausprägungen in das Zielsystem gelangen. Daraus entsteht ein prüfbarer Migrationsscope statt einer Annahme, die erst im Test auffällt.

2. Datenqualität vor dem Mapping bewerten

Mapping löst keine Qualitätsprobleme. Es übersetzt Feldwerte und Strukturen zwischen Quell- und Zielsystem. Sind Dubletten, ungültige Adressen, fehlende Klassifizierungen oder widersprüchliche Statuswerte bereits in der Quelle vorhanden, werden sie ohne vorgelagerte Regeln weitergegeben oder erzeugen Fehler in der Ladeverarbeitung.

Sinnvoll ist ein Datenqualitätsprofil je Stammdatenobjekt. Es beschreibt Vollständigkeit, Eindeutigkeit, fachliche Gültigkeit, Aktualität und Konsistenz zu verbundenen Objekten. Bei Kunden- und Lieferantendaten gehört dazu beispielsweise die Prüfung von Dubletten, Steuerkennzeichen, Zahlungsbedingungen und Sperrstatus. Bei Materialstämmen sind Mengeneinheiten, Materialarten, Werke, Beschaffungsdaten und Bewertungsdaten typische Prüffelder.

Nicht jede Auffälligkeit muss vor der Migration vollständig korrigiert werden. Das hängt von Risiko und Nutzung ab. Ein unvollständiger Altadressdatensatz kann akzeptabel sein, wenn er nicht mehr operativ verwendet wird. Ein fehlender Steuerwert bei einem aktiven Debitor ist dagegen ein klarer Sperrgrund. Diese Unterscheidung verhindert, dass Teams Zeit in fachlich irrelevante Bereinigungen investieren und gleichzeitig kritische Fehler übersehen.

3. Zielmodell und Mapping als verbindliche Arbeitsgrundlage festlegen

In S/4HANA verändern sich Stammdatenstrukturen nicht nur technisch. Die Umstellung von Debitoren und Kreditoren auf den Business Partner ist ein bekanntes Beispiel. Hinzu kommen neue Pflichtfelder, andere Wertelisten, harmonisierte Organisationsstrukturen oder geänderte Ableitungslogiken. Ein Mapping-Dokument muss deshalb mehr leisten als die Zuordnung von Quell- und Zielfeld.

Für jede Regel sollten fachliche Bedeutung, Transformation, Standardwert, verantwortliche Freigabe und Umgang mit Ausnahmen festgehalten werden. Wo Werte zusammengeführt, aufgeteilt oder aus anderen Attributen abgeleitet werden, braucht es nachvollziehbare Entscheidungsregeln. Das gilt ebenso für Default-Werte. Ein technisch zulässiger Standardwert ist keine fachliche Freigabe.

Besondere Aufmerksamkeit verdienen Abhängigkeiten. Ein Geschäftspartner kann zwar erfolgreich angelegt werden, aber ohne korrekt zugeordnete Rollen, Buchungskreisdaten oder Vertriebsbereichsdaten für nachgelagerte Prozesse unbrauchbar bleiben. Bei Materialstämmen bestehen vergleichbare Abhängigkeiten zwischen Grunddaten, Werkssichten, Lagerorten, Dispositionsparametern und Bewertung. Die Datenflussanalyse sollte diese Beziehungen sichtbar machen, bevor die erste Lademappe erstellt wird.

4. Verantwortlichkeiten und Entscheidungswege verbindlich machen

Eine Stammdatenmigration scheitert oft nicht an einer fehlenden Transformationsregel, sondern an ungeklärter Entscheidungskompetenz. Wer entscheidet über einen Dublettenfall? Wer genehmigt eine Ausnahme von Pflichtfeldern? Wer trägt das Risiko, wenn ein Fachbereich keine Bereinigung fristgerecht liefert?

Ein belastbares Vorgehen unterscheidet mindestens Datenverantwortung, technische Ausführung, fachliche Freigabe und Projektsteuerung. Diese Rollen können in kleineren Organisationen bei wenigen Personen liegen. Sie müssen dennoch getrennt dokumentiert sein. Gerade unter Zeitdruck entstehen sonst informelle Freigaben, die später weder im Cutover noch im revisionssicheren Reporting nachvollzogen werden können.

Ergänzend braucht das Projekt ein festes Eskalationsverfahren. Kritische Datenfehler dürfen nicht in Tabellenlisten ohne Bearbeitungsfrist verbleiben. Status, Verantwortlicher, Entscheidungstermin und Auswirkung auf Test oder Go-Live sollten zentral nachverfolgt werden. So wird aus Datenbereinigung ein steuerbarer Arbeitsstrom.

5. Migration iterativ testen, nicht nur technisch validieren

Ein erfolgreicher Ladejob belegt lediglich, dass das System die Daten angenommen hat. Er belegt nicht, dass die Daten fachlich vollständig, korrekt abgeleitet und in End-to-End-Prozessen verwendbar sind. Deshalb sollte die Teststrategie mehrere Ebenen verbinden: technische Validierung, fachliche Stichproben, Abstimmung von Mengen und Werten sowie Prozessintegration.

Frühe Testmigrationen dienen vor allem dazu, Mapping-Lücken, Datenqualitätsfehler und Laufzeitprobleme sichtbar zu machen. Spätere Probeläufe müssen den geplanten Cutover realistisch abbilden. Dazu zählen Extraktion, Bereinigung, Freigabe, Transformation, Ladefolge, Nachverarbeitung und Abstimmung. Auch Fehlerkorrekturen und erneute Läufe müssen zeitlich eingeplant werden.

Bei der fachlichen Validierung sind messbare Kriterien erforderlich. Beispiele sind die Anzahl übernommener Geschäftspartner nach Rolle, die Vollständigkeit aktiver Materialsichten oder die Übereinstimmung von Bestands- und Bewertungswerten. Abweichungen brauchen definierte Toleranzen und eine begründete Freigabe. Ohne diese Kriterien bleibt die Aussage „Daten sehen gut aus“ nicht belastbar.

6. Cutover auf Datenobjekte und Abhängigkeiten ausrichten

Der Cutover-Plan ist keine Liste technischer Aktivitäten. Er beschreibt einen kontrollierten Betriebsübergang mit klaren Zeitfenstern, Abhängigkeiten und Rückfallentscheidungen. Für Stammdaten ist insbesondere die Delta-Logik kritisch: Welche Änderungen entstehen nach dem letzten Extrakt im Altsystem? Wie werden sie gesperrt, erfasst, übertragen und validiert?

Die Ladefolge ergibt sich aus den Beziehungen der Objekte. Organisationsstrukturen, Customizing und Referenzwerte müssen vor abhängigen Stammdaten bereitstehen. Danach folgen etwa Geschäftspartner, Materialstämme und weitere Objekte, bevor offene Vorgänge oder Bewegungsdaten verarbeitet werden. Die tatsächliche Reihenfolge hängt von der Systemlandschaft und den Integrationen ab. Sie sollte im Probelauf bewiesen, nicht nur konzeptionell beschrieben sein.

Für jeden Cutover-Schritt sind ein verantwortlicher Ausführender, ein fachlicher Abnehmer, ein Zeitlimit und ein Abbruchkriterium sinnvoll. Ein Rückfall in das Altsystem kann nach einem bestimmten Fortschritt unverhältnismäßig werden. Gerade deshalb muss vorab klar sein, an welchem Kontrollpunkt eine Go- oder No-Go-Entscheidung getroffen wird.

7. Stabilen Betrieb nach dem Go-Live absichern

Die Migration endet nicht mit der Freigabe des Produktivsystems. In den ersten Betriebstagen zeigen sich oft Sonderfälle aus Schnittstellen, Rollenmodellen oder seltenen Geschäftsprozessen. Eine Hypercare-Phase sollte festlegen, wie fachliche Fragen, Datenfehler und Korrekturen priorisiert werden. Dabei ist zwischen echten Migrationsfehlern, neuen Stammdatenerfassungen und Prozess- oder Berechtigungsproblemen zu unterscheiden.

Für den nachhaltigen Betrieb lohnt sich außerdem ein Mindestset an Datenqualitätskontrollen. Dazu gehören Dublettenprüfungen, Pflichtfeldüberwachung, Auswertungen zu unzulässigen Kombinationen und ein geregelter Änderungsprozess. Wenn Datenverantwortung nach dem Projekt wieder unklar wird, kehren Qualitätsprobleme schnell zurück.

Die Übergabe sollte deshalb nicht nur Ladeprotokolle umfassen. Erforderlich sind auch freigegebene Mapping-Regeln, offene Restpunkte, Entscheidungen zu Ausnahmen, Testnachweise und Betriebsverantwortlichkeiten. Das schafft eine belastbare Grundlage für Audits, spätere Releases und Erweiterungen der SAP-Landschaft.

Migrationsplanung mit belastbaren Entscheidungsgrundlagen

Quteco unterstützt SAP-Projektteams mit Quick Checks, Workshops und operativer Projektbegleitung bei Datenflussanalyse, Testmanagement und Cutover-Planung. Im Fokus stehen ein realistisch abgegrenzter Migrationsscope, dokumentierte Freigaben und Datenprüfungen, die den Produktivbetrieb tatsächlich absichern. Je früher kritische Abhängigkeiten sichtbar werden, desto besser lassen sich knappe Projektzeit und fachliche Verantwortung wirksam zusammenführen.