The short answer. The best SAP data migrations follow one principle: treat data as the main workstream, not a late-stage task. Profile early, clean and de-duplicate master data, map legacy structures to the S/4HANA model, load through the Migration Cockpit, and reconcile every record against the source. Programmes that do this go live on time; programmes that leave data to the end slip.

Ask why an S/4HANA migration ran late and the honest answer is rarely the technology. It is almost always the data: duplicates nobody resolved, fields that were empty in ECC but mandatory in S/4HANA, structures that did not map cleanly to the new model. The good news is that these problems are predictable, which means they are preventable.

Here are the practices that separate a smooth migration from a stressful one, in the order they matter.

Why data-first beats system-first

S/4HANA is not a newer copy of ECC. It uses a different data model, most visibly the Business Partner model that unifies what ECC held as separate customer and vendor records. Because of that, data cannot simply be lifted across. It has to be understood, corrected, and reshaped first. A tool can load data quickly; it cannot decide whether that data was fit to move. That judgement is the real work.

The best practices that decide go-live

Profile before you plan. Assess the true state of your data before committing to an approach or a date. The findings almost always reshape the plan.
Start master data early. Duplicate and inconsistent master data is the biggest single cause of delay. Begin cleansing in parallel with everything else.
Define extraction rules, not ad-hoc pulls. Rule-based extraction from ECC keeps the process repeatable across the many test cycles a migration needs.
Validate against business rules, not just formats. Check completeness, accuracy, and consistency, not only that a field is filled.
Map to the target model deliberately. Company codes, account groups, organisational structures, and the move to Business Partner all need explicit transformation logic.
Protect data in non-production. Testing needs realistic data, but real data in lower environments is a compliance risk. Scramble sensitive fields so testing stays safe.
Load through the Migration Cockpit properly. Use staging and pre-load validation so errors surface before the target is touched, not after.
Reconcile every load. A migration is finished when you can prove loaded data matches the source in count and value, not when the job completes.
Run it more than once. Treat mock loads as rehearsals. The first pass finds the problems; later passes prove they are fixed.
Keep an audit trail. Record what moved, what changed, and what was rejected, so the migration is defensible after go-live.

Common mistakes to avoid

Treating data as a late-stage task. It is the longest workstream, so starting it last guarantees pressure at cutover.
Assuming the load tool cleans data. The Migration Cockpit validates at load time, but it is not a data quality tool. Quality has to be fixed upstream.
Migrating everything. Old, inactive, and duplicate records add cost and risk. Decide what genuinely needs to move.
Skipping reconciliation. A clean-looking load is not proof. Only reconciliation is.

The data objects that cause the most trouble

Not all data carries equal risk. In most SAP migrations, a handful of objects account for the majority of the pain, and knowing them in advance lets you point your effort where it matters:

Business partners (customers and vendors). The move to the unified Business Partner model is where legacy customer and vendor records collide. Duplicates, mismatched roles, and incomplete banking or tax detail all surface here.
Material master. Materials created many times over, with slight variations in description or unit of measure, inflate stock and split purchasing. De-duplication before migration is essential.
Open items. Open purchase orders, sales orders, and financial documents need careful handling so that only genuinely open, migration-worthy items move across.
Organisational structures. Company codes, purchasing organisations, and account groups all have to map cleanly to the target, or downstream postings break.

A good programme profiles each of these early and treats the worst offenders as their own workstream rather than assuming they will come out in the wash.

Why the timeline is mostly data

When teams underestimate a migration, it is almost always the data preparation they underestimate. The technical conversion has a fairly predictable shape. Data cleansing does not, because you cannot know how much work it is until you have profiled it. This is why the single most valuable thing you can do early is to profile, so the plan is built on evidence rather than optimism. A migration plan that allocates most of its calendar to the load and testing, and little to data preparation, is usually a plan that has not profiled yet.

Why mock loads matter more than people expect

A migration is not something you want to do correctly for the first time on go-live day. Mock loads, full rehearsals of the extract, transform, and load process against a copy of the target, are how a programme turns unknowns into knowns. The first mock load almost always surprises the team: objects that looked ready fail, mappings that seemed complete have gaps, and volumes that seemed manageable take longer than planned. That surprise is the point. Every problem a mock load finds is a problem that does not surface during the real cutover, when the business is waiting and the window is fixed.

A good rule of thumb is that the number of mock loads should be however many it takes for the last one to be boring. If your final rehearsal still throws up material issues, you are not ready. If it runs clean and predictable, with reconciliation matching every time, that is the signal that go-live will too.

Data quality does not end at go-live

It is tempting to treat migration as a finish line, but the data you worked so hard to clean will start to degrade again the moment the new system is live, through the same forces that dirtied it before: manual entry, multiple touchpoints, and change over time. The organisations that stay clean are the ones that carry their migration discipline forward into ongoing governance: continued profiling, validation at entry, and clear ownership of each data domain. Seen this way, a migration is not just a move; it is the moment to establish the data habits the new system deserves.

How deKorvai helps

deKorvai is built around exactly this data-first sequence. It extracts from ECC using rules, profiles and validates against business and technical checks, transforms and maps to the S/4HANA model, scrambles sensitive data for non-production, and loads into the Migration Cockpit (DMC or LTMC) staging tables with reconciliation built in. In one documented business partner migration, it moved more than 50,000 vendor records with 100% data accuracy and a 95%+ first-pass rate.

Key takeaways

Data is the main workstream, not a step before go-live.
Master data first: it is the biggest source of delay and can be fixed in parallel.
Prove it: reconciliation, not a completed load, is the definition of done.
One flow beats stitched tools: profiling, transformation, and validation belong together.

Frequently asked questions

What is the most important SAP data migration best practice?

Starting the data work early. Profiling, cleansing, transformation, and reconciliation are the longest and least predictable parts of a migration, so beginning them early is the most reliable way to protect the go-live date.

Does the SAP Migration Cockpit clean data?

No. The Migration Cockpit validates data at load time and executes the load, but it is not a data quality tool. Cleansing and de-duplication have to happen upstream before data reaches it.

Should we migrate all our ECC data?

No. Old, inactive, and duplicate records add cost and risk without adding value. A good migration decides deliberately what needs to move rather than carrying everything across.

How do we know a migration was successful?

When loaded data can be reconciled against the source, matching in both record count and values. A completed load is not the same as a proven one.

SAP Data Migration Best Practices: A Data-First Go-Live Guide