How Data Migrations Solutions AG accelerates its JiVS migration pipeline with agentic workflows — and how your organization can do the same.
In short: At Data Migrations Solutions AG (DMI), I build agentic workflows that automatically prepare SAP migration objects — on the JiVS platform, the Swiss market standard for enterprise migration and historization. An agent (Claude via Azure OpenAI Switzerland or directly via Anthropic) reads schema definitions from SAP S/4HANA or legacy ECC, identifies Z-tables and customizing, proposes mappings, and produces audit-ready plans. Per-object preparation drops from days to hours, without migration experts giving up control — they review only escalations instead of routine work. I bring this architecture to Swiss SME and enterprise migrations that are choking on backlog today.
Classical migration projects burn most of their budget not on the actual data transfer — but on per-object preparation. Every SAP installation has grown customer-specific over years: Z-tables, customer-owned fields in standard tables, modified customizing entries, undocumented workflows. Evaluating a migration object means reading through exactly those layers — and exactly there sits the backlog.
At DMI I see this effect in every engagement estimate: 60-70% of effort flows into discovery and object preparation, not into the ETL path itself. Migration experts work through lists of 200-500 objects, check data quality, document custom logic, propose mappings to the target system (S/4HANA Cloud, or an archive for GoBD/Swiss FADP purposes). It's work where a human does the same thing in 80% of cases and genuinely has to decide in 20%.
The result of that ratio is visible in every Swiss SAP landscape: migration projects run longer than planned, backlogs grow, S/4HANA Cloud roadmaps slip by quarters. Not because the technical difficulty was underestimated — but because per-object preparation doesn't scale as long as it runs purely manually. The same team that has to sign off on the plan also writes every proposal today. Exactly this separation of concerns — preparing the plan vs. approving the plan — is the entry point for agentic automation.
Classical RPA tools fail at this: they can't interpret schema differences, can't evaluate a customizing entry, can't place a Z-table in business context. ETL frameworks fail too — they execute what was manually decided beforehand. What's missing is a component that contextually reads, evaluates, and proposes — and cleanly escalates when something isn't unambiguous.
That's exactly what an agent does. And that's exactly why the pattern works on the JiVS platform: JiVS brings the migration mechanics (connectors, staging, historization logic), the agent adds the preparation and decision layer. Audit-suitability is preserved because every agent step is structurally logged — migration experts sign off on a plan at the end, not on a black-box result.
Another point that becomes clear at DMI: SAP migrations aren't regulatorily trivial. Anyone migrating GoBD- or Swiss FADP-relevant data has to be able to prove why which record went where — for years. With classical tools this is only achievable through extensive manual documentation. An agentic workflow produces that documentation as a by-product: every proposal, every evaluation, every escalation lands in the audit log. That doesn't change the compliance requirement — it lowers the cost of meeting it.
Planner-executor pattern, applied to individual migration objects.
The agent works through a fixed loop per migration object. It's triggered by the JiVS platform (e.g., when a new object lands in the backlog), uses SAP metadata as a tool, and at the end produces a structured migration plan plus a risk score. With a low risk score, the plan moves into the next processing step; with a high risk score, it escalates to a human migration expert — with all intermediate results exposed, so the review takes minutes instead of hours.
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-offImportant: the agent doesn't make final decisions. It prepares. This is intentional, because migrations are irreversibly expensive — anyone who builds black-box automation here risks damage no eval set can ever fully cover. Instead, the agent moves human work up the stack: less routine, more review quality.
Model-side I pick pragmatically: Claude (Anthropic) for longer reasoning chains over complex schema structures, Azure OpenAI Switzerland for data-residency-sensitive engagements. Open-source models (Qwen, Llama) are an option when everything has to run on-premises — typical in regulated industries. Tool-side, the agent uses direct SAP metadata access via JiVS connectors, no detour through exported files. Guardrails: an eval set of curated migration objects before every deployment, cost caps per backlog run, output-schema validation against the format JiVS expects, escalation triggers on any mapping operation that drops custom fields.
Detail pages follow in the use case library (Phase 3).
Per-migration-object backlog processing: schema parsing, mapping proposal, risk score, escalation. Delivers audit-ready migration plans for S/4HANA Cloud or hybrid target architectures.
Classification of whether legacy data should be migrated, historized in JiVS, or archived — based on business context, GoBD retention rules, and Swiss FADP requirements. With an explainable decision trail.
Automatically reconcile Z-fields, Z-tables, and modified customizing entries against the standard data model. Proposal: migrate, drop, refactor. Human reviews only conflict cases.
Classical ETL tools execute what was manually decided beforehand: mappings, filters, transformations are fixed in configuration files. The expensive work — figuring out what a particular Z-field means, whether a customizing entry is relevant, which edge case hides behind an empty column — happens before that and is human routine work. An agentic workflow shifts exactly that layer: the agent reads schemas and sample data, proposes mappings, recognizes edge cases, and escalates selectively. ETL stays unchanged underneath — JiVS does the data transfer, the agent does the preparation. Result: same data quality, less waiting time per object.
The agent is a pre- or intermediate layer, not a replacement for JiVS functionality. JiVS brings what it already does well today: connectors to SAP source systems, staging logic, historization mechanics, audit logging. The agent sits on top and processes migration objects from the JiVS backlog: it queries schemas and sample data, writes mapping proposals back into JiVS, documents its steps in a format that respects JiVS' audit trail. Migration experts keep working in the JiVS UI; per object they see a prepared plan plus risk score instead of an empty field. Anyone already using JiVS can introduce the agentic layer incrementally — per backlog type, per migration project — without rebuilding existing processes.
Source side: SAP ECC 6.0 and newer, SAP S/4HANA on-premises, SAP IS industry solutions — everything JiVS provides connectors for. Target side: SAP S/4HANA Cloud, S/4HANA on-premises as a greenfield target, archive systems for pure historization. Older versions (R/3 4.x) are technically possible but economically often a special case — here a discovery call helps assess whether the agentic layer justifies the effort. Non-SAP database migrations (Oracle to Postgres, old JDE/Baan systems) are also in scope, provided the source metadata is readable. The more structured and better-documented the source data model, the more leverage the agent has.
This is the core use case. The agent recognizes custom structures via namespace conventions (Z*, Y*, customer-owned table clusters) and by comparing against the SAP standard data model. Per custom element, it proposes one of three options: migrate (element is transferred with a mapped target field), drop (element is obsolete, empty, or without business reference), refactor (logic belongs in a different structure in the target system). Every proposal comes with reasoning and sample data. On uncertainty it escalates — the migration expert makes the final decision. No Z-element is silently dropped. Experience shows that the drop share among Z-table inventories over ten years old is substantial; the agent makes that cleanup visible instead of hiding it under ETL mappings.
Yes, because audit-suitability doesn't depend on the tool but on the logging. Every agent step — schema definition read, custom field identified, mapping proposed, risk score computed, escalation decision taken — is written in structured form to the JiVS audit log. Anyone checking in two years why record X arrived in the target system and record Y did not gets a complete trail: what data the agent saw, what it proposed, who signed the plan. For GoBD- and Swiss FADP-relevant migrations (retention obligations, personal data) this trail is exactly the standard already required. Put differently: agents don't make compliance documentation harder — they produce it as a by-product of the actual work, which under purely manual preparation often has to be reconstructed after the fact.
Book a non-binding 30-minute discovery call. We'll look together at where in your concrete migration project agentic workflows offer measurable leverage — and where classical tools are enough.
Book a discovery call