Should you fix procurement data before or after S/4HANA migration? The honest answer.

Last Update: July 1, 2026by Divyesh Wani

Every S/4HANA migration program has a plan for IT. A plan for the migration partner. A plan for change management. Almost none have a plan for procurement data, and that single gap is responsible for the majority of post-migration failures.

Having worked across procurement data programs for enterprises in FMCG, automotive, pharma, chemicals, construction, and financial services, organizations running SAP ECC environments spanning hundreds of thousands of vendor records, multi-currency spend across dozens of markets, and category portfolios that touch every function in the business, we have seen this play out more times than we can count. Teams that treat procurement data as a migration side-effect inherit the same fragmented supplier master, uncategorized spend, and invisible tail spend in S/4HANA that they had in ECC. The interface changes. The problem does not.

In Deloitte’s most recent global CPO survey, lack of data quality emerged as the number one barrier to procurement digitization, ahead of budget, ahead of integration, ahead of everything else. The question running quietly through every CPO and CIO conversation is the one nobody puts on the steering committee agenda:

Do we fix procurement data before or after the S/4HANA migration?

SAP ECC mainstream support ends in December 2027. Most S/4HANA migrations run 12 to 24 months. The decision is being made right now, explicitly, or by default.

The honest answer is: both. But the split between what gets fixed before migration and what gets handled during it is the decision that determines whether your go-live lands cleanly, or becomes another post-migration remediation project.

But the split is what decides whether your migration lands cleanly.

Fix before, fix after, or split the work? The three answers most teams’ default to

Before we get to the answer, here’s what the data shows about S/4HANA migrations as most teams run them.

A 2025 study by management consultancy Horváth found:

Those numbers aren’t IT’s failure. They’re what happens when procurement data doesn’t get scoped as a workstream of its own, the dirty master data risk in S/4HANA migration, made measurable.

Which brings us to the three answers most teams default to.

  • Answer 1: “Fix everything before migration.”: Two years of cleanup ahead of a two-year migration. IT will tell you, fairly, that you don’t have time. The 2027 deadline blows. The CFO loses patience. The program gets dropped or descoped.
  • Answer 2: “Fix it after migration.” (the default most teams land on): The migration partner lifts and shifts. Whatever was broken in ECC arrives intact in S/4HANA. Same data mess, more expensive interface. Six months in, you still have no spend visibility after the SAP migration, and leadership asks why the new system isn’t telling them anything the old one didn’t. That’s the 65% post-migration quality problem above. Not a coincidence. The predictable outcome of “we’ll fix it in phase two.”

The honest answer.

  • Answer 3: “Split the work. Fix the strategic data work before migration.”: Let the migration partner handle transactional cleanup during the migration program. Two parallel scopes, two different teams, two different toolkits.

The split is the decision that matters, and most steering committees never make it explicit. Your peers are already pulling ahead.

SAPinsider’s 2025 benchmark reported that 76% now cite cleansed, harmonized operational data as a critical requirement for their S/4HANA migration plans

Not a “phase two” cleanup item. A critical requirement.

The ones who deliver on that won’t be the ones saying it loudest. They’ll be the ones who scope it as a workstream of its own, not a side-effect of the migration program.

What procurement owns. What the migration partner owns.

How to clean procurement data before S/4HANA migration, in plain terms.

What’s actually inside that scope? The work splits into two buckets:

Before migration, procurement-led, running in parallel to the migration plan:

  • Supplier master deduplication – One supplier, one record, one golden master. Not “ABC Ltd” and “A.B.C. Limited” and “ABC Corporation” treated as three different vendors.
  • Spend taxonomy and UNSPSC classification – Every line item classified at commodity level. Not “office supplies” as a catch-all for 800 different things.
  • Contract register consolidation – One source of truth for what you’ve committed to, with whom, and until when.
  • Catalog standardization – Materials, descriptions, and units of measure cleaned and normalized.

Why these: they decide whether S/4HANA’s reporting, analytics, and AI modules work on day one or just inherit the old chaos in a new interface.

And these four don’t just prepare the migration. They surface savings before the ERP migration even runs. Clean classification reveals consolidation opportunities. Deduplicated supplier records cut maverick contracts.

During the migration, the migration partner and IT, on the program:

  • Historical transactional data lift-and-shift
  • Field-level technical conversions
  • System configuration, integrations, testing

Why these: they need the migration partner’s toolkit and ride with the migration program scope. Procurement can’t do this work, and shouldn’t try to.

Making procurement data migration-ready

That “before migration” work doesn’t have to be a mystery. Here’s the sequence we run when teams hand us their data. Five phases, each producing a tangible artifact your team owns:

  1. Discovery. Stakeholder workshops with procurement, IT, finance, and operations. System mapping. Gap analysis. We document the target schema before touching a single record.
  2. Profiling. Automated field profiling across every source system. Language detection. Format recognition. Anomaly flagging, FX errors, embedded costs, duplicate IDs, multilingual variants.
  3. Extraction. LLM-powered classification pulls structured attributes from free-text descriptions at scale. Brand, type, market, dimensions, regulatory flags, extracted line by line, sector-trained, validated.
  4. Harmonization. Golden records created from duplicate clusters. UNSPSC mapping at commodity level. Custom hierarchy where UNSPSC doesn’t fit, POSM types, automotive sub-assemblies, pharma dosage forms.
  5. Governance. Production ETL pipeline takes over for ongoing loads. Audit trails. Anomaly alerts. Steward review queue. KPI monitoring monthly, so the data stays clean after we hand it back.

Each phase produces a tangible artifact your team owns. The whole sequence runs in a defined window, not 24 months.

If you want to see how we cleanse the data, phase by phase, the deck below walks through it.

📘Download Procurement Data Intelligence deck now

 

Your migration partner’s scope just got smaller

Here’s the part most teams miss when they assume this means more work overall.

A clean supplier master and a working taxonomy don’t just help S/4HANA on day one; they shrink the migration partner’s scope. The data remediation work that would otherwise have ended up inside their day-rate billing is already done.

Two specialist teams running in parallel, each doing what they’re built for. Faster. Cheaper. Cleaner go-live.

The “before migration” work doesn’t wait for the migration program to kick off. It runs independently, and as soon as you have a sample of your data, the clock starts.

Think of it this way: the “before migration” work is the foundation. The “during migration” work is finishing the building. You can’t pour the foundation while you’re framing the roof.

Spend visibility before migration

Even before migration kicks off, most procurement teams can’t see half their own spend.

According to Ardent Partners’ CPO Rising research, even best-in-class procurement teams see only 54% of enterprise spend. Most see between 40 and 50%.

That’s the spend visibility on legacy ECC most teams are carrying into migration if they don’t fix the foundation first. And it’s the gap that the “before migration” work closes.

Here’s what those measurements look like when teams come to us for first-pass profiling, and what migration-ready actually looks like as a number:

Metric Typical Starting Point Migration-Ready Target
Vendor master deduplication rate ~40% 95%+
Spend taxonomy / category tag coverage <20% 97%+
Brand / description consistency ~60% 100%
Hidden duplicate spend in PO lines 8–15% of rows 0%
FX and formula error rate Unknown Zero

 

These aren’t aspirational. They’re observed starting points from engagements across FMCG, automotive, and pharma, and the targets are what migration-ready actually looks like as a number.

And every percentage point in that gap maps to a savings opportunity. Move category tag coverage from <2% to ≥98%, and you can finally see which commodities have fragmented spend, which suppliers serve overlapping needs, and which contracts have expired without renewal. Migration alone won’t deliver these savings. Visibility will.

Closing that gap doesn’t take 24 months. It takes a defined window, a parallel scope, and a team built for the work.

And one number explains what “fix it after migration” actually costs:

8–15% of your spend lines are near-duplicates in disguise, the typical hidden duplication rate we find on first-pass profiling.

On the day you migrate, that’s 8–15% of your spend that the new system can’t consolidate, can’t optimize, can’t report on accurately.

It doesn’t fix itself in S/4HANA. It just gets more expensive to find.

This is the gap, by the numbers. We close it before migration, not after.

Where to start

If procurement data quality is part of your S/4HANA planning, we can do a quick 30-minute call to walk you through our procurement data health check.

Book a 30-min Discovery Call

No pitch decks, just a real conversation.

If relevant, we can run the 48-hour assessment and share what needs to be cleaned up before migration.

With ECC support ending in December 2027, the “before migration” work is the piece you can start now. Independent of when your migration program kicks off.

Frequently asked questions

Eighteen months on a calendar is not eighteen months in practice for an enterprise migration. A typical S/4HANA migration program runs 12 to 24 months from kickoff to go-live. Pre-migration procurement data work needs to be substantially complete before the migration partner builds their plan, otherwise the plan gets built around dirty ECC data. Add two to three months for budget approval, stakeholder workshops, and data extraction, and the window that looks like 18 months is closer to one budget cycle.

The good news: the procurement data work does not need the migration programme to exist before it starts. It runs on current ECC and produces standalone value, a deduplicated vendor master, a classified spend baseline, a clean catalogue, that is useful today and that the migration partner inherits on day one of their engagement.

Powerweave’s 48-hour Data Readiness Assessment is the right first step: a sample spend export goes in, and within two business days the output is a data quality scorecard, duplicate clusters identified, UNSPSC classification applied, and a ranked fix list, enough for the CFO to budget against and for the steering committee to approve a program.

The internal selling challenge is that the procurement data problem is invisible until it is a crisis, and by then the migration partner is on-site and billing day-rate for remediation. The budget case needs to make the cost of inaction visible before that point, in numbers IT and finance will accept. Three numbers make the case: the estimated duplicate spend currently hidden in the vendor master (typically 8–15% of rows on first audit); the cost differential between cleaning data now in a separate program versus during migration at migration partner day-rates; and the spend visibility percentage the category savings program is currently working from (most organizations are below 50%).

Powerweave’s 48-hour Data Readiness Assessment generates all three numbers from a sample of real ECC data, no license commitment, no SI engagement, no migration date required. It is designed specifically to produce the steering-committee-ready artefact that converts an internal conversation into an approved program.