Datenmigration

Kurzantwort

Eine Datenmigration übernimmt Bestandsdaten aus dem Altsystem in ein neues Zielsystem. Sie läuft in getrennten Schritten: Extraktion, Transformation, Ladung, Abstimmung, Freigabe. Jeder Schritt hat einen eigenen Prüfpunkt und ein eigenes Ergebnisdokument. Vor dem scharfen Lauf steht mindestens ein vollständiger Probelauf auf einer Kopie des Zielsystems. Die Migration gilt erst als abgeschlossen, wenn Datensätze und Summen gegen das Altsystem abgestimmt und dokumentiert freigegeben sind. Vorher trägt kein Ergebnis.

Einordnung

Eine Migration ist ein Projekt mit eigenem Prüfpfad, nicht nur ein Datenimport. Sie berührt drei Datenklassen, die unterschiedlich streng behandelt werden. Stammdaten beschreiben Objekte dauerhaft, etwa Geschäftspartner und Anlagen. Bewegungsdaten halten Ereignisse fest, zum Beispiel Abrechnungen und Buchungen. Zeitreihen und Verbrauchsdaten wiederum tragen Werte über einen langen Zeitraum, teils über viele Jahre.

Für die Testseite eines Releases ist die Migration der Nachbarfall zur Teststrategie für Anwendungsänderungen. Dort prüft man Verhalten, hier prüft man Mengen und Werte. Die Teststrategie für AHB-Änderungen behandelt den Änderungsfall; dieser Artikel behandelt den Erstbefüllungsfall.

Was migriert wird, und was nicht

Migration Cockpit liefert Migrationsobjekte für Stammdaten und offene Bewegungsdaten (Migrate Your Data, Migration Cockpit). Zu jedem Objekt gehört eine Dokumentation: Zweck, Voraussetzungen, einbezogene Felder und ausgeschlossene Felder. Migration Objects for SAP S/4HANA, Kap. 1 „Available Migration Objects“

Zwei Einschränkungen sind für die Planung entscheidend. Erstens sind die Objekte für die Erstbefüllung gebaut. Sie legen Daten an und ändern vorhandene Datensätze nicht. Migration Objects, Kap. 1, Hinweis zu Initialmigration Zweitens markiert SAP einzelne Objekte als „restricted“ oder „deprecated“. Ein restricted-Objekt deckt nicht alle Felder eines Geschäftsprozesses ab. Ein deprecated-Objekt hat eine neuere Fassung und wird nach einigen Releases entfernt. Beide Markierungen stehen am Objektnamen, und SAP verlangt, die Objektdokumentation sorgfältig zu lesen.

Daraus folgt die Abgrenzung im Projekt: Alles, was ein Objekt laut Dokumentation nicht abdeckt, braucht einen manuellen Nachlauf, eine Erweiterung des Objekts oder eine bewusste Entscheidung gegen die Übernahme. Diese Lücken gehören in eine Liste mit Verantwortlichem.

Reihenfolge und Abhängigkeiten

Migrationsobjekte haben Vorgänger und Nachfolger. Die Detailseite eines Objekts zeigt die Abhängigkeiten, allerdings nur für Objekte, die dem Projekt bereits hinzugefügt wurden. The Migration Object Screen, Abschnitt „Dependencies“

Die Dokumentation nennt Voraussetzungen in der Form „die folgenden Objekte müssen bereits gepflegt oder migriert sein“. Ein Beispiel aus dem Bestand: Kundenkreditdaten setzen den Geschäftspartner beziehungsweise den Debitor voraus. Migration Objects, Kap. 1.18 „Customer – extend existing record by Credit Management data“, Abschnitt „Prerequisites“ Feste Anlagen mit Salden und Bewegungen setzen Kostenstelle, Profitcenter, Leistungsart und Material voraus. Migration Objects, Kap. 1.30 „Fixed asset“, Abschnitt „Prerequisites“

Die Regel lautet deshalb: zuerst Organisation und Referenzstammdaten, dann abhängige Stammdaten, zuletzt Bewegungsdaten und Salden. Wer die Reihenfolge umdreht, bekommt Fehler, die wie Datenfehler aussehen, aber Reihenfolgefehler sind.

Schlüssel, Nummernkreise und Wertemapping

Der kritischste Transformationsteil ist die Schlüsselbildung. Altsystem und Zielsystem vergeben Nummern nach eigenen Regeln. Beim Kundenobjekt beschreibt die Dokumentation den Zusammenhang aus BP-Gruppierung, Nummernkreis und Kundenkonto­gruppe. Eine falsche Gruppierung überschreibt die Kontoart. Migration Objects, Kap. 1.20 „Customer“, Abschnitt „Mapping Instructions“ Für die Altanlagennummer gilt, dass sie in ein eigenes Feld übernommen wird. Unteranlagen müssen im selben Projekt migriert werden, weil die Zuordnungstabelle projektbezogen ist (Migration Objects, Kap. 1.30 „Fixed asset“, Abschnitt „Migration Instructions“).

Werte, die es im Zielsystem nicht gibt, werden über Mapping-Aufgaben umgesetzt. Eine Wertzuordnung ordnet einem Quellwert einen Zielwert zu, eine Festwertzuordnung setzt einen Standardwert für ein Zielfeld. Beide Arten müssen abgeschlossen und bestätigt sein, bevor eine Simulation oder Migration läuft.

Abstimmung: vollständig, richtig, nur einmal

Die Abstimmung ist der Kern des Nachweises. Für die Anlagenmigration verlangt SAP ausdrücklich, dass die Daten im Zielsystem mit den Daten des Altsystems abgeglichen werden. Die Abstimmung und die zugehörigen Listen sind vor der Freigabe zu erstellen, weil sie später aus dem Zielsystem allein nicht mehr erzeugbar sind. Migration Objects, Kap. 1.30 „Fixed asset“, Abschnitt „Post-Processing“

Für werttragende Migrationen nennt SAP einen harten Prüfpunkt: Jedes bei der Migration erzeugte Verrechnungskonto muss sich auf null ausgleichen. Ein offener Saldo zeigt fehlende, doppelte oder falsch zugeordnete Daten. Posting Logic During Migration, Abschnitt zur Abstimmung der Verrechnungskonten

Drei Prüffragen decken den Nachweis ab:

1. Vollständig: Ist jeder Satz des Altsystems im Zielsystem vorhanden? Zähle je Objekt und je Organisationseinheit.
2. Richtig: Stimmen die werthaltigen Felder und die Summen zum Stichtag?
3. Nur einmal: Gibt es keine Doppelläufe, etwa durch einen wiederholten Import derselben Datei?

Konkretes Beispiel

Vereinfachtes Beispiel für einen Versorger, der sein Abrechnungssystem zu SAP IS-U migriert. Der Stichtag ist der 1. Januar.

Das Team extrahiert zunächst Geschäftspartner und Vertragskonten, dann Anlagen und Zählpunkte, zuletzt Abrechnungen und Verbrauchszeitreihen. Jede Extraktion ist auf den Stichtag begrenzt und wird mit einer Satzzahl und einer Summenprüfsumme abgeschlossen.

Im Transformationsteil werden Kontogruppen und Nummernkreise zugeordnet, Spartencodes und Tarifcodes auf die Zielwerte gemappt und abweichende Werte als Mapping-Aufgabe bestätigt. Die Transformation erzeugt eine Abweisungsdatei mit jedem Satz, der keine gültige Zuordnung gefunden hat.

Der Probelauf läuft auf einer Kopie des Zielsystems. Er deckt einen fehlenden Nummernkreis und 300 nicht gemappte Tarifcodes auf. Nach der Korrektur läuft der zweite Probelauf differenzfrei durch.

Beim scharfen Lauf werden die Objekte in der Abhängigkeitsreihenfolge geladen. Danach gleicht das Team die Satzzahlen je Objekt ab und prüft die Summe der Verbrauchswerte je Sparte gegen die Altsystem-Auswertung. Die Abweichung von zwei Zählpunkten wird als Nachtrag nachgeladen und erneut abgestimmt.

Folgen und Fehlerfälle

Falsche Reihenfolge erzeugt Abhängigkeitsfehler, die keine Datenfehler sind. Man korrigiert dann am falschen Ende.

Fehlende Objektabdeckung fällt spät auf. Ein restricted-Objekt liefert keine vollständigen Datensätze, und der manuelle Nachlauf beginnt nach dem Cutover.

Nicht bestätigte Mapping-Aufgaben blockieren Simulation und Migration. Der Lauf startet dann gar nicht, und der Fehler liegt in der Projektverwaltung, nicht in den Daten.

Doppelläufe entstehen, wenn dieselbe Extraktion zweimal geladen wird. Weil Objekte nur anlegen und nicht aktualisieren, sind die Folgen Dubletten statt Überschreibungen.

Unabgestimmte Summen sind der teuerste Fall. Sie fallen oft erst nach dem Go-live in der Abrechnung auf, wenn das Altsystem abgeschaltet ist.

Typische Missverständnisse

„Nach der Ladung ist die Migration fertig.“ Fertig ist sie nach der dokumentierten Freigabe. Der Nachlauf, also Nachzügler und Nachbuchungen, gehört dazu.

„Ein Objekt lädt alle Felder.“ Restricted-Objekte decken nicht alles ab. Die Objektdokumentation nennt In-Scope und Out-of-Scope.

„Der Import korrigiert vorhandene Sätze.“ Migration Cockpit legt an und ändert nicht. Für Korrekturen braucht es einen eigenen Weg.

„Die Simulation schreibt schon Daten.“ Nein. SAP beschreibt die Simulation als Lauf, der die Prüfungen ausführt, aber keine Daten ins Zielsystem schreibt. Sie zeigt genau die Meldungen, die der echte Transfer erzeugen würde. Simulating the Migration, Abschnitt zur Simulation

Quellen und Pflegehinweis

Tragende Quellen sind der SAP-Implementierungsleitfaden „Migration Objects for SAP S/4HANA“ mit den objektbezogenen Abschnitten zu Zweck, Voraussetzungen, Mapping und Post-Processing sowie die SAP-Help-Seiten zu Migration Cockpit, Migrationsobjekt, Simulation und Buchungslogik. Zitierter Stand des Leitfadens ist das Release 1909.000 vom 20. September 2019; SAP führt denselben Leitfaden als SPS04 mit Stand 23. April 2026 weiter, die hier zitierten Abschnitte sind in beiden Fassungen inhaltsgleich. Objektlisten und Markierungen ändern sich mit jedem Release, deshalb den Fassungsstand vor einer Übernahme am aktuellen Dokument prüfen.

Prüfe bei jeder Aktualisierung drei Dinge: ob ein genutztes Objekt inzwischen als restricted oder deprecated geführt wird, ob die Versionsvergleichsdokumentation neue oder geänderte Objekte meldet, und ob die Abstimmungsergebnisse des letzten Probelaufs noch zur aktuellen Datenbasis passen. Regeneriere die Abstimmungslisten vor dem Go-live neu, weil sie sich aus dem Zielsystem später nicht mehr rekonstruieren lassen.