Guides
The concepts, explained in one page each.
Definition first, then what goes wrong, then how it is done in practice. Written by the people who run it in production; updated when the practice changes.
Start here · three guides, in order 9 guides · updated Nov 2026
- 01 What is SAP data migration? SAP data migration is the controlled transfer of master and transactional data from a legacy system into an SAP target (typically SAP ECC → S/4HANA, or another ERP → SAP), executed as a sequence of governed steps: extract, scope, validate, profile, map fields, map values, simulate the load, load through standard interfaces and reconcile.
- 02 SAP Migration Cockpit vs a data migration workbench SAP Migration Cockpit is SAP's standard tool for loading data into S/4HANA via predefined migration objects; it validates what SAP will accept (formats, mandatory fields, customizing).
- 03 S/4HANA Business Partner conversion (CVI) explained In SAP S/4HANA, customers and vendors are no longer separate master objects: every one of them must be represented as a Business Partner (BP) with roles such as FLCU01 (customer) and FLVN01 (vendor).
01
Migration
What the data track is, how SAP’s own tooling fits, and the objects that decide the schedule.
01 Start here What is SAP data migration? SAP data migration is the controlled transfer of master and transactional data from a legacy system into an SAP target (typically SAP ECC → S/4HANA, or another ERP → SAP), executed as a sequence of governed steps: extract, scope, validate, profile, map fields, map values, simulate the load, load through standard interfaces and reconcile. It is a data track that runs alongside the system implementation and is usually the reason programmes slip. Updated 3 Nov 2026 Read 02 SAP Migration Cockpit vs a data migration workbench SAP Migration Cockpit is SAP's standard tool for loading data into S/4HANA via predefined migration objects; it validates what SAP will accept (formats, mandatory fields, customizing). A data migration workbench adds the layer before and around the load: profiling, business-rule validation, field and value mapping, load simulation against your customizing, a correction loop for business users, change mode for existing records, and an audit trail across all of it. The two are complementary — the workbench can deliver pre-validated files to the Cockpit or load through BAPI, IDoc and OData itself. Updated 3 Nov 2026 Read 03 S/4HANA Business Partner conversion (CVI) explained In SAP S/4HANA, customers and vendors are no longer separate master objects: every one of them must be represented as a Business Partner (BP) with roles such as FLCU01 (customer) and FLVN01 (vendor). Customer Vendor Integration (CVI) is the SAP mechanism that creates and synchronises the BP with the underlying customer and vendor records. In a brownfield migration CVI must be active before any record can enter S/4HANA, and converting ~100,000 customer and vendor records by hand typically takes 800–1,000+ hours. Updated 3 Nov 2026 Read 04 SAP ECC → Business Central migration: the data track In an SAP ECC → Dynamics 365 Business Central migration the system implementation is done by a BC partner; the data track — extracting, profiling, validating, mapping and simulating the data before the partner loads it — is a separate job that decides whether the programme lands. Run as four gates, it typically cuts test migrations from five or six to one or two, and the validation rules built for it keep working in Business Central after go-live. Updated 3 Nov 2026 Read 05 Decommissioning SAP ECC: what history to keep Decommissioning SAP ECC means switching the legacy system off after go-live on the new ERP without losing the history that audit, tax, legal retention and reporting still require. The practical approach is retain → report → decommission: extract and validate only the records that must be kept (financial documents, master data, the audit trail) into a structured archive, keep that archive queryable for on-demand historical reports, then shut ECC down and stop paying for licences, infrastructure and maintenance. Updated 3 Nov 2026 Read
02
Data quality & governance
One number for readiness, and the control that keeps everyday changes safe.
01 Data quality before SAP go-live: the readiness score A data readiness score is a single, weekly-published measure per site and programme — the share of records that pass the validation rules the business has agreed on — built from five data-quality dimensions (completeness, validity, conformity, consistency, uniqueness) applied per SAP object. It replaces fragmented Excel trackers with one answer to 'are we ready?', tells business owners exactly what to fix (in the source system), and shows the trend since the baseline. Updated 3 Nov 2026 Read 02 Four-eyes approval for ERP data changes Four-eyes approval (the four-eyes principle) is a control under which a second, named person approves a data change, or its execution in the target system, independently of the person who prepared it. For ERP master-data changes it is implemented as a role-based workflow — requester, data owner, validator, executor, admin — where nothing is posted without an approval that carries a user and a time, and where validation and a dry run happen before the approver ever sees the request. Updated 3 Nov 2026 Read
03
Mapping
Fields and values: where AI helps, and where a spreadsheet stops being safe.
01 AI field mapping with human approval AI field mapping is the use of a model to draft source-to-target field pairs and transformation rules from system metadata and plain-language descriptions, each proposal carrying a confidence score and a rationale (semantic fit, type compatibility, length, value distribution). Used safely, every draft passes a sandbox test, a named human approval, versioning and an audit trail before it is loaded — cutting the mechanical mapping effort for a complex conversion object from about 30 expert-days to about 12 without loosening governance. Updated 3 Nov 2026 Read 02 What is value harmonisation (LoV mapping)? Value harmonisation (list-of-values mapping, LoV mapping) maps the reference values used in source systems — payment terms, account groups, countries, currencies, units, plants, storage locations, chart-of-accounts entries — to the values the target system allows, so that every record loads with a valid value and every site uses the same ones. It is step 6 of a migration and a standing task in BAU master-data governance; done in spreadsheets it is one of the most fragile parts of a programme, because real mappings depend on combinations of keys. Updated 3 Nov 2026 Read
Three ways to learn. Pick the depth you need.
- Learn the terms Glossary One-line definitions of the words used across this site, each linked to the page that goes deeper. Open the glossary →
- Read the guides · You are here 9 guides Answer-first explanations of the concepts: migration, data quality, mapping. Short enough to read before a meeting.
- See field notes 6 posts What we learn on migrations, data-quality programmes and everyday data operations — with the numbers. Read the blog →
A question the guides do not answer?
Ask it. If it comes up twice, it becomes the next guide — and you get the answer either way.