MDM #10. Why Master Data Derails SAP S/4HANA Migration

Late in an SAP S/4HANA migration, a data problem can suddenly become a program problem.

The conversion itself may be running. Interfaces may already have passed testing. Business users may be preparing for cutover.

Then a migration rehearsal exposes something that looked minor in the legacy environment.

A supplier exists under several identifiers. A customer is linked to the wrong organizational structure. Material attributes mean different things in different plants. A legacy code has no agreed target value. A record loads successfully but cannot support the first business transaction after go-live.

At that point, another cleansing cycle is often started.

Sometimes that is necessary.

But I think it is important to ask a more fundamental question:

Is this really a migration defect — or is the migration exposing a master-data decision that the organization never made?

That distinction matters.

A migration tool can move data. It can validate formats, execute mappings and report errors.

It cannot decide what a supplier means to the business, which system is authoritative, whether two records represent the same legal entity, or which organization should own a global standard after go-live.

For that reason, I would treat master data as part of SAP S/4HANA transformation design — not as a cleansing activity left for the end of the project.

The migration rehearsal that tells you more than the dashboard

Migration dashboards naturally focus on measurable technical outcomes.

How many records were extracted?

How many loaded successfully?

How many failed?

How long did the run take?

Those numbers are essential. But they answer only part of the question.

Consider a material record that loads without an error.

The migration is technically successful.

But if its unit of measure, valuation data or plant assignment is wrong, the first production or inventory process may still fail.

A supplier may migrate successfully while carrying an incorrect payment attribute.

A customer may exist correctly as a record but be assigned to the wrong sales organization.

This is why I would distinguish four different kinds of migration success.

Question	What it actually proves
Did it load?	The target system accepted the record.
Is it valid?	Critical attributes satisfy agreed rules.
Is it correct?	The record represents the intended business reality.
Can the business use it?	The migrated record can support an end-to-end process.

The fourth question is the one I would pay particular attention to before cutover.

Business Partner conversion is not just a technical conversion

One of the clearest examples is SAP's Business Partner model.

For customers moving from SAP ERP to SAP S/4HANA, SAP documents Customer/Supplier Integration — commonly referred to as CVI — as a prerequisite. Customers and suppliers have to be converted to Business Partners, with Business Partner acting as the leading object for customer and supplier master data.

SAP Help Portal — Business Partner Approach (Customer/Supplier Integration)

Technically, that is well documented.

The difficult questions often sit outside the conversion logic.

Suppose the same external company appears as a customer in one system and a supplier in another.

The names are slightly different.

One address is old.

Tax identifiers do not match.

A local organization insists they are separate records because its process has always worked that way.

What should the target Business Partner look like?

That is not something an ETL rule should decide on its own.

Before conversion, somebody needs to determine:

whether the records represent the same business entity,
which values are authoritative,
which Business Partner roles are required,
how grouping and number ranges should work,
which duplicates should be merged or retained, and
who owns subsequent changes after go-live.

SAP also provides master-data consistency checks for Business Partner conversion, reinforcing the importance of identifying customer and supplier inconsistencies before the S/4HANA conversion itself.

SAP Help Portal — Master Data Consistency Check for Business Partner Conversion

CVI readiness is therefore not only a technical prerequisite. It is also a test of whether the enterprise has resolved basic master-data identity and ownership questions.

The spreadsheet problem is not the spreadsheet

Every large migration uses mapping files.

There is nothing inherently wrong with that.

The risk begins when a mapping spreadsheet quietly becomes the place where unresolved business semantics are stored.

For example:

Legacy Material Type A → Target Material Type B

The rule may look simple.

Then one plant explains that Type A has historically been used for two different purposes.

Another country has a legal reporting requirement attached to it.

A third business unit wants the original distinction preserved for analytics.

At this point, the issue is no longer mapping.

It is target-model design.

The lesson I would take from this is simple:

A mapping table should record a business decision. It should not become the place where the business decision is postponed.

For critical mappings, I would therefore expect an owner, rationale, exception rule and approval history — not only a source value and target value.

Why repeated migration testing matters

SAP's Migration Cockpit provides the ability to simulate migration before transferring data to the target system.

The simulation can expose mapping tasks and messages that need to be resolved before migration proceeds.

SAP also describes iterative test migration as part of preparing for production transfer, allowing problems found in earlier cycles to be corrected in later ones.

SAP Help Portal — Simulating the Migration

SAP Help Portal — Creating Migration Projects

I would use those cycles for more than reducing technical errors.

Each rehearsal should answer a different question.

Rehearsal focus	Useful question
Early cycle	Do the extraction, transformation and mapping rules work at all?
Middle cycle	Are the target definitions and exception rules stable enough to repeat?
Late cycle	Can migrated master data support critical end-to-end processes?
Cutover rehearsal	Can the migration complete inside the cutover window with acceptable residual risk?

The point is not to prescribe four mandatory migration stages.

The table is a practitioner example of how the purpose of testing can mature as a program moves closer to production.

Do not confuse a global template with identical data everywhere

S/4HANA programs often pursue global process standardization.

That is usually one of the reasons the transformation exists.

But master data has to operate inside legal, tax, regulatory and business contexts that are not always identical across countries.

This creates two opposite risks.

The first is preserving every historical local field and exception because “the country needs it.”

The second is removing legitimate local requirements because “the global template should be standard.”

Neither is a good data-governance principle.

The better question is:

Is the local requirement necessary for legal compliance, control or business execution — and if so, where should it live in the target model?

This requires evidence.

A local requirement should not survive merely because it existed in the legacy system.

But a global standard should not override a real requirement merely for architectural neatness.

This is one of the areas where functioning data ownership and governance matter more than another cleansing tool.

Clean Core also has a data dimension

Clean Core is frequently discussed in terms of reducing unnecessary custom code and keeping SAP extensions upgrade-friendly.

That is only part of the picture.

SAP's Clean Core Data framework explicitly addresses data strategy, data governance, data quality, data volume and data protection.

SAP — Clean Core Data for SAP S/4HANA Cloud

This connection is worth taking seriously.

A company can reduce custom code and still retain inconsistent master data.

Users then need exceptions.

Exceptions become workarounds.

Workarounds become local tools and manual reconciliation.

Eventually complexity returns — simply in a different form.

A technically cleaner ERP does not automatically create a cleaner operating model if the master data underneath it remains fragmented.

What I would want resolved before the final rehearsals

I would avoid another long migration checklist.

Instead, for each critical master-data domain, I would ask whether six basic questions have an answer.

Question	Evidence I would expect
What does this master object mean in the target model?	An agreed definition and target data model.
Who can make a decision about it?	A named business owner with actual decision authority.
What should migrate?	Explicit migration, retention and retirement scope.
How are legacy values transformed?	Approved mappings and a defined exception process.
What quality really matters?	Rules for critical attributes rather than generic completeness targets.
How do we know the migrated data works?	Representative end-to-end business scenarios executed with migrated master data.

If one of these questions has no answer, that does not necessarily mean the project must stop.

It means the project should recognize that it is carrying a known master-data risk into the next migration cycle.

The cutover gate I would add

Immediately before go-live, record counts and technical reconciliation still matter.

But I would add one more gate: business-data readiness.

Take a small number of genuinely important processes and run them with migrated master data.

For example:

Supplier → Purchase Order → Goods Receipt → Invoice → Payment

Customer → Sales Order → Delivery → Billing → Accounting

Material → Plant → Production → Inventory Movement → Costing

The exact scenarios will differ by company.

The principle is what matters.

A master record should not be accepted merely because it exists in the target system.

It should be capable of doing the job for which it was migrated.

I would therefore expect a final master-data gate to answer at least three questions:

Are critical data-quality defects within the agreed risk tolerance?
Have business owners reviewed representative critical master records?
Have priority end-to-end processes run successfully using migrated data?

This will not create perfect data.

Perfect data is not a realistic cutover objective.

It does make residual risk more visible.

One more question: should all of this data migrate at all?

Migration programs sometimes assume that retaining more data is inherently safer.

I would challenge that assumption.

Every obsolete supplier, dormant customer, unused material, duplicate record and legacy code creates something the target environment must load, govern, secure, integrate and eventually retire.

SAP describes the Migration Cockpit as supporting the transfer of the initial data needed for business operations, including master data and relevant transactional data.

SAP Help Portal — What Data Can Be Migrated?

That leads to two separate questions:

What data do we have?

and

What data does the future operating model actually need?

They are not the same question.

A new ERP should not automatically become an archive of every historical decision embedded in the old ERP.

Retention, archival and regulatory obligations must of course be respected.

But migration scope should still be a deliberate business decision.

The real test begins after go-live

A clean migration does not guarantee clean master data six months later.

The project team eventually leaves.

New suppliers are created.

Products change.

Organizations are reorganized.

Countries request exceptions.

Interfaces introduce new values.

Business rules evolve.

If the organization returns to the same creation and approval practices that produced poor data before the migration, quality will begin to deteriorate again.

That is why I would ask one final question before declaring the master-data work complete:

Who will keep this data trustworthy when the migration project is gone?

The answer should not simply be “the MDM team.”

It should describe an operating model: who owns standards, who maintains data, who handles exceptions, who monitors quality and who is accountable when a recurring problem is not fixed.

My practical takeaway

When master-data problems appear late in an SAP S/4HANA program, adding more cleansing resources can solve individual defects.

But if similar issues continue to return, I would look deeper.

There may be an unresolved business definition.

A missing owner.

A target model that was never fully agreed.

A local exception that became permanent.

A mapping rule that is really an undocumented business decision.

Or a governance process that exists on paper but not in daily operations.

The goal before cutover is not perfect data. It is master data whose critical definitions are agreed, whose ownership is clear, whose migration decisions can be explained and whose ability to run the business has actually been tested.

That is when master data stops being something the ERP project has to move.

It becomes part of the operating model the new ERP is supposed to enable.

Sources & Further Reading

Editorial Note
The readiness questions, rehearsal model, business-data gate and practitioner recommendations in this article are Digital Future & Strategy's interpretation of enterprise MDM and ERP transformation practices. They are not SAP's official implementation methodology. Migration controls, data scope and acceptance criteria should be adapted to each organization's SAP landscape, regulatory obligations, business processes and risk tolerance.

Reviewed: September 2026

Global MDM Strategy Series

Part 2 — MDM on the Ground

MDM #8. When Enterprise MDM Goes Off Track — Five Early Warning Signs
MDM #9. Why Enterprise MDM Governance Fails After Go-Live — and How to Make Ownership Real
MDM #10. Why Master Data Derails SAP S/4HANA Migration — and What to Fix Before Cutover

Previous: Why Enterprise MDM Governance Fails After Go-Live — and How to Make Ownership Real

Next: How to Read the 2026 Gartner MDM Magic Quadrant: Five Leaders, Two Acquisitions, One Buyer Framework

Search This Blog

Digital Future & Strategy