The S/4HANA deadline is 2027. Dynamics 365 migrations are accelerating. Oracle Fusion projects are everywhere. And in every one of these projects, the master data workstream gets pushed to “we will figure it out later.”
That deferral is how organizations end up loading the same broken supplier table into a brand-new ERP, and discovering six months in that the new system cannot reconcile the duplicates either. ERP migration is the rare moment when finance, operations, and IT all agree that master data needs to be fixed. The window closes the day the new system goes live. After that, every cleanup competes with operational priorities and nobody wins those arguments.
The default plan is the trap
The default migration plan looks like this: extract from the legacy ERP, run a cleanup pass, transform to the new schema, load. Two of those four steps are wishful thinking.
The cleanup pass usually means a project manager assigns a contractor to “clean the supplier list.” The contractor opens a spreadsheet, removes obvious duplicates, fixes some formatting, and ships it back. Then the same data gets loaded into the new ERP, where the new ERP's mandatory fields surface every record that was incomplete in the old one. Now the project is two months behind and the data steward is patching records in production.
The transform step is the same story. The new ERP's data model is not the old one. Customer hierarchies are different. Vendor classifications are different. Product taxonomies are different. The old codes do not map cleanly. A junior consultant spends a week building a translation table that is almost right, and the wrong rows end up in the wrong groups.
Both problems share a root cause. Nowhere in the plan is there a step that says “decide what the master record actually looks like, with whoever owns the data, before the load.”
The cleanup belongs outside the ERP
If the cleanup happens inside the new ERP, the cleanup is happening in production. There is no review gate. There is no audit trail of what changed. There is no way to roll back a bad merge. You are editing live data with a deadline.
The pattern that works: stand up a master data layer outside both the old and new ERPs, and make it the authoritative source during the migration. Extract from the legacy system into the master data layer. Cleanse, dedup, classify, and approve every record there. Then publish to the new ERP from the master data layer.
The advantages add up fast. The cleanup runs against a stable environment, not a system someone else is also configuring. The records have a real audit trail covering who merged what and who approved which classification, which the new ERP cannot reproduce on its own. Approval workflows let stewards work through the data without being interrupted by the implementation team. And when a question comes up six months later about why a particular customer ended up in a particular group, the answer is in the master data system, not in someone's recollection of a spreadsheet from October.
This is also how you stop the same cleanup from running again next time. The next ERP migration, and there will be one eventually, starts from a governed master data layer rather than from another extract of a system that has been unmaintained for five years.
Three decisions you cannot defer
Three decisions get deferred in every migration plan I have seen, and each one breaks the project later.
The identifier question
Which customer or supplier ID survives? The legacy ERP’s? The CRM’s? A new SAP business partner number? If the legacy ID does not survive, every downstream system needs a mapping table, and that table cannot live in the new ERP. If the legacy ID does survive, someone has to confirm it is actually unique once duplicates are merged. Most legacy customer tables fail this test silently.
The mandatory field question
New ERPs almost always require fields the old one did not. SAP needs tax classification on customers. Dynamics 365 wants payment terms on every supplier. NetSuite expects subsidiary linkage. Filling those in is not a sysadmin task. It is a business decision that someone in finance has to make on every record, with the right context, before the load.
The reference data question
Country codes, currency codes, GL account structures, product hierarchies. Every one of these has to reconcile to the new ERP’s expected lists. The old codes will not map one to one. Some legacy codes are not valid in the new system. Some new codes have no equivalent in the old data. The reconciliation is a discrete piece of work, and it usually gets discovered the week before go-live.
If any of these three decisions are still open when extract starts, the migration is already in trouble.
Sequence matters
The order is cleanse, govern, then load. Not the other way around.
Cleansing first means deduping, normalizing, completing required fields, and reconciling reference data, all in the master data layer, with the original records preserved. Governance means those changes go through approval: the data steward proposes a merge, the data owner approves it, the audit trail records both. Load means the new ERP receives data that is already in the shape the new ERP expects, with no surprises at cutover.
The reverse order, load first and fix later, is the source of every “the master data is a mess” complaint you will hear in the year after go-live. Loading dirty data into a new ERP is faster on the project plan and slower on the calendar. The cleanup that did not happen pre-migration becomes a permanent maintenance load on the data team.
Pitfalls that keep showing up
| Migration choice | What actually happens |
|---|---|
| Cleanse inside the new ERP | Editing live production data with a deadline. No audit trail, no rollback, no review gate. |
| Treat the legacy ID as the master key | Duplicates that were silent in the old system surface as collisions in the new one. |
| Defer mandatory fields to cutover weekend | Records reject on load. The data steward becomes a bottleneck for go-live. |
| Retire the cleanup environment at go-live | Next ERP migration starts from another five-year-old extract. Same project, same cost. |
What survives the migration
A surprising amount of effort goes into deciding what the cutover snapshot looks like. Less effort goes into what stays governed afterward.
The master data layer that hosted the cleanup should not be retired the day the new ERP goes live. It should keep being the system of record. The new ERP becomes a downstream consumer like any other, receiving published master records via integration views, REST APIs, or scheduled batch loads, depending on how the ERP wants to be fed. The CRM, the data warehouse, and the BI layer also receive from the master data layer.
This is the structural change. Before the migration, the legacy ERP was the de facto master because it was the only system where the data lived in a coherent shape. After the migration, the master data system is the master, and every ERP, current and future, is just one more consumer. The boundary between an ERP and an MDM stops being theoretical and becomes operational.
That structural change is what stops the next ERP migration from being another two-year cleanup project. The data is already governed. The schema is already stable. The new ERP gets a feed.
A practical first scope
Full master data governance for an ERP migration is a multi-month engagement. A useful first scope is narrower.
Pick the domain that hurts most. For most organizations doing an S/4HANA migration, that is customers, because customer master data is what finance reconciles and finance is funding the project. For an industrial company, it might be suppliers. For a manufacturer, it might be products. Read the first-domain picking post if the choice is not obvious.
Stand up the master data system. Configure entities for that one domain. Extract the legacy records. Run the cleanse cycle: dedup, normalize, fill mandatory fields, approve. Publish the cleaned set to the new ERP via the integration view that the ERP team is already building.
Then expand to the second domain, while the first is already in production. By the time the third domain comes around, the cleansing pattern is repeatable, the stewards know what they are doing, and the new ERP is receiving governed data on a schedule.
The mistake is trying to clean every domain in parallel during the migration crunch. The teams are not ready, the tools are not configured, and the deadline forces shortcuts that show up later as bad data.
The window closes at go-live
Every conversation I have about ERP migration master data starts six months before cutover and ends three months after, and the trajectory is the same. Pre-cutover, there is funding, attention, and project momentum. The data steward gets called into meetings. The CFO is interested. Post-cutover, the project closes, the contractors leave, and master data goes back to being something nobody owns.
The migration is the leverage. It is the only window where the business will pay for the cleanup that should have happened five years ago. Use it for what it is actually worth: not for moving rows from one place to another, but for putting master data under governance so the next system finds it ready.
Common questions
Should master data cleanup happen inside the new ERP or outside it?
Outside. If the cleanup happens inside the new ERP, you are editing live production data with a deadline, no review gate, and no easy rollback if a merge goes wrong. The pattern that works is a master data layer outside both ERPs: extract the legacy records, cleanse and approve everything there, then publish the governed records into the new ERP. The cleanup runs against a stable environment, has an audit trail, and survives the migration as the system of record.
What master data decisions cannot be deferred during an ERP migration?
Three. Which legacy ID survives the migration and how downstream systems are mapped to it. What fields the new ERP requires that the legacy data does not have, and who in the business will fill them in. How country codes, currencies, GL accounts, and product hierarchies reconcile to the new ERP’s expected lists. If any of those are still open when extract starts, the migration is already behind.
Why is ERP migration the right time to fix master data?
Because it is the only window where finance, operations, and IT all agree the data needs to be fixed. Before the migration, master data is a chronic complaint nobody funds. After the migration, the project closes, the contractors leave, and master data goes back to being something nobody owns. The migration is the leverage. Use it for the underlying cleanup, not just for moving rows from one system to another.
What should the master data scope be for a first ERP migration phase?
One domain. Pick the one that hurts most. For an S/4HANA migration that is usually customers, because customer master data is what finance reconciles and finance is funding the project. Stand up the master data system, configure entities for that one domain, extract, cleanse, approve, publish. Expand to the second domain while the first is already in production. Trying to clean every domain in parallel during the migration crunch is the failure mode.
A governance layer that outlives the next ERP
Primentra runs on SQL Server, supports approval workflows and full audit trails, and publishes governed master data via integration views and REST APIs to whatever ERP, warehouse, or BI tool needs it. The 60-day trial covers everything, including the import wizards for moving legacy records in.