SAP Migration Cockpit Data Preparation: A Field Guide

The SAP S/4HANA Migration Cockpit is a well-behaved piece of software. Point it at clean data and it loads. Most of the pain teams report during an ECC to S/4HANA cutover — the error list at simulation, the third and fourth reload cycles, the rehearsal weekend that becomes two — comes from what was handed to it, not from the tool.

This guide covers Migration Cockpit data preparation — the master data work that happens before the first staging table is populated: what “Migration Cockpit-ready” concretely means, and five practices that get a load through simulation without a rework loop. For the wider programme view — why data debt accumulates and when to start — read our ECC to S/4HANA data migration best practices guide. This one stays on the last mile.

Why Migration Cockpit loads fail

The Cockpit validates on the way in, at three checkpoints: structure when you populate the staging tables, business rules at simulation, and again at the migration run. Errors come back at row level, which is useful — and also why a bad extract produces a spreadsheet of thousands of messages instead of one clear problem.

The failure modes are boringly consistent:

• Mandatory in the target, optional in the source. A field nobody filled in for fifteen years because ECC configuration never required it, which the target model does.
• Values that resolve nowhere. Country, region, tax category, unit of measure, language key — codes that were valid in the legacy client, referenced by master data, and absent from the target’s check tables.
• Format drift. Dates in three formats across one file, decimals with the wrong separator, account numbers whose leading zeros were stripped by a spreadsheet round-trip.
• Dependency violations. An object referencing something that has not been loaded yet.
• Duplicates. Two source rows collapsing onto one target key, or a “new” record that already exists under a slightly different name.

None of these are Cockpit defects, and none of them need the Cockpit to be found. Every one is detectable in the extract, on your side of the fence, weeks before a staging table exists. That timing is the whole argument: the same error costs minutes to fix during preparation, hours at simulation, and negotiating-with-the-business days during cutover rehearsal.

What “Migration Cockpit-ready” actually means

Three properties, and a file needs all three.

The right shape

Migration objects ship with template structures, and the template is the contract. For customers and suppliers on recent releases these are the CUSTOMER_2 and VENDOR_2 template generations.

The distinction that saves the most rework: the sheets inside a template are template structures, not ECC tables. Your customer data comes out of KNA1, KNB1 and KNVV. It goes into structures like S_CUST_GEN, S_CUST_COMPANY, S_CUST_SALES_DATA, S_CUST_BANK_DATA and S_CUST_TAXNUMBERS. The two decompositions are related but not the same, and they do not split the record along the same seams. Some structure names make the trap worse by looking almost identical to the source — the bank template’s S_BNKA against ECC’s BNKA — which invites a one-to-one column copy that then fails on the fields the template added or dropped.

Download the template from the target system at the target release, read its field list and mandatory flags, and treat that as the spec. Field lists move between releases; a template from the last project is not evidence.

Custom fields need a decision rather than a default. Every Z-field in the extract has to be consciously mapped to a target field, carried as an extension, or dropped — and “we will deal with the Z-fields later” is a reliable way to earn another load cycle.

The right values

Every coded field has to resolve in the target client. A large share of any error list comes from here, because configuration and master data are usually migrated by different people on different schedules. Configuration lands first and looks complete; the master data still referencing codes that configuration dropped is nobody’s finding until the load runs.

The right order

Dependencies are constraints, not preferences, and they stack in three levels:

1. Foundational — bank master records, and GL accounts (which need the operating chart of accounts and company code in place).
2. Organizational — cost centers and profit centers, which depend on the GL and company code above them.
3. Master data — fixed assets, customers and suppliers, products; each referencing the two levels below.

The consequence is concrete rather than theoretical: load customers before the bank master and the Cockpit rejects the rows with “Bank key does not exist.” Sequence the objects before you build anything, because a load order discovered halfway through is a load order you will re-run.

The SAP Help Portal carries the per-object template and prerequisite detail for your release. The practices below are about what you do with it.

Profile the full extract, not a sample

Test loads use hand-picked samples, and hand-picked samples behave. The full extract is where the two thousand records with a blank country live, along with the vendor created in 1998 whose tax number is a phone number. Profile completeness, validity and uniqueness per field across one hundred percent of rows before writing a single mapping rule, and record the baseline error count — you need a number to measure corrections against.

Teams skip this because it feels like it should be slow. It should not be. S4Ready profiles uploaded extracts per object — Bank, Customer, Supplier, GL Account, Cost Center, Profit Center, Fixed Asset and Product — as a batch job; customer and supplier sets of 100,000 rows are profiled and validated in minutes through columnar processing.

Getting the data out of ECC is its own problem. S4Ready ships a Windows desktop Agent that extracts over RFC, reading the source tables per object — BNKA and its configuration tables for banks, KNA1/KNB1/KNVV for customers, LFA1/LFB1/LFM1 for suppliers — and packaging them with a manifest for upload. Extraction is scoped by the company codes and organizational units actually in play rather than pulling everything, and the same run can connect to the S/4HANA target and pull its reference data — which is what turns “check every coded value against the target” from a principle into something you can run before the target has seen a single row. The SAP ECC data extraction guide walks through the options, including which extraction method to choose when Basis constrains what you can install.

Validate against target rules before you map, not after

The common sequence is to map first and discover afterwards that the target rejects the mapped result. Invert it. Run target-shaped validation against the source, so mapping decisions get made with the error list already in hand rather than as a hypothesis to be tested at simulation.

For that to hold up over a months-long project, the rules themselves need properties:

• Catalogued, not buried in scripts. The functional lead who knows why a tax field behaves differently in Türkiye should be able to read the rule and disagree with it.
• Graded by severity. Blocking and advisory are different conversations; mixing them produces an error list nobody triages.
• Re-runnable. The delta between two runs is the only honest progress metric a data workstream has.

S4Ready keeps around 150 validation rules in YAML catalogs, split per object, for exactly this reason — a rule is readable and diffable rather than archaeological. Each carries a severity, the fields it applies to, the message it raises, and optionally a suggested fix that the grid can apply. They run at the level of detail the target actually checks at: BANK_COUNTRY_MANDATORY requires a valid ISO 3166-1 alpha-2 country on every bank record, and BANK_IBAN_COUNTRY_MATCH cross-checks that the IBAN’s first two characters agree with it — the kind of internal contradiction that passes a not-null check and fails a load.

Mapping runs alongside this: ECC fields are bound to the Migration Cockpit templates automatically, and each custom Z-field is surfaced for an explicit Map, Extend or Drop decision rather than being quietly left out of the export.

Deduplicate with evidence, not with a merge button

Deduplication is where migrations get politically hard, because merging two customers is a business decision with credit management, open items and reporting history attached. A tool that announces “412 duplicate pairs found, click merge” does not survive the first meeting with the AR lead, and it should not.

The approach that holds up is two-layer:

1. Deterministic keys for the unambiguous cases — same tax ID and country, exact normalized name plus postcode. These are decidable without a meeting.
2. Probabilistic matching for everything else, producing scored candidate clusters, each carrying the field-level evidence that produced the score.

A reviewer then works clusters rather than pairs, and accepts or rejects with that evidence in view. S4Ready implements both layers and leaves clusters in a pending state until somebody decides — nothing auto-merges. Each pair has an explain card showing the match probability, the match weight, and which individual signals contributed, and that card exports as a file you can attach to the decision. Clusters left unreviewed block the export, so “we’ll come back to the duplicates” cannot quietly become “we shipped the duplicates.”

The deliverable at the end of dedupe is not only a deduplicated file. It is the record of which merges were decided, by whom, on what basis — which is what answers the audit question six months later.

Govern corrections so they survive a re-extract

Master data cleansing fails on process long before it fails on technique. The anti-pattern is the emailed spreadsheet: corrections in XLSX_v14_final have no history, no ownership and no re-validation path — and the moment a fresh extract lands, they are gone and the work is repeated.

What holds up instead:

• Corrections stored as patches against the source rather than overwriting it, so applying them produces a new dataset version and the source stays intact. A re-extract can then have the same decisions re-applied instead of re-made.
• Bulk application for systematic problems. One country-code correction across three thousand rows is one decision, not three thousand.
• An audit trail per cell — what changed, who changed it, when.
• A gate at the end that a named person passes through.

In S4Ready this is the Quick Fix Grid: validation feedback sits next to the row that failed, fixes apply cell by cell or across a whole field at once, and every edit is held as a pending patch until it is applied into a new version, with per-cell history retained.

Sign-off is two-tier — General and Company Code — so the owner of the data globally and the owner for a given company code both sign, and the person who prepared a record cannot approve their own work. Approvals are pinned to the exact content they approved, which means a later edit invalidates them rather than silently inheriting the signature.

The gate itself is a mode decision, taken per project rather than per install. The same workflow runs in Pilot, which keeps approvals flexible while you are still discovering and cleansing, and in Governed, which requires them for rehearsal and production loads. In Governed mode exports stay blocked until the gates pass. An override exists for the cutover-weekend emergency, but it requires a recorded justification and lands in the audit trail as an override rather than as an approval. That distinction is the point — the gate is enforced by the workflow, and stepping around it leaves a mark.

Export in the shape the Cockpit expects

The last mile is mechanical and still goes wrong. A renamed sheet, a missing header row, a reordered column, dates written as serial numbers, leading zeros gone because a spreadsheet decided an account number was a number.

Generate the file from the template contract rather than hand-editing a workbook, and keep the evidence with the data. S4Ready exports Migration Cockpit bundles as CSV or Excel 2003 XML, and the bundle is more than the data file: a README recording object, template, source version and approvals; a checksum file; a manifest; mapping notes where a mapping spec exists; and the record of the disposition and duplicate decisions that produced this extract. If the README cannot be generated, the export aborts rather than shipping a bundle nobody can trace.

That matters at exactly one moment, and it is a bad moment to improvise: during cutover rehearsal, when somebody asks which version of this file was signed off, the answer should be in the bundle.

A Migration Cockpit data preparation sequence you can run

1. Extract complete data sets per object. Not samples.
2. Profile completeness, validity and uniqueness. Record the baseline error count.
3. Pull the migration object templates from the target system at the target release. Confirm field lists and mandatory flags against that download, not against the last project.
4. Validate the source against target rules. Sort by blocking severity.
5. Dedupe with evidence. Get business decisions on the clusters, recorded.
6. Correct in a governed grid. Re-validate. Watch the error count fall.
7. Approve — general owner, then company code owner.
8. Export the bundle, populate staging, simulate.
9. Fold the simulation errors back into step 4.

Steps 4 through 7 are a loop, and running that loop early and often is the whole method. The target state is that step 9 finds nothing you have not already seen.

Where S4Ready fits

S4Ready is built for this stretch specifically — after the extract, before the Cockpit. It profiles, validates, auto-repairs and deduplicates legacy master data across the eight objects above, runs corrections through a governed grid with two-tier approvals, and exports Migration Cockpit-ready bundles with their evidence attached. It installs as a customer-managed server on your own infrastructure or private cloud, which matters for this particular workload: master data is where the bank details, tax numbers and personal data live, and here it never leaves your organisation. The interface is available in English, German, Spanish, Italian and Turkish. Deeper detail lives in the product documentation and the master data migration best practices guide.

If you are scoping the data workstream for a cutover, see how the S4Ready preparation workflow is put together, or run the whole sequence against synthetic data in the hosted demo — no install, no production system involved.