What is SAP data migration?

Definition

SAP data migration is the controlled transfer of business data from one or more source systems into an SAP target — most often from SAP ECC to SAP S/4HANA, but also from non-SAP ERPs, files and legacy databases into SAP, or from SAP into another platform such as Microsoft Dynamics 365 Business Central. It covers everything between “the data exists in the old system” and “the new system runs on it”: selection, cleansing, transformation, loading and proof that the result is complete and correct.

Done well, it is a data track with its own owner, plan and gates, running alongside the system implementation. Done badly, it is a spreadsheet exercise discovered late, and the most common reason an ERP go-live slips.

What it covers

A governed migration runs as a sequence of steps, each removing one class of error before the next:

1. Extract — pull the data from the source, versioned, for every object in scope.
2. Scope — decide which records travel: active partners, open items, agreed periods. The whole legacy database rarely should.
3. Validate — check every record against rules: format, mandatory fields, lists of values, cross-field and cross-object consistency, and the business rules SAP does not know.
4. Profile — measure completeness, validity, conformity, consistency and uniqueness per object; publish a readiness score per site.
5. Field map — define source-to-target field pairs and transformation rules. This is the specification the migration lives by.
6. Value map — harmonise lists of values: payment terms, account groups, countries, currencies, units.
7. Load simulation — dry-run the load against the target through the real interface; fix what fails; repeat until clean.
8. Report — post-load reconciliation: what was extracted, transformed, posted, rejected and why.

These are the eight steps of vise DMW; other tools cut the list differently, but every serious programme has to do all eight.

What usually goes wrong

• The mapping lives in a spreadsheet. No validation, no dependency checks, three versions in three inboxes.
• Errors are found at load time. The first real load is the first real test; every failed cycle costs a week of the cut-over plan.
• Values that do not exist in the target. Payment terms, account groups and units that were fine in ECC are not on the S/4HANA list.
• Business owners cannot see what to fix. Error logs are written for developers; the person who can correct a vendor never gets a list they can act on.
• Direct table writes. Tempting under pressure; they bypass CVI, number ranges, customizing checks and change documents, and they break audits.

How a governed data track is run

Three principles separate migrations that land from migrations that slip. Rules as code with owners: validation rules are small, versioned functions with a scope, a severity and a named owner, run on every record, not a checklist in a document. Simulation before every load: the load is dry-run through the real interface, errors go to a correction queue, and the real load happens only when the simulation is clean. Standard interfaces only: BAPI, IDoc, OData or Migration Cockpit, never a direct database write, so SAP’s own integrity model stays switched on.

AI now drafts the slowest parts — field mappings, transformation rules, validation rules — but only inside that loop: every draft is tested in a sandbox and approved by a person before it runs. See AI field mapping with human approval.

Where Visehub fits

Visehub runs the data track as a service with its own platform, vise DMW, and specialists who have done it in production since 2017 at a global brewing group. The usual start is a 30-day proof of concept on one object — vendor master, most often — which produces a readiness score, a mapping, a load simulation and a reliable estimate for the rest.