Skip to content

Solution · S/4HANA migration

You run the programme. We own the data track.

Eight governed steps from extract to post-load report, for every SAP object in the wave. AI drafts the field mapping, business users harmonise the values, every load is simulated before it is posted — through standard interfaces, never a direct table write.

Start a 30-day PoC on your data See vise DMW →
8 steps
extract to report, one platform
Since 2017
in production at a global brewing group
0
direct database writes
vise DMW validation history: invalid rows per validation run over the project window, with milestones
Validation progress over the project window — Nordic Rollout demo

01

What usually goes wrong.

01 The mapping lives in a spreadsheet Source-to-target rules in Excel, three versions in three inboxes, no record of who decided what. The mapping is the migration — and nobody owns it.
02 Load failures discovered late The first real load is the first real test. Every failed cycle costs a week of the cut-over plan and a weekend of the team.
03 Values that don’t exist in the target Payment terms, account groups, units and countries that were fine in ECC are not on the S/4 list. Harmonising them per country, by hand, is where programmes lose months.

02 · Which path, what it means for the data

Brownfield, greenfield or selective — the data track is different for each.

The conversion approach is the programme’s decision. What it means for the data is ours to make explicit, object by object, before the first wave is planned.

Brownfield · system conversion Clean in place before the conversion runs.
The data
The same records stay; what must change is their quality and the structures S/4 enforces — Business Partner and CVI, material-number length, FI/CO settings.
DMW steps
Extract → Validate → Profile → Report, with Value Map and correction loops run in ECC; FieldMap only for the structures that change.
Most of the work is data quality before the conversion: duplicates, CVI readiness, mandatory fields per BP role, values the S/4 customizing will not accept. The readiness score tells the programme when the data is fit to convert — and the correction loop runs in the source, not in a spreadsheet.
Greenfield · new implementation Migrate what is worth keeping — through all eight steps.
The data
A selected, cleansed subset of legacy data moves into a fresh S/4 client with new structures and new value lists.
DMW steps
All eight: Extract → Scope → Validate → Profile → Field Map → Value Map → Load Sim → Report.
Scoping decides what moves; FieldMap drafts the mapping to the new structures; LoV-MAP harmonises values to the new lists; every load is simulated against the new customizing before it is posted — through the loader you choose.
Selective data transition Both at once, decided per object and per site.
The data
Some company codes convert, some objects are re-implemented, history is cut at a date — each object follows its own path.
DMW steps
Brownfield steps for converted objects, greenfield steps for re-implemented ones, one readiness view across both.
The risk in a selective transition is losing track of which object follows which rule. vise DMW keeps one scorecard, one mapping repository and one audit trail across both paths, so the programme can defend every decision at cut-over.

03 · How it runs in vise DMW

The same discipline at every step.

  1. Steps 1–4 · Extract, scope, validate, profile

    Know what you are moving before you move it.

    Per-site extracts, scoped to the wave; validation rules per object; a DQ scorecard that tells the steering committee how ready each site is. Data gets corrected in the source — or, in a migration project, directly in DMW when that is the faster path — and re-validated.

    vise DMW DQ scorecard by dimension and object
    Readiness by dimension and object
  2. Step 5 · Field Map

    AI drafts the mapping. Your consultant approves every line.

    vise FieldMap proposes source-to-target field pairs and transformation rules with a confidence score, from your metadata. Target-driven view shows every mandatory field as mapped, defaulted, manual-load or unresolved. Every decision carries an owner and a date.

    Screens for this step come from the migration demo. Ask for a walkthrough, or see it on your own object in the 30-day PoC.
  3. Step 6 · Value Map

    Business users harmonise values once, for every site.

    Payment terms, account groups, countries, languages, reconciliation accounts, currencies: mapped in vise LoV-MAP by the people who know them, approved once, reused across waves. Dictionaries feed validation, so an unmapped value is caught before the load, not in it.

    vise LoV-MAP value mapping: source values mapped to target values with completion per table
    Value mapping in vise LoV-MAP (demo data)
  4. Step 7 · Load simulation

    Dry-run the load through the real interfaces.

    Every load is simulated against the target first — BAPI, IDoc or OData, the same path the real load takes. Errors come back per record with the reason; they go to the correction queue; the simulation is repeated until it is clean. Change mode updates what already exists instead of reloading everything.

    Screens for this step come from the migration demo. Ask for a walkthrough, or see it on your own object in the 30-day PoC.
  5. Step 8 · Report

    Post-load reconciliation your auditors will accept.

    What was extracted, what was transformed, what was posted, what failed and why — per object, per site, per run. Plus the weekly summary and cleansing progress the programme manager has been sending since step 1.

    vise DMW cleansing progress per operating company
    Cleansing progress per operating company

04 · 30-day proof of concept

What you have after 30 days.

  • One object from your system: extracted, profiled, validated, field-mapped and value-mapped
  • A load simulation against your target (or your load tool) with the error list and the fixes
  • A data assessment report and a working DMW project — the start of the data track, not a demo
  • An effort estimate for the full wave, by object and site
How the PoC and the licence work

In production

SAP → Navision, now Business Central → S/4HANA Karlsberg Customer and BOM data cleansed, deduplicated and transformed for the Navision move by one specialist instead of five; rules from the German entity reused for the French one. Today: the first production customer of vise FieldMap, mapping material data for the move to S/4HANA. Read more Rollout waves since 2017 Global brewing group vise DMW as the data readiness gate in front of BODS for each SAP rollout across the group’s operating companies, and vise Data Run for the everyday changes after go-live. Read more

05 · FAQ

Straight answers, the same in every review.

For SAP architects
01What about SAP Migration Cockpit?
Use it if it fits. DMW adds change mode, load simulation, rule-based validation and a correction loop for business users — and can feed the Cockpit or BODS instead of loading itself.
02How does DMW post into S/4HANA?
Standard BAPIs, IDocs and OData only. Never a direct table write. Business Partner goes through CVI like any SAP-approved tool.
03Which objects?
Any: customer, vendor, business partner, material, BOM, open items, GL accounts, cost centres, plant maintenance, assets. The rule library and the mapping are per object; the platform is the same.
04How do you work with our system integrator?
We own the data track and hand the integrator clean, mapped, simulated data on the agreed dates. Your IT runs DMW, we run it for you under SLA, or hybrid with a Visehub specialist embedded in the team.

Start the data track with one object, in 30 days.

Customer or customer or vendor master is the usual pick. We extract it, validate it, map it and simulate the load — and you see what the full wave will take.

Start a 30-day PoC Watch the demo