Migrations-Objekte pro Backlog-Eintrag vorbereiten — Schema parsen, Z-Tabellen erkennen, Mapping vorschlagen, sauber eskalieren.
Kurz gesagt: Agentische Vorbereitung von SAP-Migrationsobjekten — Schema parsen, Z-Tabellen identifizieren, Mapping vorschlagen, eskalieren. Inspiriert durch laufende Arbeit bei Data Migrations Solutions AG auf der JiVS-Plattform. Branchen mit dem grössten Hebel: Manufacturing, Versicherung und Public Sector mit über zehn Jahre gewachsenen SAP-ECC- oder S/4HANA-Landschaften. Stack: Claude (Anthropic direkt) oder Azure OpenAI Switzerland, JiVS als Migrationsplattform, SAP S/4HANA als Quell- und Zielsystem. Vorbereitung pro Objekt fällt typischerweise von Tagen auf Stunden; Migrationsexperten reviewen Eskalationen statt Routinemappings. Audit-Trail entsteht als Nebenprodukt — GoBD- und FADP-anschlussfähig.
SAP-Migrationen kosten nicht Quartale, weil der Datentransfer schwierig ist — sondern wegen der manuellen Objektanalyse davor. Jede ECC-6.0- oder S/4HANA-Installation ist über Jahre kundenspezifisch gewachsen: hunderte Z-Tabellen, Z-Felder in Standardtabellen wie MARA, VBAK, BSEG, modifiziertes Customizing, undokumentierte Abhängigkeiten. Ein Migrationsobjekt zu bewerten heisst, durch diese Schichten zu lesen, Sample-Daten zu prüfen, Sonderfälle zu erkennen, ein Mapping vorzuschlagen und die Entscheidung in einem Format zu dokumentieren, das in zwei Jahren noch ein Audit übersteht.
Aus laufenden Migrationsprojekten — insbesondere bei Data Migrations Solutions AG — ist es ein gut belegter Erfahrungswert, dass Migrations-Experten typischerweise 60-70 % ihrer Zeit in genau dieser Vorbereitung verbringen, statt in der eigentlichen Migration. Das ist keine veröffentlichte Benchmark, sondern eine Engagement-Schätzung, die sich projektübergreifend wiederholt. Hinzu kommt: SAP Migration Cockpit deckt nur Standardobjekte mit klar definierten Strukturen ab — sobald Z-Tabellen aus den frühen 2000ern im Spiel sind, fällt der Cockpit-Pfad weg, und die Arbeit kippt zurück in manuelle Listenbearbeitung. Genau diesen Engpass adressiert ein Migrations-Agent.
Der Agent arbeitet als vorgelagerte Schicht über JiVS. Pro Migrationsobjekt aus dem Backlog liest er Schema-Definition und Sample-Daten direkt aus dem SAP-Quellsystem, identifiziert Custom-Fields und Z-Tabellen, schlägt ein Mapping auf das Zielsystem (S/4HANA Cloud, Greenfield-S/4HANA, Archiv) vor und berechnet einen Risk-Score. Der Score wird gegen einen Schwellwert geprüft: unter Schwellwert schreibt der Agent den vorbereiteten Plan direkt in JiVS, über Schwellwert eskaliert er an einen menschlichen Migrationsexperten — mit allen Zwischenergebnissen offengelegt, damit das Review in Minuten statt Stunden passiert. Jeder Schritt landet strukturiert im Audit-Log.
Modellseitig wird Claude (über Anthropic direkt) für längere Reasoning-Ketten über komplexe Schema-Strukturen eingesetzt; Azure OpenAI Switzerland kommt zum Zug, wenn Daten-Residenz in der Schweiz Vertragsbedingung ist. Tool-seitig greift der Agent über JiVS-Connectoren auf SAP-Metadaten zu — kein Umweg über exportierte Files. Guardrails: kuratiertes Eval-Set vor jedem Deployment, Cost-Caps pro Backlog-Run, Output-Schema-Validierung gegen JiVS' erwartetes Format, harte Eskalations-Trigger auf jede Mapping-Operation, die Custom-Fields verwirft.
Wichtig: Der Agent entscheidet nicht final. Er bereitet vor. Migrationen sind irreversibel teuer — wer hier Black-Box-Automatisierung baut, riskiert Schäden, die kein Eval-Set jemals voll abdeckt. Stattdessen verschiebt der Agent menschliche Arbeit nach oben: weniger Routine, mehr Review-Qualität, vollständige Spur.
Eine Schweizer Versicherung — Komposit, kein realer Klient — steht vor der S/4HANA-Cloud-Migration. Im Backlog: rund 400 Migrationsobjekte, darunter zwölf Jahre alte Z-Tabellen ohne Dokumentation, kundeneigene Felder in BSEG für interne Abrechnungslogik, und ein Customizing-Bestand, der seit drei Reorganisationen nicht aufgeräumt wurde. Der Agent (Claude, über Azure OpenAI Switzerland für FADP-Datenresidenz) arbeitet das Backlog ab: pro Objekt liest er Schema und 50 Sample-Records, klassifiziert jedes Custom-Feld, schlägt ein Mapping vor, berechnet einen Risk-Score. Bei rund 70 % der Objekte liegt der Score unter dem Schwellwert; der Plan wird automatisch in JiVS geschrieben. Die übrigen 30 % landen mit offengelegtem Reasoning in der Eskalations-Queue. Die Migrationsexperten machen weiter dieselbe Arbeit wie vorher — aber an den Fällen, die tatsächlich Erfahrung brauchen.
Typischer Effekt: Die Vorbereitung eines Migrationsobjekts fällt von ein bis zwei Tagen pro Objekt in Richtung Stunden — directional, nicht als veröffentlichte Benchmark. Der Hebel sitzt nicht im einzelnen Mapping, sondern in der Aggregation: ein Backlog von 300 bis 500 Objekten wird vom kritischen Pfad zum normalen Sprintdurchsatz. Migrationsexperten reviewen die Eskalations-Queue und treffen die schwierigen Entscheidungen — Routine-Mappings produziert der Agent. Als Nebenprodukt entsteht pro Objekt ein vollständiger Audit-Trail mit Input-Snapshot, Agent-Reasoning, Vorschlag, Eskalations-Entscheidung und menschlicher Bestätigung. Dieser Trail ist GoBD- und FADP-anschlussfähig und wird nicht nachträglich rekonstruiert, sondern fällt mit der eigentlichen Arbeit an.
Klassische ETL-Tools sind regelbasiert und an kundenspezifischem SAP-Customizing strukturell brüchig. Sie führen Mappings aus, die vorher manuell entschieden wurden — und genau dieser manuelle Schritt ist der Engpass. Ein Migrations-Agent reasoniert über Schema, Code-Referenzen und Sample-Daten zugleich. Er erkennt zum Beispiel ein deprecated Z-Feld, das in der Standard-ETL stillschweigend transformiert würde, und stellt die Frage, ob die Migration überhaupt sinnvoll ist. Mit anderen Worten: ETL bleibt darunter unverändert — der Agent ersetzt nicht den Datentransfer, sondern die menschliche Vorarbeit. Resultat: gleiche Datenqualität, weniger Wartezeit pro Objekt, dokumentierte Bereinigung statt versteckter Transformation.
Quellseitig: SAP ECC 6.0 und neuer, einschliesslich S/4HANA on-premises sowie SAP-IS-Branchenlösungen. Zielseitig: SAP S/4HANA Cloud, S/4HANA on-premises als Greenfield-Ziel, oder Archiv-Systeme für reine Historisierung. Ältere R/3-Versionen (4.x) sind technisch möglich, aber wirtschaftlich oft ein Sonderfall — hier hilft ein Discovery-Call. Modulübergreifend abgedeckt sind FI, CO, MM, SD und HCM; weitere Module wie PP oder PM laufen agentengestützt, profitieren aber von gezielter Vorabstimmung. Je strukturierter und besser dokumentiert das Quell-Datenmodell, desto mehr Hebel hat der Agent.
Der Agent klassifiziert pro Feld in eine von vier Kategorien: still-in-use (Feld wird aktiv beschrieben und gelesen), unused (Feld ist seit X Monaten leer oder hat einen konstanten Default), partial (Feld wird nur für einen Datentyp-Subset verwendet), unclear (Bedeutung lässt sich aus Schema und Sample-Daten nicht ableiten). Auf Basis der Klassifikation schlägt er ein Mapping vor — bei „unclear" eskaliert er an den Migrationsexperten. Pro Feld entsteht ein Audit-Eintrag mit Begründung und Sample-Daten. Kein Custom-Feld wird stillschweigend verworfen.
Jede Agent-Entscheidung wird strukturiert geloggt: Input-Snapshot (welche Schema-Definition und welche Sample-Daten der Agent sah), Reasoning (welche Klassifikation und welches Mapping er ableitete), Entscheidung (Auto-Write oder Eskalation), menschliche Bestätigung im Eskalationsfall. Diese Spur entspricht den GoBD-Dokumentationsanforderungen für nachvollziehbare Datenverarbeitung sowie der FADP-Forderung nach Bearbeitungs-Nachverfolgbarkeit. Hinweis: Die finale Compliance-Freigabe liegt beim Auditor des Kunden — der Agent liefert die Spur, der Auditor bewertet sie.
Dieser Use Case sitzt in der Praktik Agentensysteme & Workflows und greift in mehrere benachbarte Migrations-Use-Cases.
Praktik: Wie Agenten in Produktionsumgebungen gebaut, betrieben und auditfähig gemacht werden — Patterns, Guardrails, Plattformwahl.
Klassifikation, ob Legacy-Daten migriert, in JiVS historisiert oder archiviert werden — mit erklärbarer Entscheidungs-Spur.
Z-Felder, Z-Tabellen und modifizierte Customizing-Einträge automatisiert mit Standard-Datenmodell abgleichen.
Auditfertige Diff-Reports mit Diskrepanz-Klassifikation und Sign-off-Paketen für Cut-over.
Diese Lösung passt nicht zu jedem SAP-Projekt. In einem unverbindlichen 30-Minuten-Discovery-Call besprechen wir ehrlich, ob Ihre Migration ein Kandidat ist — und wo klassische Tools ausreichen.
Discovery-Call anfragen