Why SAP data migration fails and how to fix it

SAP data migration fails for one reason more than any other: the plan is built on what the business thinks its data looks like, not on what an extract shows. This guide is for programme directors, data leads and finance leaders on an S/4HANA programme. It covers why migrations break, the five mistakes behind most cutover failures, a mock-load plan you can copy, and which SAP tools fit which job in 2026. If you do one thing this week, take a full extract of your customer, vendor and material masters and count the records yourself.

A manufacturing company spent 18 months and $4.5 million on its SAP implementation. Launch day arrived. Everyone was nervous but excited. Then the data migration failed.

Nothing worked right. Customer data was missing. Inventory numbers were wrong. Accounting could not close the books. The CEO was furious.

It was not the software and it was not the implementation team. The failure was in the gap between what the business thought its data looked like and what it actually looked like.

SAP's data model is not a flat import. Records depend on each other. A material master has a general record (MARA), plant data (MARC), valuation data (MBEW) and, where MRP areas are used, MRP area data (MDMA). Load the header without the dependent views and the material exists but cannot be used in a transaction.

S/4HANA adds its own rule. Customers and suppliers are business partners. A legacy customer becomes a business partner with a customer role, and a vendor becomes one with a supplier role. Credit limits, bank details and tax numbers hang off that business partner. A record that a legacy system tolerated with gaps will fail validation here.

Then there is volume. Most companies are shocked by how much data they actually have. One client thought it had about 50,000 material records. Counting all the variants and plant-specific records, the number was closer to 500,000. A plan sized for the first number does not survive the second.

Business estimateFull extract

Material records in scope500,000+450,000 · +900%

Business estimate50,000

Full extract500,000

• Every variant and plant-specific record counted
• A plan sized on the estimate does not survive it

That was not a data migration problem. It was a scoping problem that became one.

The data quality assessment at the start of a project is usually a description of the data, not an examination of it. The finance director says the vendor master is well maintained. The warehouse manager says the materials are mostly clean. Those are impressions.

The first extraction tells you the truth. Vendors that were meant to be cleaned up years ago and were not. Materials discontinued long ago and never deactivated. Customer addresses with inconsistent country codes. Bank details missing on vendors paid by electronic transfer.

Each of these needs a business decision, not a technical fix. Only accounts payable can say which of two duplicate vendors is correct. Only procurement can say which obsolete materials to block and which to leave behind. Those decisions take time, and they need the people who know the data. If the assessment is not based on a real extract, the plan is built on assumptions that will not survive contact with the data. My free data migration estimator helps size the effort once you have real counts.

1. Treating migration as a late technical task

Migration belongs in every SAP Activate phase. Explore defines the scope: objects, source systems, volumes and quality. Realize builds the templates and runs the mock loads. Deploy runs the final rehearsal and the cutover load. Run reconciles the first period close on live data.

Projects that start migration work in Deploy are starting it months too late. The quality issues that should have been resolved in Realize turn up in the first mock, weeks before cutover. My SAP timeline planning guide shows where migration sits in the overall plan.

2. Too little business involvement

Migration is technical in execution and a business activity in decision-making. IT cannot produce the list of duplicate vendors. Which customer accounts move as active and which stay as history is a finance decision. Obsolete material cleanup needs procurement, warehouse and product management.

Programmes that staff migration only with technical people, and treat the business as a sign-off at the end, produce data that loads. Commercially, it is wrong.

3. Planning too few mock loads

A well-run SAP data migration needs at least three mock loads before cutover, and complex programmes need more. Projects that plan for one or two are planning for clean data and clean mapping. That scenario is rare. More cycles are not a sign of a troubled migration. They are a sign of a properly planned one.

4. Not reconciling trial loads

A load job finishing without errors is not validation. Validation compares what was loaded with what was expected: record counts, financial totals, open item balances. Then a process smoke test confirms the data works in transactions.

A trial load that is not reconciled still costs time. The gap it produced is still there at the next mock, only now it is harder to trace back to its cause. Reconcile every load before starting the next one.

5. A cutover load that differs from the rehearsals

The cutover migration should repeat the final mock exactly: same extraction scripts, transformation logic, load sequence, checks and timing. Any change at cutover is untested risk at the highest-pressure point of the programme.

The least-tested piece is usually the delta. Between the final mock and cutover, the business keeps adding vendors, changing orders and moving stock. Define the data freeze date and rehearse the delta load as part of the final mock.

Use this cycle structure as a starting point. Each cycle has an objective and an exit criterion, and it is not complete until the reconciliation is signed.

Cycle	Objective	Exit criterion	Owner
Mock 1	Structure: every object loads in dependency order	Mapping gaps and format errors logged per object	Data migration lead
Mock 2	Quality: test the mapping fixes and expose data issues	Error rate falling per object; cleanup decisions logged	Data stewards
Mock 3	Business rules: exceptions and edge cases	Stewards accept a reconciled sample in each domain	Data stewards
Mock 4	Volume and timing at full production size	Full load completes inside the cutover window	Cutover manager
Final rehearsal	Dress rehearsal of cutover, including delta and freeze	Counts and financial totals reconciled and signed	Financial controller and data lead

Around that plan, five things make the difference:

1. A full extract in Prepare. All of it, not a sample. Profile completeness, accuracy, consistency and duplicates, then size the cleanup and the timeline from the results.
2. Object-by-object mapping. For each object (business partners, materials, open purchase and sales orders, open items, stock, fixed assets), document source-to-target fields, transformation rules, validation checks and exception rules.
3. Named data stewards. Finance owns customer and vendor financial data. Procurement owns the material master. The warehouse owns stock. Each steward signs off their domain after every cycle.
4. Reconciliation defined upfront. Agree which counts and totals prove a load is right before the first mock, so nobody argues about it at cutover.
5. A written cutover sequence. Freeze, extract, transform, load, validate, business sign-off, go/no-go. The same sequence as the final rehearsal.

For a new S/4HANA implementation, the SAP S/4HANA Migration Cockpit is SAP's recommended tool for the initial load. Since S/4HANA 2020 it runs as the Fiori app Migrate Your Data. Transaction LTMC is deprecated, and existing LTMC projects can only be displayed. The app offers two approaches: migrate data using staging tables (filled from files or by your own tools) and migrate data directly from an SAP source system. On-premise and private cloud teams use transaction LTMOM, the migration object modeler, to adjust standard objects or build their own. The cockpit is built for initial loads, not for recurring interfaces or mass changes.

SAP Data Services is SAP's ETL platform. Use it for high volumes, heavy transformation logic, several source systems, or when you want a reusable data quality framework that outlives the project.

Third-party ETL tools such as Informatica, Talend or Microsoft SSIS make sense where the organisation already owns them and has the skills.

SAP Datasphere, now part of SAP Business Data Cloud, is not a migration tool. Its place is the analytics layer after go-live. It matters if you leave history in the legacy system and still need to report on it.

For most standard implementations, the Migration Cockpit covers the majority of objects. High volumes, heavily customised legacy systems or unusual source structures usually need Data Services or an ETL tool alongside it. Conversions from ECC are a different exercise, covered in my ECC to S/4HANA migration guide.

What is SAP data migration?

SAP data migration is extracting data from legacy systems, transforming it to fit SAP's structures and rules, and loading it into SAP as part of an implementation or conversion. Typical objects are business partners (customers and suppliers), materials with plant data, open purchase and sales orders, stock balances, financial open items and fixed assets. It is hard because SAP enforces dependencies and validation rules that legacy systems often did not.

What are the main approaches to SAP data migration?

A new implementation (greenfield) loads selected master data and open items into a fresh S/4HANA system, leaving history in the legacy system or an archive. A system conversion (brownfield) converts an existing ECC system and its history in place. Selective data transition sits between the two, moving chosen company codes, objects or time slices. The right choice depends on data quality, history requirements and how much of the old process you want to keep.

What is SAP Migration Cockpit and when should you use it?

The SAP S/4HANA Migration Cockpit is SAP's recommended tool for the initial data load into S/4HANA, in all editions. Since S/4HANA 2020 it runs as the Fiori app Migrate Your Data; transaction LTMC is deprecated. It provides predefined migration objects, validates data before posting and reports errors at field level. Use it for standard objects at normal volumes. Add SAP Data Services or another ETL tool when volumes, transformation logic or source structures go beyond what the templates handle.

How many mock loads should an SAP data migration plan for?

At least three, with the last one a full cutover rehearsal. Complex programmes need more. In a typical plan, the first finds structural mapping gaps. The second tests the fixes and exposes data quality issues. The third works through business rules and edge cases. The final run repeats the cutover exactly, and its reconciliation becomes the baseline for go-live day.

How do you migrate customers and vendors to SAP S/4HANA?

As business partners. In S/4HANA, customer and supplier master data is maintained through the business partner, with customer and supplier roles attached. In a new implementation, the Migration Cockpit loads them through its business partner objects. In a conversion from ECC, customer-vendor integration has to be set up and run before the conversion itself.

What causes SAP data migration to fail at cutover?

Five patterns cause most cutover failures. Too few mock loads. A cutover sequence never tested end to end. Legacy changes after the final mock with an untested delta load. Reconciliation gaps left open. Business sign-off based on a spot check. "The first 1,000 records looked fine" is not validation. Go-live needs reconciled counts and totals.