Expert article

Data Migration in SAP S/4HANA – Approaches, Planning, and Practical Implementation

Data migration is not a one-time upload, but a controlled transformation process. What matters most are not only the technology and loading methods, but also data quality, mapping, object dependencies, repeatable test cycles, and a robust cutover.

October 28, 2026

Share this article

Data migration remains a key success factor in SAP S/4HANA projects. While the fundamental ETL concept still applies, the focus for data migration to SAP S/4HANA is now primarily on the standard solutions provided by SAP. With the SAP S/4HANA Migration Cockpit and standardized migration objects, SAP provides an integrated approach for the structured preparation, execution, and monitoring of the migration.

Data Migration as a Standalone Subproject

Data migration is one of the most critical success factors in an SAP S/4HANA implementation. It involves business decisions, data quality, technical transformation, process dependencies, test management, and cutover planning. An inadequately prepared migration can lead to extended project timelines, inconsistent master data, faulty downstream processes, and increased effort after go-live.

A robust migration concept therefore defines the scope, migration objects, data sources, responsibilities, transformation and mapping rules, dependencies, test cycles, durations, and business and technical acceptance criteria at an early stage.

Real-world example: The technical message “Migration successful” is not equivalent to business acceptance. Only the business data reconciliation and the subsequent process verification can confirm whether the migrated data can be processed completely and correctly in the target system.

Paths to SAP S/4HANA

There are three basic transformation paths for the transition to SAP S/4HANA: System Conversion, New Implementation, and Selective Data Transition. Which path is appropriate depends, among other things, on the source system, transformation requirements, desired data history, and project strategy.

Approach	When Is It Appropriate?	Role of Data Migration
System Conversion (Brownfield)	The existing SAP ERP system is to be largely retained.	A large portion of the existing data is technically converted; however, data cleansing and adaptation remain necessary.
New Implementation (Greenfield)	Processes, structures, or master data are to be rebuilt or harmonized.	Selective transfer of relevant master and transaction data into a newly built target system.
Selective Data Transition	A targeted combination of data transfer and transformation.	Selective choice and transformation of data sets, e.g., for consolidation or phased transitions.

Data Types and Migration Scope

For project work, a process-oriented classification is more helpful than a purely technical view of database tables. Typical categories include organizational and Customizing data, master data, open business transactions and transaction data, historical data, as well as reference and mapping tables.

Organizational and Customizing Data: Plants, storage locations, company codes, control parameters.
Master data: Material, business partner, work center, bill of materials, routing.
Open business transactions and transaction data: Inventory, open purchase orders, sales orders.
Historical data: Only to the extent required for business, regulatory, or reporting purposes.
Mapping and harmonization tables: Controlled mapping of source to target values.

The scope should also define selection rules, data volume, organizational scope, and temporal validity. Equally important is the deliberate decision regarding which data will not be migrated.

From the ETL Model to the Migration Lifecycle

Extract, Transform, Load remains the technical core. For a real-world S/4HANA project, however, this model is too narrow.

Data migration in SAP S/4HANA is not a purely linear process, but rather an iterative one. During test migrations in particular, data is repeatedly validated, migrated, and verified for business accuracy in the target system. Any errors or discrepancies that are identified are used to correct the mapping and transformation rules before the production cutover takes place following successful test cycles.

SAP S/4HANA Migration Cockpit – As of 2026

For current new implementation scenarios, the SAP S/4HANA Migration Cockpit is the central SAP standard approach for migrating business data. The Fiori app “Migrate Your Data – Migration Cockpit” (F3473) supports migration projects, migration objects, mapping tasks, simulation, and migration.

Staging Tables and Direct Transfer

Approach	Principle	Typical Use
Staging Tables	Data is transferred to staging structures created for the migration object.	Non-SAP sources, files, prepared extracts, or heterogeneous sources.
Direct Transfer from SAP System	Supported data is selected and transferred directly from a suitable SAP source system.	SAP-to-SAP scenarios, provided that both the source and the migration object are supported.

Excel can still be a practical tool in the staging scenario, but it is not the actual migration tool. For larger volumes or more complex transformations, suitable ETL tools or automated data loading may be more appropriate.

Migration Objects, Dependencies, and Extensions

Migration objects define the structures, relationships, and transfer logic required for a business object. Their content is release-dependent. Therefore, before starting a project and after upgrades, you should check whether object versions, fields, or statuses have changed. The “Explore Migration Objects” app (F8638) allows you to visualize dependencies between objects. If a standard object does not meet business requirements, you should check whether an extension is possible using the Migration Object Modeler before developing a custom solution.

Correctly Classifying LTMC and LSMW

For current S/4HANA releases, access to the SAP S/4HANA Migration Cockpit is via the Fiori app F3473. LTMC is part of earlier versions of the Migration Cockpit and should no longer be described as the current entry point in new concepts. LSMW is not the strategic standard for new S/4HANA implementations. However, special cases may still require other interfaces or customer-specific programs.

Structuring and Planning Data Migration

A successful data migration requires a clear structure for the data to be transferred and the associated activities. To this end, the first step is to determine which data is to be migrated and to what extent. Next, the technical implementation, dependencies, responsibilities, and testing and approval steps are defined.

Migration objects play a central role in this process. They structure the business data to be migrated and form the basis for further planning and execution of the migration. The key parameters for each relevant object should be transparently documented.

Key Question	What needs to be determined?
What is to be migrated?	Relevant data and migration objects, as well as their scope
Where does the data come from?	Source systems and required data extracts
How is the data transferred?	Appropriate migration approach and technical loading procedure
What dependencies exist?	Prerequisites, references, and required sequence
How is the data prepared?	Mapping, transformation, cleansing, and required derivations
How will the results be verified?	Technical validation, data reconciliation, and business-related checks
Who is responsible?	Responsibilities for deployment, migration, and business-related approval
When will the migration take place?	Test migrations, runtimes, and the production cutover window

These specifications form the basis for operational migration planning. Depending on the complexity, they can be documented in a migration object list and a detailed migration specification. While the migration object list primarily provides an overview of the scope, status, responsibilities, and dependencies, the migration specification describes the concrete implementation at the data level, such as field and value mapping, transformation rules, derivations, and business-logic checks.

This transforms the defined scope of the migration into a traceable and repeatable process that can be managed across multiple test cycles through to the production cutover.

Test Migrations and Data Reconciliation

A production migration should never be the first full migration. A proven approach consists of a series of test loads, integration tests, a dry run, and a production cutover. Each cycle reduces uncertainty and provides more reliable insights into data quality and runtime.

Cycle	Focus
Test Load 1	Technical completeness, required fields, initial mapping
Test Load 2	Corrected transformation, business-logic validation, runtime
Integration Test	End-to-end processes with migrated data
Dry Run	Production-like data volume, final load sequence, cutover timing
Production Cutover	Final extract, delta/freeze, load, validation, and release

Validation: Don’t just compare the number of records. Keys, totals, statuses, validity checks, and business relationships must also be correct.

Case Study 1: Migration of Work Plans and Integration into the Production Process

The following example illustrates a complete migration scenario in the context of work planning: Work plan data is extracted from a legacy system, reviewed for business accuracy, harmonized, and prepared for SAP S/4HANA. After migration, the data is reused in the product structure.

Legacy-Information	Transformation / Rule	Target Information
Operation	Normalization / Numbering According to Migration Concept	Process
Work Center	Mapping Source Key → SAP Work Center	Work Center
Base Quantity	Format and Unit Validation	Base Quantity
Labor Time	Conversion / Plausibility Check	Personnel Time
Machine Time	Conversion / Plausibility Check	Machine Time
Control Key	Value Mapping: Legacy → SAP	Control Key

fter the work plan migration is complete, plan groups are assigned to the relevant product structure nodes or levels. A bill of materials can be derived from the product structure. To create or validate a production version, the referenced objects must exist and be technically valid.

Quality rule: A production version can only be used in the process if the necessary references—in particular, the bill of materials and the work plan—are consistent and valid.

Practical Example 2: Dependencies and Migration Order of PS Objects

When migrating PS data, there may be business and technical dependencies between individual migration objects. If one object references another, the referenced object must already exist in the target system. For example, a PSP element assigned to a project can only be migrated once the corresponding project has been created or migrated. These dependencies determine the required migration sequence.

Stable foreign keys are essential in this context. If keys are changed between test loads, dependent objects lose their references. Mapping tables should therefore be versioned, and changes should be documented in a controlled manner.

From the Dress Rehearsal to the Production Cutover

The cutover combines technical migration with the start of operational service. For each migration object, the start and end times, predecessor, responsible parties, expected duration, verification steps, and escalation path should be clearly defined.

Define the data freeze or delta strategy.
Plan the final extract in a reproducible manner.
Determine the load sequence based on business dependencies.
Adopt runtimes from test loads and factor in safety margins.
Define error handling and responsibilities.
Perform validation with clear go/no-go criteria.
Prepare fallback decisions for critical objects.

Eight Lessons Learned

Data quality is a business matter: technical teams identify inconsistencies; data owners decide which value is correct from a business perspective.
Mapping tables are project artifacts: they should be versioned, tested, and modified in a traceable manner.
Plan dependencies first: missing predecessor objects cause avoidable load errors.
Use simulation consistently: early simulation reduces errors before the actual load.
Measure runtime: Derive cutover times from realistic test loads, not from estimates.
Do not migrate everything: a new implementation is also an opportunity to deliberately phase out legacy data.
Standard solutions over custom development: first check standard objects and extension options, then consider a customer-specific solution.
Take release dependencies seriously: objects, fields, and functions may change; the specific target release is decisive.

Conclusion

Data migration in SAP S/4HANA is a repeatable, controlled transformation process—not a one-time upload. The core technical ETL process remains relevant but must be supplemented with data quality, mapping, object dependencies, simulation, test cycles, validations, and cutover control.

For current new-implementation scenarios, the SAP S/4HANA Migration Cockpit serves as the central standard approach. Staging tables and Direct Transfer address different source scenarios; migration objects structure the scope. Nevertheless, the success of the project depends largely on business-side preparation: clear rules, stable keys, reproducible transformations, and robust test cycles remain crucial.

28. October 2026

Expert article, Latest Insights