A comprehensive guide to SAP data migration, covering key questions, strategies, tools, data quality, testing, and best practices.
SAP data migration is the controlled process of extracting, transforming, validating, and loading business data from legacy systems into an SAP target environment such as SAP S/4HANA.
For UK organisations moving from SAP ECC to SAP S/4HANA, data migration is often one of the most complex workstreams in the transformation. The challenge is not simply moving records into the new system. Organisations need to decide what should be migrated, what should be archived, how legacy structures should be transformed, how data quality will be validated, and how the business will confirm that the migrated data supports the target operating model.
For organisations planning an ECC-to-S/4HANA transformation around the 2027 maintenance milestone, data migration should therefore be considered alongside the wider SAP S/4HANA migration strategy.
Below are the most common questions organisations ask when planning an SAP data migration.
|
Consideration |
What to assess |
|
Source systems |
SAP ECC, other SAP systems, non-SAP ERP, databases, spreadsheets, and specialist applications |
|
Data scope |
Master data, open transactions, balances, selected history, and required operational data |
|
Data quality |
Duplicates, missing values, obsolete records, inconsistent structures, and invalid data |
|
Migration approach |
System conversion, new implementation, or selective data transition |
|
Migration tools |
SAP Migration Cockpit, SAP Data Services, integration and data-management platforms, and custom tooling where required |
|
Validation |
Technical checks, functional testing, reconciliation, and business sign-off |
|
Governance |
Data owners, quality rules, approval processes, security, and compliance |
|
Cutover |
Data freeze, final extraction, load, reconciliation, go-live validation, and contingency planning |
The objective is not simply to move data successfully. It is to create a clean, governed, business-ready data foundation for the new SAP operating model.
SAP data migration is the controlled transfer of business data from existing systems into a new SAP environment.
The migration may include:
A typical migration lifecycle is:
Extract → Transform → Validate → Load → Reconcile → Business Sign-off
The exact scope depends on the SAP implementation strategy, target architecture, legacy landscape, business requirements, and migration approach.
The objective is not simply to move data successfully. It is to create a reliable data foundation for the new SAP operating model.
Data migration directly affects whether the new SAP environment can operate correctly from day one.
Poor migration can lead to:
For example, an incorrect material master can affect:
MRP → Purchasing → Warehouse → Production → Sales → Finance
Similarly, an incorrect Business Partner record can affect:
Customer → Sales Order → Delivery → Billing → Receivables
A successful migration therefore needs to be treated as a business transformation workstream, not simply an IT activity.
The data scope varies by implementation, but SAP S/4HANA migrations commonly involve several major categories.
Examples include:
Depending on the migration strategy, organisations may migrate:
Historical information may also be required for:
However, not all historical data needs to be migrated into the operational SAP system.
In some cases, historical data is retained in an archive, data warehouse, or legacy reporting environment.
No. One of the most important SAP migration decisions is determining what data should actually move to the target system.
Migrating everything can increase:
A better approach is to classify data according to business value and regulatory requirements.
For example:
| Data Category | Typical Treatment |
| Active master data | Migrate |
| Open transactions | Usually migrate |
| Required opening balances | Migrate |
| Recent operational history | Assess |
| Long-term historical transactions | Archive or selectively migrate |
| Obsolete records | Usually exclude |
The principle should be:
Migrate the data the business needs, not simply the data that exists.
The goal is not to create a historical copy of the legacy ERP inside S/4HANA.
The goal is to create a clean, business-ready data foundation for the target operating model.
SAP S/4HANA Migration Cockpit is SAP's standard functionality for supporting data migration into S/4HANA.
It can support organisations in:
Available migration approaches and objects can differ depending on the SAP S/4HANA deployment model, release, and migration scenario.
Migration Cockpit should therefore be evaluated against the specific target S/4HANA environment and required business objects rather than treated as a universal solution for every migration requirement.
The migration tool should follow the migration strategy - not define it. Complex programmes may require a combination of SAP standard capabilities, data-management platforms, integration tooling, and custom transformation logic.
The distinction is particularly important in S/4HANA transformation programmes.
A system conversion transforms an existing SAP ERP system into SAP S/4HANA.
The existing system, configuration, and data are transitioned as part of the conversion.
A new implementation creates a new S/4HANA environment and migrates selected business data into it.
This approach provides more opportunity to redesign processes and clean up data.
Selective data transition combines elements of both approaches, allowing organisations to retain selected existing structures or data while transforming other parts of the landscape.
The right strategy depends on:
The migration approach should therefore be the result of the business and technical assessment, not an assumption made at the beginning of the project.
Master data describes relatively stable business objects used by operational processes.
Examples include:
Transactional data records business events.
Examples include:
Master data typically needs to be migrated before dependent transactional objects can be loaded.
For example:
Material master → Bill of Material → Production-related data
This creates dependencies that need to be incorporated into the migration sequence.
The two concepts are related but serve different purposes.
Moves data from one system or environment into another as part of a transformation.
Legacy ERP → S/4HANA
Keeps different systems connected so that information can continue to flow between them during normal operations.
S/4HANA ↔ EWM ↔ TMS ↔ External Systems
Migration is therefore usually a transition activity, while integration is an ongoing operating capability.
This distinction becomes particularly important when moving from ECC to S/4HANA in a landscape that still includes non-SAP applications, warehouses, manufacturing systems, transportation platforms, or external partners.
Data preparation usually involves several activities:
Data cleansing should begin early.
Waiting until the final migration cycle to discover poor-quality master data is one of the common causes of migration delays.
For UK organisations, data preparation should also consider whether records contain personal or regulated information, how long that information needs to be retained, and which data should be archived rather than migrated into the operational SAP environment.
Data quality should be managed through measurable validation rules rather than manual inspection alone.
Typical controls include:
For example, a material record may need to satisfy requirements for:
Material Type + Plant + Purchasing Data + MRP Data + Accounting Data
A record that passes a technical file check may still fail a business validation.
That is why data quality testing needs both technical and functional ownership.
Data migration should not be owned exclusively by the IT team.
A successful programme normally involves:
The business should ultimately determine whether migrated data is accurate and usable.
IT can verify that a record loaded successfully.
The business must verify that the record is correct.
Data mapping defines how information from the source system corresponds to structures in SAP.
For example:
| Legacy System | SAP S/4HANA |
| Customer ID | Business Partner |
| Vendor ID | Business Partner |
| Legacy Material Code | Material |
| Legacy Plant Code | SAP Plant |
| Legacy GL Account | SAP G/L Account |
Mapping becomes more complex when the target operating model changes.
A legacy system may have ten organisational codes that are consolidated into three SAP entities.
In that case, migration is not merely a technical mapping exercise. It becomes part of the business transformation and organisational design.
There is no universal number, but successful SAP programmes normally perform multiple migration cycles before production cutover.
A typical sequence may include:
Mock Migration 1 → Data Cleansing → Mock Migration 2 → Integration Testing → Mock Migration 3 → User Acceptance → Final Migration
Each cycle should improve:
The final migration should therefore be a controlled execution of a process that has already been tested repeatedly.
A mock migration is a rehearsal of the migration process using representative or production-like data.
It helps teams validate:
Mock migrations are particularly important when the final cutover window is limited.
A migration that works technically but takes three days to execute may still be unacceptable if the business has only an eight-hour downtime window.
The final cutover is more than the final data load.
A typical sequence may include:
Transaction Freeze → Final Extraction → Transformation → Load → Technical Validation → Reconciliation → Business Sign-off → Go-Live
Depending on the programme, cutover may also require:
The cutover plan should have clear owners, timings, dependencies, escalation paths, and go/no-go criteria.
The objective is to make the production migration repeatable and measurable, not to improvise it on go-live weekend.
Migration testing should cover both technical integrity and business usability.
Verify:
Verify that migrated data supports actual business processes.
For example:
Customer → Sales Order → Delivery → Billing → Accounting
or:
Material → MRP → Purchase Order → Goods Receipt → Invoice
Financial data requires additional controls, including reconciliation of:
The objective is not merely to prove that data was loaded.
It is to prove that the business can operate correctly using the migrated data.
Reconciliation compares data and business results from the source systems with those in the target SAP environment. It helps confirm that migrated data is complete, accurate, and consistent after the migration.
Depending on the data type, organizations may compare:
For finance, reconciliation should typically be performed at appropriate organizational and accounting levels to confirm that key balances and transactions have been transferred correctly.
A useful principle is:
Every critical migration object should have a defined reconciliation method and an accountable business owner.
The most common challenges are not necessarily related to migration tools. They often come from the quality, structure, and governance of the data itself.
Duplicate, incomplete, obsolete, or inconsistent data can make transformation more difficult and increase the effort required for cleansing and validation.
Organizations may have multiple SAP and non-SAP systems with different data models, structures, and integration methods.
Different plants or business units may use different definitions, formats, or codes for the same business object, making standardization more difficult.
If nobody is accountable for data quality and migration decisions, issues can take longer to resolve and responsibilities can become unclear.
Custom fields, Z-programs, and other legacy developments may require additional mapping, transformation, or redesign to fit the target S/4HANA environment.
Large data volumes and dependencies between systems can make the final migration technically and operationally challenging, particularly when downtime must be minimized.
Users may expect historical processes or legacy codes to remain unchanged even when the target S/4HANA model requires standardization or process redesign.
A structured migration strategy can help reduce project risk and identify issues before they affect the final cutover.
Key practices include:
The most effective migration programs treat data as a business asset with defined quality standards, rather than simply as a collection of files to be uploaded.
The appropriate toolset depends on the migration scenario, data landscape, and target architecture.
SAP environments may use capabilities such as:
Tool selection should follow the migration architecture rather than determine it. Different tools may be combined depending on the source landscape, data objects, transformation requirements, and migration approach.
The key questions are:
What data needs to move? Where does it originate? How complex is the transformation? How often will migration run? What validation and reconciliation are required?
SAP Master Data Governance (MDG) can help organisations establish governed master-data processes around objects such as:
This is particularly useful when migration exposes inconsistencies that have accumulated across multiple systems.
Migration can therefore become an opportunity to establish stronger governance rather than simply transferring historical problems into S/4HANA.
A Clean Core strategy aims to keep the S/4HANA core as standard and upgradeable as possible.
Data migration supports this objective by:
Migration should therefore be viewed as an opportunity to simplify the target environment.
Replicating every historical data structure and custom workaround can undermine the benefits of moving to S/4HANA.
There is no standard SAP data migration timeline.
The duration depends on:
A global S/4HANA transformation involving multiple ERP systems can require substantially more migration effort than a single-system implementation with well-governed master data. Historical data requirements can also significantly affect the scope, particularly when organizations need to retain or transform large volumes of legacy information.
The most reliable way to estimate the timeline and effort is through an early data discovery and complexity assessment. This helps identify data-quality issues, dependencies, transformation requirements, and migration risks before detailed planning begins.
A comprehensive SAP data migration strategy should define not only what data will be moved, but also how it will be prepared, validated, approved, and transferred to the target environment.
What data will and will not be migrated?
Define which data will be migrated, archived, or left in the legacy system. The scope should reflect business requirements and the capabilities of the target SAP environment.
Where does the data originate?
Identify all relevant data sources, including SAP and non-SAP systems, databases, spreadsheets, and other sources. This helps uncover data dependencies, duplicates, and inconsistencies early.
Where will the data reside in SAP?
Define where each data object will reside in the target SAP environment and how it will be structured. This includes mapping legacy data to the relevant SAP master data, transactional data, and organizational structures.
How will legacy structures be converted?
Specify how legacy data will be transformed to meet the requirements of the target system. This may include field mapping, format changes, code conversion, data enrichment, and duplicate-record consolidation.
Who approves the migrated data?
Assign clear responsibility for each data domain. Business data owners should define quality requirements and approve migrated data before it is loaded into the production environment.
How will data quality be measured?
Define how data quality will be measured before, during, and after migration. Validation should cover completeness, accuracy, consistency, and compliance with the target SAP structure.
How will completeness and accuracy be proven?
Establish how migration results will be compared with source data. Reconciliation should confirm that critical records, quantities, balances, and other business-relevant information have been transferred completely and accurately.
How many rehearsals are required?
Plan the number of migration cycles needed before go-live. Trial migrations and rehearsals help identify mapping, transformation, data-quality, and performance issues while there is still time to address them.
How will the final migration be executed?
Define the final migration process, including data freeze periods, extraction and loading activities, validation, business sign-off, and the transition to the new SAP environment.
What happens if migration fails or critical data does not reconcile?
Define what happens if the final migration encounters critical errors. A contingency plan should establish responsibilities, decision points, recovery or rollback options, and criteria for proceeding with go-live.
The following principles can help organisations build a more reliable migration programme:
Migration success should be measurable.
Useful KPIs include:
| KPI | What It Measures |
| Data completeness | Whether required records were migrated |
| Data accuracy | Whether migrated values are correct |
| Duplicate rate | Quality of master-data cleansing |
| Migration error rate | Technical and validation failures |
| Reconciliation variance | Difference between source and target |
| Successful load rate | Percentage of records loaded successfully |
| Mock migration duration | Readiness for production cutover |
| Business sign-off rate | User acceptance of migrated data |
| Post-go-live data defects | Quality of final migration |
The objective is not to achieve a technically successful data load.
The objective is to achieve business-ready data at go-live.
One common SAP migration mistake is treating data as something to be cleaned and loaded at the end of an implementation.
In reality, data quality directly affects business processes and operational performance. A successful SAP data migration therefore requires clear scope, defined data ownership, data cleansing and transformation, standardization, thorough testing, reconciliation, and a controlled cutover.
For organizations moving to SAP S/4HANA, the process should begin with a structured assessment of the existing data landscape, target architecture, migration scope, data quality, and business requirements.
Disclaimer: SAP product capabilities, data migration tools, implementation methodologies, and best practices may evolve over time. This article reflects information available at the time of publication and is provided for general informational guidance only. SAP functionality and migration options may vary depending on the deployment model, product version, licensing, configuration, source systems, and target architecture. Organisations should validate current SAP capabilities, roadmap information, technical requirements, data migration scope, and implementation considerations with SAP and qualified SAP specialists before making technology or investment decisions.