SAP S/4HANA Data Quality: Why Waiting Until Migration Is Too Late

The queue behind the go-live date

We repeatedly see the same sequence. A programme announces its S/4HANA timeline. Months later, the first mock conversion runs, and the data workstream discovers what two decades of ECC operation actually left behind: customers created for one invoice and never touched again, vendors duplicated across purchasing organisations, materials with units of measure that contradict their own purchasing data.

None of this is new damage. It was always there. The migration simply forces the organisation to look, and it forces the look on the programme's critical path, where every remediation decision competes with the cutover date.

Technically valid is not business valid

The distinction that decides these migrations is between technically valid and business valid. A customer record with a populated account group is technically valid. If the account group is wrong for how that customer trades, every downstream determination that keys off it, from field selection to reporting, is quietly wrong too. ECC accepted it for twenty years. S/4HANA will accept it as well. The business process is what breaks.

Profiling finds the technically invalid quickly: blanks, format failures, orphaned references. Only business rules find the business-invalid, because only the business knows that this payment term should never appear with that company code, or that these two plants cannot share that material status. Writing those rules down, with owners, is the real data quality work, and none of it requires the migration to have started.

Where it hurts most: the objects

The Business Partner model is the honest example of a structural change. Customer and vendor records that lived apart in ECC converge, and every duplicate pair you have not resolved becomes a conversion decision you make under pressure. Duplicate resolution before CVI work starts is cheap. During it, expensive. After it, archaeology.

Material master carries its own patterns: units of measure, base and alternative, that must be populated and consistent; organisational extensions that determine where a material can actually be used; reference and check values that the target validates more strictly than the source ever did. Cross-object relationships bind it together, and they are where object-by-object cleansing quietly fails. Individually valid customers, materials and sales areas can still be invalid as a set.

It is worth saying plainly: most ECC data structures do not change fundamentally in S/4HANA. Treating the migration as a wholesale re-modelling exercise wastes effort. Treating it as a copy misses the places, like Business Partner, where the model genuinely moved. Knowing which is which is the expertise.

Why fixing it in the migration fails

The migration team can transform data, and every migration includes some enrichment. But transformation logic is the wrong home for quality repair. Fixes buried in migration code are invisible to the business, unauditable after go-live, and lost to the source system, which continues generating the same defects daily. Meanwhile every mock cycle consumed by avoidable data issues is a cycle not spent proving the migration itself.

Remediation belongs in the source, owned by the people who create the data, guided by the same rules that will gate the migration. Then the migration inherits clean input and the improvement survives the go-live.

The sequence that works

Profile the source objects early, before scope is final. Define business rules with named owners, and measure against them continuously so the trend is visible. Resolve duplicates before Business Partner conversion strategy is fixed. Let the rule results gate each migration cycle, so quality debt cannot silently roll forward. Keep the rules running after go-live, because a migration is a moment and data quality is a process.

Every one of those steps can start today, whatever the programme calendar says. That is the point.