How should you migrate data to S/4HANA with the SAP Migration Cockpit?
The cockpit moves data reliably. It does not decide which data deserves to move.
The short answer
The SAP S/4HANA Migration Cockpit is SAP's standard tool for loading business data into a new S/4HANA system using predefined migration objects such as material, business partner, open purchase orders and balances. You choose a transfer approach (loading from files or staging tables, or pulling directly from a source SAP system, depending on your release), map and convert the data, simulate, and then migrate. It is usually enough for greenfield and selective-transition loads of standard objects, and it is not a substitute for data cleansing or for reconciliation. The tool moves what you give it; whether the result is correct is decided by your data-quality work before the load and your reconciliation after it.
What does the Migration Cockpit actually do?
The Migration Cockpit, delivered in S/4HANA as the Migrate Your Data app, is a project-based tool built around migration objects. Each object bundles the target structures, the mapping and conversion rules, and the load logic for one business entity, so you are not hand-writing BAPI calls or batch input for every table.
It succeeded the older LTMC transaction in current S/4HANA releases, so check which one your target release supports before you plan on either. For a standard object with a delivered template, it is the lowest-risk way to load data, because SAP maintains the object logic.
Which transfer approach should you choose?
The right approach depends on where the data lives and how much you need to reshape it on the way. Availability varies by release and deployment model, so confirm it in SAP's documentation for your version.
- Files: simple and transparent, good for small objects and manual mapping, but slow to iterate at volume.
- Staging tables: the better fit when you need to transform and cleanse data in a database before load, and when row counts are large.
- Direct transfer from a source SAP system: removes the extract step for supported objects, but it carries source-system dependencies and is only as good as the source data.
Where do cockpit-based migrations go wrong?
They rarely fail on the tool. They fail on scope and quality: duplicate business partners, materials with inconsistent units, open items nobody has reconciled, and custom fields that no delivered object covers. The simulation step catches format and consistency errors; it cannot tell you that a customer is a duplicate or that an open order should have been closed two years ago.
Custom objects are the second trap. If a business-critical Z-table has no delivered migration object, someone has to build one, and that effort belongs in the plan on day one, not in the cutover weekend.
How do you prove the migrated data is right?
Reconciliation is the control that matters. For every object, agree in advance what you will compare: record counts, control totals for balances, and a sampled business check such as an open sales order walking through to delivery in the new system. Run the full chain in at least one rehearsal, with timings, so the cutover plan is based on measurements.
This is where evidence from the source system helps. In a reference estate (a live ECC system analysed by our scanner), object-level usage data showed which tables and documents were actually active, which is the input to deciding what to migrate rather than migrate everything by default. A customer's numbers come from their own system.
Frequently asked
Is the Migration Cockpit enough for a brownfield conversion?
Generally no. A system conversion moves your existing data in place through SUM and the conversion tooling, so the cockpit's object loads are mainly for greenfield and selective-transition scenarios. Some conversions still use it for supplementary loads, so scope it explicitly.
Can an AI agent run the data migration?
Agents can help with profiling source data, proposing mappings and drafting reconciliation checks, and SAP has described agent-led migration tooling announced at Sapphire 2026 (SAP News). Loads into a target system should still go through your normal change and approval process, with a human accountable for sign-off.
How many mock loads should we plan?
Plan at least two full rehearsals before cutover, and more for large or complex estates. Each rehearsal should produce measured load times and a reconciliation report, so that the final cutover window is a prediction backed by evidence rather than an estimate.
See your own Clean Core Score.
Run the free S/4 readiness scan in under a minute — no system access required.
Keep reading