What AI Actually Does in an S/4HANA Data Migration — and What It Doesn't
AI is not a data-cleaning button. It is a controlled accelerator for field mapping and rule authoring, and it only pays off when every AI draft passes human approval, a sandbox test and an audit trail. The numbers: about 30 expert-days by hand versus about 12 with FieldMap.
· Andrzej Bartosiewicz · updated 3 November 2026
Every vendor promises AI will speed up your migration. Almost none say where it must stop.
SAP ECC mainstream maintenance ends in 2027, and the pressure to move faster is real. Most vendor decks answer that pressure with the same slide: AI will speed up your migration. Very few say where the AI has to stop.
AI does not clean data on its own. Treated as a button, it creates risk the team cannot see. Treated as a draftsman inside a control loop, it removes the slowest, most expert-locked work from the critical path. The difference is the operating model around it, not the model itself.
The promise, and the quiet risk
The pitch is simple: point an AI at messy ERP data and it harmonises, maps and cleanses automatically. The expensive work in a migration is somewhere else entirely — defining what correct means for every field, encoding that as transformation and validation logic, and proving it before the load. That work is manual, expert-dependent, and the place where timelines slip.
Two failure modes follow.
Over-trust the AI
Unverified output moves toward production. The team inherits errors it cannot trace, and they surface inside the cut-over window. Avoidable — with governance.
Dismiss the AI
Senior consultants spend days writing every rule by hand. The slowest, most expert-locked step in the programme, done the slowest way, because the alternative felt unsafe.
AI as a controlled accelerator, not a cleaning button
Our position: AI belongs inside a control loop, and every output is a draft, not a decision.
| Stage | Step | Who / what |
|---|---|---|
| 0 | Plain-language specification | The consultant describes the mapping need |
| 01 | AI draft | vise FieldMap |
| 02 | Sandbox test | Rule tester on real records |
| 03 | Human approval | A named reviewer |
| 04 | Version and audit trail | Every change recorded |
| Final | Governed load | Target system, via standard interfaces |
Throughput goes up. Control stays exactly where it was: nothing reaches the target until a person has tested, approved and versioned it.
Where AI saves real time: field mapping
Mapping source to target schemas is one of the slowest steps in any ECC-to-S/4HANA or cross-ERP programme, and the one most locked to scarce experts. FieldMap drafts the mappings and the transformation logic from a plain-language description and your metadata, runs them through a Python conversion engine, and shows every proposal with a confidence score and the reason behind it — semantic fit, type compatibility, length, value distribution.
The sandbox step matters as much as the draft. Before anything is committed, the rule runs in a tester against real records. Consultants shift from writing rules to reviewing, correcting and approving them — and business consultants without classic ETL experience can take part in mapping work under the same governance.
Where AI stays on a leash: validation and business logic
AI can propose validation rules. It cannot decide which records are acceptable for your business. The costliest errors are cross-field dependencies, country-specific rules and referential constraints unique to your operating model. vise DMW runs dictionary-driven validation against those rules, and a human confirms any AI-suggested rule before it joins the checks. Nothing loads on an AI’s say-so.
The pattern that makes AI safe at enterprise scale
Whether AI drafts a mapping in FieldMap or proposes a rule in vise DMW, the same five controls apply — and because they are the same, data-governance leads can defend the approach and audit it across multi-OpCo rollouts:
- Suggestion + human approval. The AI proposes; a named person decides. An AI-drafted mapping is not used until a reviewer signs off.
- Sandbox before production. Every output is tested on real records before it touches live data.
- Versioning. Every change shows what changed and why.
- Audit trail. Each step is captured; AI-drafted decisions are explainable after the fact.
- Four-eyes on execution. A second person, separate from the approver, on the load itself.
We run this pattern in production on a multi-country programme at a global brewing group. Throughput rose; governance did not loosen for a single load.
What the numbers actually look like
Measured in expert-days on the same conversion object:
| Path | Expert-days (approx.) | What happens |
|---|---|---|
| Manual | ≈30 | Senior consultants author and test mapping and transformation rules by hand |
| With FieldMap | ≈12 | AI drafts, a human approves; same deliverable, same governance |
| Difference | ~60% fewer | On the mechanical part of the work |
The figures are illustrative; validate them against a reference scope or a PoC. For context, fully in-house data preparation for a single complex conversion object can exceed 1,000 hours — see what Business Partner conversion costs when you do it yourself. The point is not that the AI is clever. It is that it moves the expert from typing rules to judging them.
AI pays off when it is governed
Governed AI compresses the timeline. Ungoverned AI moves the risk out of view. With the 2027 deadline in sight, the right move is to adopt it now — as a draftsman inside validation, approval and audit, never as a button.
See it on your own data
Bring one conversion object to a 30-day proof of concept: AI mapping and validation running inside full governance, and the effect on effort for that object, measured.