Cleansing master data before an ERP migration: how to proceed?

Master data is cleansed in five steps: measure the current state, define the rules, remove duplicates and dead records, fill in mandatory fields, and anchor the rules permanently with named owners. The order is decisive: derive the target rules from the future processes first, then cleanse. Scrubbing without rules puts you back in the same state within two years.

1. Measure the baseline. Customers without revenue, items without stock movement, duplicate suppliers, empty mandatory fields: four numbers per data object are enough.
2. Define the rules. Uniqueness, mandatory depth, naming conventions, life cycle and ownership, derived from the future processes.
3. Clear out duplicates and dead records. Only now, because cleaning without rules leaves you in the same state two years later.
4. Fill in the mandatory fields. Whatever the new system needs is filled before migration, not in live operation.
5. Anchor the rules for good. With named owners for creation and change, otherwise the result will not hold.

Where do you start: how bad is it really?

The first step is an honest stocktake, and it is quickly done: how many customers had no revenue in 24 months? How many items no stock movement? How many vendors exist twice under different spellings? How many mandatory fields are empty or filled with placeholders?

These metrics turn gut feeling into a work list. Typical in the mid-market: 30 to 50 percent of master records are inactive or duplicated. That is no disgrace, it is two decades of lived business. But it is the reason why a migration without cleansing doubles the problems instead of solving them.

Four figures per data object are enough for the assessment: duplicate rate, share of complete mandatory fields, share of inactive master records and the age of the last maintenance. That measurement takes days and regularly changes the project team's own estimate.

By which rules do you cleanse?

The rules come from the future processes, not from the past: which fields does the order process really need? Which dimensions does reporting need? Which item structure does planning need? What nobody needs is not maintained, it is removed.

• Uniqueness: one business partner, one master record, a clear duplicate rule
• Mandatory depth: which fields are required, which optional, which are dropped
• Naming conventions: consistent spelling for names, addresses, units
• Lifecycle: when a master record is blocked, archived, deleted
• Ownership: who creates, who changes, who approves

What matters is that the rules come before the work and exist in writing. Without them, every person decides case by case, and then the cleansing produces a new inconsistency, only this time with the claim of being clean.

DGP keeps these rules on a single page that every editor has in front of them. One sentence per field is enough, what matters is that nobody decides alone when in doubt.

Who does the work, and how much can be automated?

Tools help with finding: duplicate candidates, empty mandatory fields and inactive records can be listed mechanically, these days with AI support too. The decision stays with the business: whether two similar customers are really one is something sales knows, not the script.

A clear division has proven itself: pre-sort mechanically, decide professionally, correct in the legacy system or an interim step. Cleansing thus runs in parallel with the implementation and is one of the few project tasks that can start early, long before the new system exists.

In our experience the detection can largely be automated, the deciding cannot. A tool finds duplicates reliably, but which of the two records is the right one is known only to the business.

That is why the distribution of effort is typically the opposite of what is expected: the technical part is done in days, while the business decisions take weeks and cannot be accelerated.

How does it stay clean once the migration is over?

Without anchoring, the old state grows back, only faster. Cleansing therefore does not end with the migration but with three permanent arrangements: named data owners per object, creation workflows with mandatory fields in the system, and one metric per quarter that keeps quality visible.

That pays twice: clean master data is the precondition for reliable figures and for everything that follows, from process automation to AI agents working on exactly this data foundation. The data foundation stays; systems come and go.

Without that ongoing upkeep, the state is back to the old one after about two years, only that the cleansing then has to run against a productive system and becomes considerably more expensive. The upkeep itself costs a few hours a month, provided it belongs to a person named by name.