The SAP S/4HANA migration cockpit

The SAP S/4HANA migration cockpit is SAP's standard tool for the initial transfer of master data and transactional data into a new S/4HANA environment. The current experience is the Migrate Your Data - Migration Cockpit Fiori app, ID F3473.

This SAP data migration cockpit organizes the work through migration projects, SAP migration objects, mapping tasks, staging structures and controlled load steps. Depending on the edition and release, teams can migrate through files, staging tables or direct transfer from a supported SAP source system.

This practical SAP Migration Cockpit guide explains how the tools relate, how the three transfer routes work, how objects and staging tables are structured, and how experienced projects plan sequencing, reconciliation and mock loads. It also covers LTMC, LTMOM, the migration object modeler and the operational data work that continues after cutover. For every object, teams must confirm the supported edition, release and transfer route, not just whether the object appears in a list.

Free SAP migration planning templates

These free Excel templates help teams plan an SAP S/4HANA migration cockpit project. They are provided by PostNow.ai, and every field maps to a structure and field verified against the SAP dictionary.

Migration object load sequence planner

Tracks each object, wave, prerequisite, owner, volume and mock result through cutover. The Depends On column earns its keep because a dependency discovered during execution usually creates a re-run.

Migration object load sequence plannersap-migration-object-load-sequence-planner.xlsxDownload

Migration object field mapping tracker

Connects source fields to target structures, transformations and value mappings. The Mapping Task Confirmed column exists because an unconfirmed task can trigger DMC_RT_MSG 93 during preparation.

Migration object field mapping trackersap-migration-object-field-mapping-tracker.xlsxDownload

Cutover data readiness checklist

Records source sign-off, duplicate checks, target reference validation, leading zeros, number-range decisions, mock-load results and agreed reconciliation counts for every object.

Cutover data readiness checklistsap-cutover-data-readiness-checklist.xlsxDownload

Beyond planning, PostNow.ai publishes 75 free SAP upload templates covering the objects a migration actually loads: material master, bills of material, classification, cost centres, assets, purchase orders, sales orders and goods movements. Each names the SAP interface it posts through and maps every column to its structure and field. Browse the library at PostNow.ai SAP upload templates, or start with the 24 master data templates.

Where PostNow.ai fits alongside the migration cockpit

PostNow.ai is an Excel add-in and web portal that posts data into SAP ECC and S/4HANA through standard SAP BAPIs, validates each row before posting and returns SAP document numbers. It appears here because migration programs need both a controlled cutover tool and a practical plan for preparing data and handling operational loads.

The SAP S/4HANA migration cockpit remains SAP's tool for the cutover load. This product does not replace it.

On a migration project, the Excel workflow can be used before the cockpit to identify mapping, formatting and reference-data issues while the data is still being prepared. It can also help teams shape spreadsheet data into the structures and field formats expected by migration cockpit templates or staging-table processes. After go-live, it supports ongoing posting work that belongs outside the one-time cutover load.

What the SAP migration cockpit is

As the standard SAP data migration tool for S/4HANA, the SAP migration cockpit controls the initial loading of supported business objects. It organizes migration work through SAP migration objects, mapping tasks, staging structures and controlled load steps. Object availability and supported transfer methods vary by S/4HANA edition and release.

How does SAP Migration Cockpit work?

The SAP data migration cockpit uses migration objects to create records in the target S/4HANA system. Teams prepare the source data, complete and confirm the required mappings, execute the applicable load steps and reconcile the resulting target records.

This is the practical meaning of migrate your data in the cockpit. The migration object defines the structures, mappings and processing for a supported business object. Confirm both object availability and transfer-method support for the project's exact edition and release.

The SAP migration cockpit step by step

Used as a tutorial, a migration cockpit run follows the same shape every time: select the migration object, download or map the template, upload the data, run the value mappings, simulate, then migrate. Each phase has to complete before the next becomes available, which is why an unconfirmed mapping task blocks the whole run rather than failing one record.

LTMC, LTMOM and Migrate Your Data: how the tools relate

LTMC, LTMOM and the Migrate Your Data app are related but serve different purposes. LTMC launches the older Web Dynpro cockpit, LTMOM models migration objects, and the Migrate Your Data Fiori app is the current migration cockpit Fiori app experience.

What is LTMC in SAP?

The LTMC transaction launches the Web Dynpro implementation called Migrate your Data - Migration Cockpit (Old). SAP KBA 2988692 distinguishes this implementation from the current Fiori version.

LTMC is deprecated, but published sources differ on whether the practical release boundary should be described as S/4HANA 2020 or 2021. Teams should check SAP KBA 3355075 against their exact release instead of applying one universal cutoff. For S/4HANA Cloud Public Edition 2105 onward, the old app cannot be used for new migration projects, although existing projects remain viewable.

What is LTMOM in SAP?

LTMOM is the migration object modeler for on-premise and Cloud Private Edition, and it was not deprecated with LTMC. It remains the modeling environment for migration projects created through the current Fiori app.

Cloud Public Edition does not provide the LTMOM transaction. Its corresponding Fiori experience is Model Your Migration Objects - Migration Object Modeler. This distinction matters because teams sometimes treat the retirement of the old cockpit interface as the retirement of the modeling capability.

How LSMW relates to the current cockpit

LSMW remains technically present in S/4HANA on-premise but is classified for restricted use and receives no functional development under SAP Note 2287723. Batch-input recordings do not work with Fiori screens, and recordings based on older customer and vendor master transactions were affected by Business Partner conversion.

The useful comparison in SAP migration cockpit vs LSMW is therefore one of supported project design. The migration cockpit is SAP's recommended initial-load tool for S/4HANA, while existing LSMW content must be assessed against the current target process and interface.

The current status of the tool, its 14 steps and the objects that fail after a conversion are covered in LSMW in S/4HANA.

The three ways data gets into S/4HANA

The SAP S/4HANA migration cockpit presents three transfer options: files, staging tables and direct transfer. In the current Fiori app, uploaded files ultimately populate staging tables, so the three user-facing options rely on two underlying mechanisms.

SAP migration cockpit file upload

The file approach lets the team download an SAP migration cockpit template, populate it and upload it to the project. It is supported for on-premise, Cloud Private Edition and Cloud Public Edition.

For S/4HANA on-premise, the XML file limit is 100 MB by default, with the literal system message stating that each file must be smaller than 100 megabytes. SAP KBA 2719524 documents that the limit can be raised to 160 MB by parameter. For Cloud Public Edition, the limit is 100 MB per XML file and 100 MB for the zip, while release 2602 raises the per-XML limit inside the zip to 400 MB, according to SAP KBA 3691273.

Migration cockpit staging tables

The staging-table route lets XML files or an ETL process populate generated SAP staging tables. It is available for on-premise from 1709 FPS01 and is also supported in Cloud Private Edition and Cloud Public Edition.

This route suits programs that already have a repeatable extraction, transformation and loading process. The migration cockpit still owns the migration object and target processing, while the upstream pipeline owns the controlled preparation and population of source records.

SAP migration cockpit direct transfer

Direct transfer connects the target to a supported SAP source system through RFC and selects source data for migration. It is available for on-premise from 2020, for Cloud Private Edition, and for Cloud Public Edition from 2402.

Supported scenarios include SAP ERP to SAP S/4HANA, SAP Apparel and Footwear (AFS) to SAP S/4HANA, and SAP EWM to Decentralized EWM. For an SAP ERP source, the minimum release is SAP ERP 6.0 with Unicode enabled. Direct transfer requires an RFC connection from the target system to the source system.

Migration objects and how coverage works

An SAP migration object packages the source structures, target structures, mappings and processing needed for a defined business object. Coverage must be checked as a matrix of object, transfer method, edition and release.

SAP provides several hundred S/4HANA migration objects (often searched as S4HANA migration objects), but no single count is reliable across editions, releases and transfer methods. Use SAP's live available migration objects list and data migration landing page instead of copying a static SAP migration objects list into project documentation.

Custom objects and extensions

On-premise and Cloud Private Edition allow a SAP migration cockpit custom object to be built in LTMOM. Cloud Public Edition does not permit creation of custom migration objects. This is a key difference between the SAP Migration Cockpit on premise and SAP Migration Cockpit Public Cloud models. Only SAP-released migration objects can be enhanced, and the applicable per-object SAP Notes define which structures and fields are extensible.

Fields created in the Custom Fields app can be used in Public Cloud when they are published for other applications or APIs and the migration object is updated. Not every object supports custom fields, so SAP KBA 2978407 should be used to confirm support for the selected object.

Keep transformation design proportionate. When a mapping rule requires more than five or six conditions, practitioners commonly perform that transformation upstream in data preparation rather than embedding an increasingly complex rule in the cockpit.

Staging tables: where your data lands

Migration cockpit staging tables hold prepared source records on SAP HANA before target processing. They can reside in the local ABAP schema of the S/4HANA system or in a remote, dedicated HANA schema.

The cockpit creates the required tables automatically when a migration object is opened. A generated table follows the pattern /1LT/DS<sys-id><consecutive number>, so the technical name is not a stable semantic name for an ETL design.

Since 1809 FPS0, /1LT/DS_MAPPING records the relationship between the migration object, its source structure and the generated staging-table name. Teams looking for migration cockpit staging table names should use this mapping rather than infer meaning from the generated identifier.

Many programs create database synonyms that expose stable, readable names to their ETL or preparation process. The synonym insulates upstream logic from a generated name that may change, while the mapping table remains the source of truth for the current physical table.

Staging tables can be populated using migration cockpit XML template files or an ETL tool that writes to the relevant schema. This approach gives large programs a repeatable handoff between source preparation and cockpit-controlled target creation.

Sequencing the load

SAP does not publish one universal SAP migration cockpit load sequence. Dependencies are documented object by object in prerequisite sections and collective SAP Notes, so each project must derive and govern its own sequence.

A practical sequence starts with foundational data such as banks and GL accounts, then enterprise and organizational structures, then cost centers and profit centers, followed by materials, customer master data, suppliers and Business Partners. Open items, balances and open orders follow when their prerequisites are available, with historical data handled according to the agreed retention design.

Dependencies are operational, not merely documentary. Customers loaded before bank master data can be rejected for missing bank keys, and profit centre data must exist before dependent material master records are created. Finding either dependency during a production-scale run creates avoidable rework.

The sequence planner should therefore record every object's prerequisites, owner, volume, mock results and cutover slot. If the documentation for an object identifies a predecessor, treat it as an executable entry criterion rather than a note for later review.

Upload templates for each tier of the load

The dependency tiers above map to specific SAP objects. These free Excel templates cover them, and each one names the SAP interface it posts through and maps every column to its structure and field.

The full library of 75 templates is at /templates/.

SAP migration cockpit data readiness checklist

Run this before the first mock load, not after it.

1. Start from the target definition, not the legacy extract
2. Confirm required fields for every migration object in scope
3. Record the target structure and field for each source field
4. Note the transformation rule and whether value mapping is needed
5. Name the person who confirms each mapping task
6. Validate reference values against the target, since a code valid in the source may not exist in the new organisational design
7. Check formats and leading zeros
8. Decide duplicate handling before the load, not during reconciliation
9. Confirm internal versus external number ranges per object
10. Agree that reconciliation compares both counts and resulting identifiers
11. Assign an owner to every exception

The cutover data readiness checklist workbook tracks each of these through sign-off.

Preparing data so it loads cleanly the first time

Clean migration input is structurally valid, aligned with target reference data and reconciled before execution. Preparation should confirm required fields, duplicate handling, code mappings, formats, leading zeros, number ranges and ownership of every exception.

Start with the target definition, not the legacy extract. For each source field, record the target structure and field, transformation rule, whether value mapping is required and who confirms the mapping task. Validate reference values against the target because a code that is valid in the source may not exist in the new organizational design.

Number ranges deserve explicit treatment. A supplied identifier may be accepted while the target assigns a different one, depending on internal or external numbering. Reconciliation must therefore compare both counts and resulting identifiers.

Validating rows against the live SAP system before a mock load can shorten the correction cycle. PostNow.ai performs per-row validation in Excel so formatting and target-reference issues can be addressed before prepared data reaches a cockpit template or staging process.

Errors you are likely to meet, and what they mean

A SAP Migration Cockpit error must be interpreted in the context of the current processing phase. The examples below cover unconfirmed mappings, number-range behavior, long-running tasks, and Fiori or Gateway configuration. Reconcile successful records as carefully as failed ones.

Unconfirmed mapping tasks

Messages DMC_RT_MSG 93 and CNV_DMC_SIN 331 state that mapping has not yet been confirmed and value conversion must be maintained in the migration cockpit. Confirm every open mapping task, including fixed values and control parameters, before downloading templates, uploading files or running Prepare, as documented in SAP KBA 3075948.

Successful customer creation with a different number

A customer load can report success while the resulting customer number differs from the migration sheet. An internal number range on the Business Partner grouping lets the system assign the number, while an external number range preserves the supplied number, as described in SAP KBA 3091031.

Because the run is successful, this behavior can escape an exception-only review. Reconciliation should explicitly compare supplied and created identifiers. The reverse message, Grouping xxxx has external number assignment, enter a number, is associated with how vendor internal or external numbering was mapped during Convert Values, according to SAP KBA 2809250.

SAP KBA 2856407 also documents a case in which Business Partner instances are not created and no error is returned. That is another reason to reconcile target existence and identifiers rather than equate a clean message list with complete business reconciliation.

Runtime, configuration and transport messages

Long-running migration tasks are addressed in SAP KBA 3428275. Messages such as Cannot create project. Certain settings are required before projects can be created and No System Alias found for Service point to Fiori or Gateway configuration rather than source-record content, as covered by SAP KBA 3039598.

Cloud Public Edition does not support transport for the Migrate Your Data app, so projects are created in each tenant under SAP KBA 3420827. On-premise projects, objects and rules can be transported through LTMOM, but mapping values and fixed-value rules move by download and upload, and RFC connections are not transported.

Template structures can change between releases. If the target product version changes before go-live, prepared data may need to be transferred into the new release's templates, as documented in SAP Note 2778320.

Why mature projects run multiple mock loads

Multiple mock loads prove data quality, sequencing, runtime, reconciliation and cutover ownership before production. Each SAP Migration Cockpit simulation should be treated as a controlled rehearsal, not a disposable test. They are essential because migrated data is not reversible through the cockpit, as addressed by SAP KBAs 2812591 and 3430469.

A practical program target is at least three full dress rehearsals with increasing data volume. The first establishes object behavior and exposes mapping issues, the next validates corrected data and dependencies, and the final rehearsal proves production-scale timing, handoffs and reconciliation.

Validation continues during load processing, so some quality issues will surface only when the records meet target logic. Each rehearsal should therefore close with defect classification, corrected source rules, refreshed templates or staging data, and signed reconciliation results.

The objective is repeatability. A mock load is complete only when the team can explain what loaded, what did not, why the totals differ and exactly which approved procedure will be repeated during cutover. These are the SAP Migration Cockpit best practices that turn a technically successful run into an auditable business result.

Designed for the initial load

The SAP S/4HANA migration cockpit is designed for the initial load into an S/4HANA environment. Its migration objects create target records for the new-implementation scenario rather than maintain ongoing synchronization between systems.

SAP states this directly in its official Migration Cockpit FAQ:

"SAP S/4HANA migration cockpit was generally designed for the initial load of data into an S/4 Environment. An update functionality to Change already data in the target system is not the current scope of SAP S/4HANA migration cockpit."

Understanding that design scope allows the project to choose the correct operating mechanism for every later data activity. Re-running records that failed within the same migration object is a normal part of migration execution. Loading new or changed records continuously after go-live is a separate operational process.

Planning the data work that continues after go-live

Post-go-live data work should be designed as an operational process, separate from the controlled initial load. Typical work includes permitted corrections, master data deferred from cutover, data for an acquired entity, price-list updates and period-end postings.

The three kinds of load that follow cutover, from delta loads to hypercare corrections, are covered in the guide to data loads after go-live.

The appropriate mechanism depends on the business object, governance model and system landscape. Available options include APIs and BAPIs, IDocs, SAP Data Services, SAP Application Interface Framework, mass-maintenance transactions and SAP Master Data Governance.

For teams whose controlled source is Excel, PostNow.ai is one operational option. It sends records through standard BAPIs, validates each row before posting and returns SAP document numbers to the spreadsheet.

Frequently asked questions