Datenmigration bei S/4HANA: typische Stolperfallen

Die Technik einer S/4HANA-Migration ist beherrschbar – die Daten aus 20 Jahren IS-U-Betrieb sind es oft nicht. Dieser Beitrag beschreibt neun Stolperfallen, die in Migrationsprojekten immer wieder auftreten: jeweils mit dem Signal, an dem man sie erkennt, und dem Weg, sie zu vermeiden.

1. Karteileichen mit offenen Posten

Woran man sie erkennt: Vertragskonten, deren Verträge seit Jahren beendet sind, tragen noch offene Forderungen oder Guthaben: oft Kleinstbeträge, oft aber auch alte Streitfälle. In der Mengenanalyse fallen sie als beendete Verträge mit Saldo ungleich null auf.

Wie man sie vermeidet: Vor der Migration entscheiden, nicht während: ausbuchen, niederschlagen oder bewusst mitnehmen, aber als dokumentierte Regel je Fallklasse. Wer die Entscheidung ins Projekt verschiebt, diskutiert sie unter Zeitdruck im Testzyklus.

2. Sondervertrag oder Tarifkunde: die unklare Grenze

Woran man sie erkennt: Kunden mit individuellen Preisvereinbarungen sind im Altsystem als Tarifkunden angelegt (oder umgekehrt), erkennbar an Preis-Konditionen, die nicht zur Vertragsklasse passen. Im Zielsystem entscheidet diese Einordnung aber über Abrechnungslogik, Konditionspflege und Prozesse.

Wie man sie vermeidet: Die Abgrenzung als explizite Mapping-Regel definieren und in der Datenanalyse jeden Grenzfall klassifizieren, statt die Alt-Einordnung ungeprüft zu übernehmen.

3. Vertragsende: 31.12.9999 oder leer?

Woran man sie erkennt: Im Quellbestand existieren beide Varianten für „unbefristet": das Hochdatum 31.12.9999 und leere Endedatum-Felder. Je nach Migrationslogik wird ein leeres Feld als „beendet am Initialdatum" oder als Fehler interpretiert; im schlimmsten Fall entstehen still beendete Verträge.

Wie man sie vermeidet: Eine verbindliche Konvention je Feld festlegen und in der Transformationslogik erzwingen. Solche Datums-Semantiken gehören in die Feldregel-Dokumentation, nicht ins Gedächtnis einzelner Entwickler.

4. Sparten-Inkonsistenzen

Woran man sie erkennt: Anlage, Gerät und Vertrag derselben Versorgung tragen unterschiedliche Sparten, etwa eine Wasser-Anlage mit Strom-Zähler nach einer historischen Fehlkorrektur. Im Altsystem läuft das oft unauffällig weiter; die Migration bricht ab oder erzeugt fachlich falsche Strukturen.

Wie man sie vermeidet: Konsistenzprüfungen über die gesamte Objektkette (Anschlussobjekt → Verbrauchsstelle → Anlage → Gerät → Vertrag) als festen Teil der Datenanalyse fahren, lange bevor der erste Ladelauf startet.

5. Die Schlüsselstrategie: Alt-Schlüssel, die nicht passen

Woran man sie erkennt: Quellsystem-Schlüssel sprengen die Längengrenzen referenzierender Felder (das EMIGALL-Altschlüsselformat erlaubt 30 Zeichen, viele Referenzfelder praktisch nur zehn), enthalten Sonderzeichen oder sind über mehrere Quellsysteme hinweg nicht eindeutig. Spätestens beim Zusammenführen mehrerer Quellsysteme kollidieren identische Nummernkreise.

Wie man sie vermeidet: Die Schlüsselstrategie als eigenes Designdokument behandeln: Quellsystem-Kennungen nur dort, wo die Längengrenzen es zulassen, sonst kollisionsfreie Nummernkreise je Quellsystem und definierte Kürzungsregeln, dazu eine dauerhaft gepflegte Zuordnungstabelle Alt- zu Neuschlüssel. Sie ist später die Grundlage jeder Fehleranalyse und jeder Auskunft gegenüber Kunden und Marktpartnern. Wie das Schlüsselmapping in der Migration Workbench technisch sauber aufgesetzt wird, zeigt der Beitrag zum Key- und Status-Management in EMIGALL.

6. Hausscharf oder wohnungsscharf?

Woran man sie erkennt: Das Altsystem führt Anschlussobjekte hausscharf (ein Objekt pro Gebäude), das Zielkonzept verlangt wohnungsscharfe Verbrauchsstellen (oder umgekehrt). Sichtbar wird das an Adressen mit vielen Anlagen ohne Wohnungsunterscheidung.

Wie man sie vermeidet: Die Granularität der Objektstruktur vor dem Mapping festlegen und die Aufteilungsregeln (Wohnungsnummer, Lagezusatz, Zählpunktbezeichnung) definieren. Eine nachträgliche Umstrukturierung im Produktivsystem ist um ein Vielfaches teurer als eine saubere Regel in der Migration.

7. Reihenfolge- und Abhängigkeitsfehler

Woran man sie erkennt: Ladeläufe brechen mit Fremdschlüssel-Fehlern ab: Der Vertrag findet sein Vertragskonto nicht, das Gerät seine Anlage. Ursache ist fast immer eine verletzte Objekt-Reihenfolge, denn der IS-U-Datenbestand ist eine Kette, in der jedes Objekt seine Vorgänger braucht.

Wie man sie vermeidet: Die Ladereihenfolge strikt aus dem Objektmodell ableiten (Geschäftspartner vor Vertragskonto, Anlage vor Gerät vor Einbau) und Restart-Punkte definieren. Die Migration Workbench EMIGALL unterstützt das, aber die fachlich richtige Sequenz muss das Projekt selbst festlegen.

8. Hersteller-Extrakte als Zeitfalle

Woran man sie erkennt: Die Extraktion aus dem Altsystem liegt beim Softwarehersteller, und dessen Lieferungen kommen verspätet, unvollständig oder in wechselnden Formaten. Jeder Testzyklus wartet, und das Projekt taktet sich unbemerkt nach einem externen Dienstleister.

Wie man sie vermeidet: Extraktumfang, Format, Liefertermine und Nachlieferungswege früh vertraglich fixieren; jede Lieferung sofort mit automatisierten Eingangsprüfungen (Satzzahlen, Pflichtfelder, Schlüsseleindeutigkeit) abnehmen, statt Fehler erst im Ladelauf zu entdecken.

9. Nur zählen, nicht verstehen: die fehlende semantische Prüfung

Woran man sie erkennt: Das Projekt meldet „100 Prozent migriert", weil Quell- und Zielsatzzahlen übereinstimmen, aber der erste Abrechnungslauf liefert abweichende Beträge. Mengenprüfung allein sieht falsche Salden, vertauschte Sparten oder verschobene Stichtage nicht.

Wie man sie vermeidet: Neben der Mengen- immer eine semantische Prüfung: Salden je Vertragskonto gegen das Altsystem abstimmen, Vertragslaufzeiten und Gerätezuordnungen feldweise vergleichen, Probeabrechnungen gegen Altsystem-Ergebnisse rechnen. Eine belastbare Systematik dafür beschreibt der Beitrag zur Qualitätssicherung in der Datenmigration.

Das Muster hinter den Fallen

Auffällig ist, was in dieser Liste fehlt: die Technik. Weder EMIGALL noch die Zielplattform tauchen als Risiko auf; die Werkzeuge sind ausgereift. Acht dieser neun Fallen haben stattdessen dieselbe Wurzel: fachliche Entscheidungen, die zu spät getroffen werden. Nicht zufällig nennen laut der Natuvion/adesso-Transformationsstudie 2025 64 Prozent der befragten EVU-IT-Entscheider die Datenqualität als wichtigsten Erfolgsfaktor ihrer Transformation. Wer Datenanalyse und Regelwerk vor das Projekt zieht und jeden Testzyklus auf dem vollen Mengengerüst fährt (siehe Vorgehen und Zeitplan), entschärft die Fallen, bevor sie Geld kosten.

Migrationsfehler entstehen selten im Ladelauf – sie entstehen Monate vorher, wenn niemand die Regel für den Sonderfall festgelegt hat.