EMIGALL erklärt: die IS-U Migration Workbench in der Praxis

Wer SAP IS-U ablöst oder nach SAP S/4HANA Utilities migriert, kommt an einem Werkzeug nicht vorbei: der IS-U Migration Workbench, im Projektalltag nach ihrem Transaktionscode schlicht „EMIGALL" genannt. Dieser Beitrag erklärt, wie das Werkzeug arbeitet, wie eine Migrationsdatei aufgebaut ist und an welchen Stellen Projekte in der Praxis stolpern.

Was die Migration Workbench ist

Die IS-U Migration Workbench ist SAPs Standardwerkzeug, um Stamm- und Bewegungsdaten in SAP IS-U und das Vertragskontokorrent FI-CA zu laden. Sie stammt aus der Utilities-Branchenlösung selbst und kennt deren Datenmodell vollständig: Geschäftspartner, Vertragskonten, Anschlussobjekte, Anlagen, Geräte, Verträge, Belege, bis hinein in die Abhängigkeiten zwischen diesen Objekten.

Gearbeitet wird dateibasiert: Pro Migrationsobjekt entsteht eine Eingangsdatei in einem festen Format, die EMIGALL einliest und verbucht. Welche Felder gefüllt werden, welche Prüfungen greifen und wie Schlüssel behandelt werden, wird pro Migrationsobjekt in der Workbench als Customizing gepflegt; daraus generiert das Werkzeug die eigentlichen Ladeprogramme. Das Verfahren trägt sowohl die Initialmigration (alle Daten in einem geplanten Ablauf) als auch spätere Delta-Läufe, etwa wenn einzelne Datenbereiche nachgezogen werden.

Warum EMIGALL: Laden über die Anwendungslogik

Der entscheidende Unterschied zu tabellenbasierten Verfahren: EMIGALL schreibt nicht direkt in Datenbanktabellen, sondern ruft dieselbe Anwendungslogik auf, die auch beim manuellen Anlegen im Dialog läuft. Jeder Datensatz durchläuft beim Verbuchen die Plausibilisierungen des Systems: Pflichtfeldprüfungen, Customizing-Abgleiche, Feldkonvertierungen.

Das kostet Laufzeit, bringt aber eine Garantie, die im regulierten Umfeld schwer wiegt: Was EMIGALL verbucht hat, ist ein konsistentes SAP-Objekt, das anschließend in Abrechnung und Marktkommunikation funktioniert. Es gibt keine „technisch eingefügten" Sätze, die erst Monate später als Klärfall auffallen. Genau deshalb ist EMIGALL seit Jahrzehnten das gesetzte Werkzeug für IS-U-Neueinführungen und Systemwechsel in der Energiewirtschaft.

Aufbau einer Migrationsdatei

Eine EMIGALL-Datei ist eine Festlängendatei: Jedes Feld wird auf die Länge des SAP-Zielfeldes mit Leerzeichen aufgefüllt. Der Aufbau folgt immer demselben Muster:

• &INFO-Header: Die erste Zeile beschreibt die Datei selbst: erzeugendes Programm, Quellsystem, Erstellungsdatum, Zielmandant.
• Master-Record: Pro Geschäftsobjekt ein führender Satz. Er beginnt mit dem Alt-Schlüssel (OldKey), einem bis zu 30 Zeichen langen Schlüssel aus dem Quellsystem, gefolgt vom Satztyp und den Felddaten.
• Sub-Records: Abhängige Sätze mit demselben OldKey: Adressen, Bankverbindungen, Steuerdaten, Kommunikationsdaten. Der Satztyp steuert, in welche Zielstruktur die Zeile gehört.
• &END-Trailer: Die letzte Zeile enthält die Zeilenzahl als Vollständigkeitskontrolle.

Schematisch und stark verkürzt sieht eine solche Datei so aus:

&INFO   EXTRAKT_BP      ALTSYSTEM   20260301   100
4711                          INIT  MUSTERMANN                ANNA       19800101
4711                          ADDR  MUSTERWEG 12          01234 MUSTERSTADT
&END    000004

Die erste Datenzeile ist der Master-Record: Er beginnt mit dem OldKey „4711", der auf die volle Breite von 30 Zeichen mit Leerzeichen aufgefüllt wird, gefolgt vom Satztyp (hier INIT für den Stammsatz) und den Felddaten. Die zweite Datenzeile ist ein Sub-Record desselben Partners: gleicher OldKey, anderer Satztyp (ADDR für die Adresse). Der Trailer zählt: vier Zeilen, Datei vollständig.

Ein einzelner Geschäftspartner wird so schnell zu rund zehn Records: Stammsatz, Adresse, Adressgültigkeit, Bankverbindung und weitere, alle über den identischen OldKey verklammert. Diese Alt-/Neu-Schlüssel-Logik ist so zentral, dass wir ihr einen eigenen Beitrag widmen: Key & Status Management (KSM) in EMIGALL.

Migrationsobjekte und die strikte Reihenfolge

Ein Migrationsobjekt ist ein logisches Datenpaket wie „Geschäftspartner", „Anlage" oder „Forderungsbeleg", mit definierter Struktur aus Master- und Sub-Records. Weil spätere Objekte per Fremdschlüssel auf frühere verweisen, ist die Ladereihenfolge nicht verhandelbar:

1. Stammdaten Geschäftspartner (PARTNER) und Vertragskonten (ACCOUNT) bilden das Fundament, denn das Vertragskonto referenziert bereits den Partner.
2. Technische Stammdaten Anschlussobjekt (CONNOBJ), Verbrauchsstelle (PREMISE), Anlage (INSTLN) und Gerät (DEVICE). Jede Ebene hängt an der vorherigen.
3. Verträge Der Einzug (MOVE_IN) verbindet Partner, Vertragskonto und Anlage und braucht deshalb alle drei bereits im System. Danach folgen abhängige Objekte wie Abschlagspläne.
4. Belege Forderungen, Zahlungen und Abrechnungsbelege kommen zuletzt, denn sie hängen an Vertragskonto und Vertrag.

Wohin die wichtigsten Migrationsobjekte laden, zeigt die folgende Übersicht. Die Kern-Tabelle ist dabei jeweils der Anlaufpunkt für die Datenkontrolle nach dem Ladelauf:

Verweist ein Satz auf einen Alt-Schlüssel, den EMIGALL noch nicht kennt, schlägt die Auflösung fehl und der Satz bleibt liegen, und mit ihm alle Sätze, die wiederum auf ihn verweisen. Wie solche Fehler sich fortpflanzen, zeigt auch der Beitrag zu typischen Stolperfallen der Datenmigration.

Typische Stolperfallen

• Padding-Fehler. Die Feldlängen müssen exakt zur SAP-Felddefinition passen. Ein Zeichen zu viel verschiebt alle Folgefelder. Die Datei wird abgelehnt oder, schlimmer, still falsch interpretiert.
• Pflichtfelder unterschätzt. Was im Quellsystem optional war, ist in SAP oft Pflicht. Solche Lücken müssen in der Feldanalyse auffallen, nicht erst im Ladelauf.
• Customizing nach den Daten. Jeder Wert, den ein Datensatz nutzt, ob Vertragskontotyp, Belegart oder Sparte, muss vor dem Laden im Customizing existieren. Die Reihenfolge lautet immer: erst Customizing, dann Daten.
• Datumsformate. Quellsysteme liefern gern „2026-01-31", SAP erwartet „20260131". Solche Konvertierungen gehören in die automatisierte Transformationsstrecke, nicht in Handarbeit.

Der gemeinsame Nenner: EMIGALL verzeiht keine Ungenauigkeit, meldet sie aber zuverlässig. Wer die Fehlerprotokolle der Testläufe systematisch auswertet, verwandelt jede Ablehnung in eine Korrektur der Mapping-Regeln, und der Produktivlauf wird planbar.

Das Werkzeug-Umfeld

Im Projektalltag arbeitet niemand nur in einer Transaktion. Rund um die Workbench haben sich fünf Anlaufstellen etabliert:

• EMIGALL, die Migration Workbench selbst: Migrationsobjekte customizen, Ladeprogramme generieren, Ladeläufe starten.
• SLG1, das Anwendungslog: Fehleranalyse je Ladelauf, filterbar nach Objekt und Zeitraum.
• SM37 für die Batch-Jobs der Massenläufe: Laufzeit, Status, Abbrüche.
• AL11, um die Migrationsdateien auf dem Applikationsserver einzusehen, bevor und nachdem sie geladen wurden.
• SE16N für die Datenkontrolle direkt in den Zieltabellen: Sind die Sätze so angekommen, wie das Mapping es verspricht?

Läuft das unter S/4HANA weiter?

Ja. Die Migration Workbench ist Bestandteil von SAP S/4HANA Utilities in den On-Premise- und Private-Cloud-Varianten und bleibt dort das Werkzeug für die Übernahme des IS-U-Kerns. Das SAP S/4HANA Migration Cockpit deckt die Utilities-spezifischen Objekte gerade nicht ab. Die Abgrenzung haben wir im Werkzeugvergleich für Utilities ausgeführt. Wer die Ablösung von SAP IS-U plant, findet den Gesamtfahrplan im Beitrag Migration von SAP IS-U auf S/4HANA Utilities: Vorgehen & Zeitplan und die Terminlage in SAP IS-U Ablösung: warum 2027 das entscheidende Jahr ist.

EMIGALL ist kein Ladeprogramm, sondern ein Qualitätsfilter: Was durchkommt, ist ein konsistentes SAP-Objekt – was nicht durchkommt, wäre später ein Klärfall geworden.

Direkt ausprobieren: Der EMIGALL-Übersetzer erkennt das Migrationsobjekt Ihres Snippets und macht die Felder lesbar. Kostenlose Kostprobe, ohne Registrierung.

Häufige Fragen