Wie Data Migrations Solutions AG ihre JiVS-Migrationspipeline mit agentischen Workflows beschleunigt — und wie Ihr Unternehmen das gleiche tun kann.
Kurz gesagt: Bei Data Migrations Solutions AG (DMI) baue ich agentische Workflows, die SAP-Migrationsobjekte automatisiert vorbereiten — auf der JiVS-Plattform, dem Schweizer Marktstandard für Enterprise-Migration und Historisierung. Ein Agent (Claude über Azure OpenAI Schweiz oder direkt via Anthropic) liest Schema-Definitionen aus SAP S/4HANA oder Legacy-ECC, identifiziert Z-Tabellen und Customizing, schlägt Mappings vor und produziert auditfertige Pläne. Vorbereitung einzelner Migrationsobjekte verkürzt sich von Tagen auf Stunden, ohne dass Migrationsexperten die Kontrolle abgeben — sie reviewen nur noch Eskalationen statt Routinearbeit. Diese Architektur bringe ich zu Schweizer KMU- und Enterprise-Migrationen, die heute an Backlogs ersticken.
Klassische Migrationsprojekte verbrennen den Grossteil ihres Budgets nicht im eigentlichen Datentransfer — sondern in der Vorbereitung pro Migrationsobjekt. Jede SAP-Installation ist über Jahre kundenspezifisch gewachsen: Z-Tabellen, kundeneigene Felder in Standard-Tabellen, modifizierte Customizing-Einträge, undokumentierte Workflows. Ein Migrationsobjekt zu bewerten heisst, durch genau diese Schichten zu lesen — und genau hier sitzt der Backlog.
Bei DMI sehe ich diesen Effekt in jeder Engagement-Schätzung: 60-70 % des Aufwands fliesst in Discovery und Object-Vorbereitung, nicht in den ETL-Pfad selbst. Migrationsexperten arbeiten Listen von 200-500 Objekten ab, prüfen Datenqualität, dokumentieren Custom-Logik, schlagen Mappings auf das Zielsystem (S/4HANA-Cloud, oder ein Archiv für GoBD/DSG-Zwecke) vor. Das ist Arbeit, in der ein Mensch in 80 % der Fälle das Gleiche macht und in 20 % wirklich entscheiden muss.
Das Resultat dieses Verhältnisses ist sichtbar in jeder Schweizer SAP-Landschaft: Migrationsprojekte dauern länger als geplant, Backlogs wachsen, S/4HANA-Cloud-Roadmaps verschieben sich um Quartale. Nicht weil die technische Schwierigkeit unterschätzt wurde — sondern weil die Vorbereitung pro Objekt nicht skaliert, solange sie ausschliesslich manuell läuft. Dasselbe Team, das den Plan unterzeichnen muss, schreibt heute auch jeden Vorschlag. Genau diese Aufgabentrennung — Plan vorbereiten vs. Plan freigeben — ist der Ansatzpunkt für agentische Automatisierung.
Klassische RPA-Tools versagen daran: Sie können keine Schema-Unterschiede deuten, keinen Customizing-Eintrag bewerten, keine Z-Tabelle in Geschäftskontext einordnen. ETL-Frameworks ebenfalls — sie führen aus, was vorher manuell entschieden wurde. Was fehlt, ist eine Komponente, die kontextuell liest, bewertet und vorschlägt — und dabei sauber eskaliert, wenn etwas nicht eindeutig ist.
Genau das macht ein Agent. Und genau deshalb funktioniert das Pattern auf der JiVS-Plattform: JiVS bringt die Migrations-Mechanik mit (Connectoren, Staging, Historisierungs-Logik), der Agent ergänzt die Vor- und Entscheidungsschicht. Audit-Tauglichkeit bleibt erhalten, weil jeder Agent-Schritt strukturiert geloggt wird — die Migrationsexperten unterschreiben am Ende einen Plan, kein Black-Box-Ergebnis.
Ein weiterer Punkt, der bei DMI deutlich wird: SAP-Migrationen sind regulatorisch nicht trivial. Wer GoBD- oder DSG-relevante Daten migriert, muss nachweisen können, warum welcher Datensatz wohin ging — über Jahre. Das ist mit klassischen Tools nur über aufwendige manuelle Dokumentation zu erreichen. Ein agentischer Workflow produziert diese Dokumentation als Nebenprodukt: jeder Vorschlag, jede Bewertung, jede Eskalation landet im Audit-Log. Das ändert nicht die Compliance-Anforderung — es senkt die Kosten, sie zu erfüllen.
Planner-Executor-Pattern, angewendet auf einzelne Migrationsobjekte.
Der Agent arbeitet pro Migrationsobjekt eine fixe Schleife ab. Er wird ausgelöst durch die JiVS-Plattform (z.B. wenn ein neues Objekt im Backlog landet), nutzt SAP-Metadaten als Werkzeug, und produziert am Ende einen strukturierten Migrationsplan plus Risk-Score. Bei niedrigem Risk-Score geht der Plan in den nächsten Verarbeitungsschritt; bei hohem Risk-Score eskaliert er an einen menschlichen Migrationsexperten — mit allen Zwischenergebnissen offengelegt, damit das Review in Minuten statt Stunden passiert.
Migration Object Backlog
↓
Agent: parse schema definition + sample data
↓
Agent: identify custom fields, Z-tables, dependencies
↓
Agent: propose mapping (target system) + risk score
↓
┌─────────────────────────┐
│ Risk score below threshold? │── no ──→ Escalate to human reviewer
└─────────────────────────┘
│ yes
↓
Agent: write structured migration plan + audit trail
↓
Human migration expert: sign-offWichtig: Der Agent entscheidet nicht final. Er bereitet vor. Das ist absichtlich so gewählt, denn 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 in den Stack: weniger Routine, mehr Review-Qualität.
Modellseitig setze ich pragmatisch ein: Claude (Anthropic) für längere Reasoning-Ketten über komplexe Schema-Strukturen, Azure OpenAI Schweiz für Daten-Residenz-sensitive Engagements. Open-Source-Modelle (Qwen, Llama) sind eine Option, wenn alles On-Premises laufen muss — typisch in regulierten Branchen. Tool-seitig nutzt der Agent direkten SAP-Metadaten-Zugriff über JiVS-Connectoren, kein Umweg über exportierte Files. Guardrails: Eval-Set mit kuratierten Migrationsobjekten vor jedem Deployment, Cost-Caps pro Backlog-Run, Output-Schema-Validierung gegen JiVS' erwartetes Format, Eskalations-Trigger auf jede Mapping-Operation, die Custom-Fields verwirft.
Detail-Seiten folgen in der Use-Case-Bibliothek (Phase 3).
Backlog-Bearbeitung pro Migrationsobjekt: Schema-Parsing, Mapping-Vorschlag, Risk-Score, Eskalation. Liefert auditfertige Migrationspläne für S/4HANA-Cloud oder hybride Zielarchitekturen.
Klassifikation, ob Legacy-Daten migriert, in JiVS historisiert oder archiviert werden — auf Basis von Geschäftskontext, GoBD-Aufbewahrungsregeln und DSG-Vorgaben. Mit erklärbarer Entscheidungs-Spur.
Z-Felder, Z-Tabellen und modifizierte Customizing-Einträge automatisiert mit Standard-Datenmodell abgleichen. Vorschlag: Migration, Drop, Refactor. Mensch reviewt nur Konfliktfälle.
Klassische ETL-Tools führen aus, was vorher manuell entschieden wurde: Mappings, Filter, Transformationen sind in Konfigurationsdateien fixiert. Die teure Arbeit — herauszufinden, was ein bestimmtes Z-Feld bedeutet, ob ein Customizing-Eintrag relevant ist, welcher Sonderfall sich hinter einer leeren Spalte verbirgt — passiert davor und ist menschliche Routinearbeit. Ein agentischer Workflow verschiebt genau diese Schicht: der Agent liest Schemas und Sample-Daten, schlägt Mappings vor, erkennt Sonderfälle und eskaliert gezielt. ETL bleibt darunter unverändert — JiVS macht den Datentransfer, der Agent macht die Vorbereitung. Ergebnis: gleiche Datenqualität, weniger Wartezeit pro Objekt.
Der Agent ist eine vor- bzw. zwischengelagerte Schicht, kein Ersatz für JiVS-Funktionalität. JiVS bringt mit, was es heute schon kann: Connectoren zu SAP-Quellsystemen, Staging-Logik, Historisierungs-Mechanik, Audit-Logging. Der Agent setzt darüber auf und verarbeitet Migrationsobjekte aus dem JiVS-Backlog: er fragt Schemas und Sample-Daten ab, schreibt Mapping-Vorschläge zurück in JiVS, dokumentiert seine Schritte in einem Format, das JiVS' Audit-Trail respektiert. Migrationsexperten arbeiten weiter in der JiVS-UI; sie sehen pro Objekt einen vorbereiteten Plan plus Risk-Score statt eines leeren Felds. Wer JiVS bereits einsetzt, kann die agentische Schicht inkrementell einführen — pro Backlog-Typ, pro Migrationsprojekt — ohne bestehende Prozesse umzubauen.
Quellseitig: SAP ECC 6.0 und neuer, SAP S/4HANA on-premises, SAP-IS-Branchenlösungen — alles, wofür JiVS Connectoren bereitstellt. Zielseitig: SAP S/4HANA Cloud, S/4HANA on-premises als Greenfield-Ziel, Archiv-Systeme für reine Historisierung. Ältere Versionen (R/3 4.x) sind technisch möglich, aber wirtschaftlich oft ein Sonderfall — hier hilft ein Discovery-Call, um zu beurteilen, ob die agentische Schicht den Aufwand rechtfertigt. Datenbank-Migrationen ausserhalb SAP (Oracle-zu-Postgres, alte JDE/Baan-Systeme) sind ebenfalls in Scope, sofern die Quell-Metadaten lesbar sind. Generell gilt: Je strukturierter und besser dokumentiert das Quell-Datenmodell, desto mehr Hebel hat der Agent. Bei sehr alten Systemen mit reverse-engineerten Schemas wird der Migrationsexperte häufiger eingreifen — die Architektur funktioniert weiterhin, der Effizienzgewinn fällt aber kleiner aus.
Das ist der Kern-Use-Case. Der Agent erkennt Custom-Strukturen über Namespace-Konventionen (Z*, Y*, kundeneigene Tabellen-Cluster) und über Vergleich mit dem SAP-Standard-Datenmodell. Pro Custom-Element schlägt er eine von drei Optionen vor: Migration (Element wird mit gemapptem Ziel-Feld übertragen), Drop (Element ist veraltet, leer oder ohne Geschäftsbezug), Refactor (Logik gehört im Zielsystem in eine andere Struktur). Jeder Vorschlag kommt mit Begründung und Sample-Daten. Bei Unsicherheit eskaliert er — der Migrationsexperte trifft die finale Entscheidung. Kein Z-Element wird stillschweigend verworfen. Erfahrungsgemäss ist der Drop-Anteil bei Z-Tabellen-Beständen über zehn Jahre erheblich; der Agent macht diese Bereinigung sichtbar, statt sie unter ETL-Mappings zu verstecken.
Ja, weil Audit-Tauglichkeit nicht vom Werkzeug abhängt, sondern vom Logging. Jeder Agent-Schritt — gelesene Schema-Definition, identifiziertes Custom-Field, vorgeschlagenes Mapping, berechneter Risk-Score, getroffene Eskalations-Entscheidung — wird strukturiert ins JiVS-Audit-Log geschrieben. Wer in zwei Jahren prüft, warum Datensatz X im Zielsystem ankam und Datensatz Y nicht, bekommt eine vollständige Spur: Welche Daten der Agent sah, was er vorschlug, wer den Plan unterzeichnete. Für GoBD- und DSG-relevante Migrationen (Aufbewahrungspflichten, Personendaten) ist genau diese Spur der Standard, der ohnehin gefordert ist. Anders gesagt: Agenten machen Compliance-Dokumentation nicht komplizierter, sondern erzeugen sie als Nebenprodukt der eigentlichen Arbeit — was bei rein menschlicher Vorbereitung oft nachträglich rekonstruiert werden muss.
Buchen Sie einen unverbindlichen 30-Minuten-Discovery-Call. Wir prüfen gemeinsam, wo in Ihrem konkreten Migrationsprojekt agentische Workflows messbaren Hebel haben — und wo klassische Tools ausreichen.
Discovery-Call anfragen