SAP S/4HANA Migration Cockpit: strengths and limitations

If you're moving onto SAP S/4HANA, the Migration Cockpit is the tool SAP wants you to use. It's the successor to the old LSMW, delivered through the Fiori app Migrate Your Data, and it comes with hundreds of predefined migration objects – customers, suppliers, materials, open items and so on – complete with field mapping and validation built in.

It's genuinely useful. But it's a loading framework, not a magic wand: it solves the transport of data, not the quality of it. Here's an honest look at what it does well and where it stops. Everything below reflects the cockpit as of SAP S/4HANA 2025.

Two ways to migrate

The cockpit gives you two approaches, and choosing the right one up front matters.

1. Migrate data using staging tables

Staging tables are the flexible option. The cockpit creates a set of staging tables – technically named /1LT/DS… – and you fill them with your source data before it transfers them into S/4HANA. The tables can live in two places:

• Local SAP S/4HANA database schema – the cockpit generates the tables in the internal ABAP schema of the target system.
• Remote SAP HANA database schema – a dedicated schema, optionally on a separate tenant, connected via DBCO. This is what lets a third-party ETL tool write to the tables directly. (SAP restricts that schema to migration use only.)

You can populate the tables two ways:

• Upload the template files the cockpit generates per migration object. The default and recommended format is XML (a single Excel 2003 XML workbook per object, with one sheet per data structure); CSV is supported but treated as an expert option (RFC 4180, UTF-8, one file per data structure).
• Populate the staging tables directly – with SQL, an ETL tool such as SAP Data Services, or your own scripts. If you load tables this way, run the cockpit's consistency check yourself; file uploads get that check automatically, direct loads don't.

Once the tables are filled, the cockpit handles mapping, simulation, validation and the actual transfer into S/4HANA.

Strengths: handles large volumes far better than file upload, lets you prepare and cleanse data with your own tooling before it ever touches SAP, and supports an iterative "fill → simulate → fix → reload" rhythm. This is my default for any non-trivial migration.

Limitations: you need database access and someone comfortable with SQL/ETL to populate the tables; it's more setup than the direct approach. Watch the practical edges too – the Excel template tops out at 15 digits per numeric field, and uploaded files have size limits (100 MB per XML file, 100 MB per zip).

2. Migrate data directly from an SAP system

The direct approach reads data straight from a source SAP system over an RFC connection – no spreadsheets, no manual file prep. You pick the migration objects, set selection criteria (typically organizational units like company codes), and the cockpit extracts and transfers in one flow. The source can even be non-Unicode; the conversion to the S/4HANA data model happens automatically on load.

It only works for specific, supported source scenarios, each with a minimum release:

• SAP ERP / ECC → S/4HANA (ERP 6.0 / NetWeaver 7.0 and up)
• SAP Apparel and Footwear (AFS) → S/4HANA (AFS 6.0)
• SAP EWM → decentralized EWM (EWM 5.1)
• SAP CRM → S/4HANA for Customer Management (CRM 7.0)
• SAP APO SPP → eSPP (SCM 7.14)

You can't use another S/4HANA system as a source, and the source needs the DMIS add-on installed at a compatible version.

Strengths: minimal setup, no manual data preparation, and SAP-to-SAP field knowledge is baked into the predefined objects. When your source is SAP and the data is already reasonably clean, this is the fastest path. You can also opt to route a direct-transfer project through staging tables as intermediate storage if you want a place to inspect or adjust the data mid-flight.

Limitations: it only works from supported SAP source systems, and you're bound to the predefined extraction logic and selection options. There's far less room to transform or cleanse data on the way – what's in the source is largely what you get. A project is tied to one source system; switching sources means a new (or copied) project.

The project lifecycle teams underestimate

This isn't in the marketing material, but it shapes your timeline. Migration projects can only be created in a development system, then transported – dev → test → production – via the Migration Object Modeler (LTMOM). A few consequences worth planning for:

• The development package must use a Y/Z prefix; a local $TMP package can't be transported.
• You'll typically run several test cycles, each in a fresh copy of production, before the production load. Each cycle gets its own project carrying forward the previous corrections.
• Mapping values aren't transported with the project definition – but you can download mapping values from one cycle and upload them into the next, so you don't re-map from scratch every round.
• After an S/4HANA release upgrade, SAP recommends building new projects rather than reusing old ones.

Budget for the iteration, not just the final load.

What the cockpit does well

• Predefined content. Hundreds of ready migration objects with field mappings and checks – you're not building from scratch.
• Mapping and value mapping. Resolve value mapping tasks (legacy value → S/4HANA value) and fixed value tasks (defaults) centrally, and reuse them.
• Simulation and validation. Simulate transfers and clear errors before committing real data. Messages are typed (error / warning / success / info) and kept for 180 days.
• Dependency awareness. Objects know their predecessors; the Sequence Information view and the Explore Migration Objects app help you load things in the right order.
• Parallelism. Job Management lets you tune background jobs (15 by default) per project and per object to push volume.
• No ABAP for standard objects. Business-led migration is realistic for the standard scope.

Where it stops – and you take over

This is the part teams underestimate. The cockpit will load whatever you give it; it won't tell you that the data was wrong to begin with.

• Data quality is still on you. Profiling, deduplication and defining "good enough" happen before the cockpit – ideally during discovery, not at load time.
• Custom objects and fields need work in the Migration Object Modeler (LTMOM) – custom migration objects, Check for Custom Fields on standard objects, and your own source-code rules (which require extra S_DEVELOP authorizations). Anything beyond standard takes real effort.
• It's not a full ETL tool. Heavy transformation, complex business rules and cross-object logic are better handled upstream.
• Reconciliation is yours. The cockpit confirms a load succeeded technically; proving the migrated data matches the source – counts, totals, sign-off – is still a separate, manual discipline.
• Delta handling is limited. Plan cutover sequencing (bulk vs delta) deliberately; don't expect the tool to manage it for you.
• Compliance is yours. Migrating personal data that should have been deleted can itself be unlawful processing. The cockpit offers a data-retention period on finished projects, but deciding what may move is your call.

Worth knowing before you start

A short practitioner checklist that saves grief later:

• Authorizations. Transferring data needs role SAP_CA_DMC_MC_USER (plus SAP_BR_CONFIG_EXPERT_DATA_MIG on the front end); LTMOM work needs SAP_CA_DMC_MC_DEVELOPER; direct transfer needs an RFC user with SAP_DMIS_MC_DT_REMOTE in the source.
• Note Analyzer. Run transaction CNV_NA_MC (SAP Note 3016862) regularly to confirm the relevant correction notes are in place – the cockpit and its DMIS components move quickly.
• Projects live in dev. You can't create them in QA or production systems.

In summary

The Migration Cockpit is the right tool for loading data into S/4HANA, and the choice between staging tables (flexible, volume-friendly, your own prep) and direct transfer (fast, SAP-to-SAP, less control) should be a conscious one. But the cockpit is the last mile. The work that decides whether your migration succeeds – understanding the source, fixing quality, defining scope and reconciling the result – sits firmly outside the tool.

Planning an S/4HANA move and weighing staging vs direct transfer? Get in touch – I'm happy to share how I work.

---

Reference: the official SAP Help Portal documentation this article draws on is available here as a PDF — SAP S/4HANA Migration Cockpit – Data Migration (2025 FPS01).