By Rahul · 14 Oct 2026 · 7 min readMost mid-sized companies meet master data management the same way: two reports disagree in a board meeting, somebody goes looking for why, and the answer is that the same customer exists four times across three systems with three different credit limits.
The next step is usually a search that leads to Informatica, SAP Master Data Governance, Stibo or Reltio. Those are serious products. They are also built for organisations that employ data stewards full time, and the fit is wrong often enough that it is worth saying plainly: if you are a company of twenty to three hundred people, the enterprise suite is probably not your answer.
Here is what is, and how to tell which situation you are in.
What master data actually is, in your business
Master data is the small set of records that everything else refers to: customers, products, suppliers, locations, employees, and the codes that link them. It changes slowly. Every order, invoice and report depends on it. We cover the wider picture in what enterprise data management means in practice, and the terminology in EDM vs MDM.
Transaction data is different. You have millions of rows of it and nobody argues about them. The arguments are always about master data, which is why fixing a few thousand customer records changes how the whole business feels.
Five signs you have outgrown spreadsheets and goodwill
- Two departments produce different totals for the same month, and the meeting becomes an argument about whose file is right.
- Somebody maintains a "master" spreadsheet that the real systems do not know about, and that person is now a single point of failure.
- The same customer or supplier exists several times, with different spellings, and nobody is sure which record the invoices go against.
- Onboarding a new product or client takes days because the same details are typed into four systems by hand.
- A simple question - how many active customers do we have in Germany - takes a week and still gets a hedged answer.
One of these is annoying. Three or more is costing you real money in hours, errors and decisions made late.
Why the enterprise suites are the wrong shape for most mid-sized firms
This is not a criticism of the software. It is a question of what the software assumes about you.
They assume dedicated people. Enterprise MDM is designed around data stewards who own domains and sit in workflow queues all day. If nobody at your company has "data" in their job title, the governance workflows go unused and you are paying for an empty process.
They assume a long programme. Implementation is measured in quarters and usually involves a consulting partner. A mid-sized business needs the duplicate problem to stop hurting this quarter, not after a two-year programme.
The licence is the smaller number. Across the enterprise MDM market, implementation and ongoing administration routinely cost several times the licence over the first few years. The sticker price is the part you can see.
You pay for breadth you will not touch. Multi-domain governance, hierarchy management, data marketplaces and stewardship consoles are genuinely valuable at the scale they were designed for. At your scale they are weight.
What mid-sized businesses actually need
Strip it back and the requirement is usually five things, none of which needs an enterprise suite:
1. One agreed record, with a rule for conflicts
For each core record type, a single place that holds the truth and a written answer to "when two systems disagree, which wins, and on which field?". Sales may own the contact details while finance owns the billing name. That decision takes an afternoon to make and saves months of argument.
2. Validation at the point of entry
Required fields, format checks, controlled lists instead of free text, and duplicate detection at the moment of saving. This is the part people skip, and it is the part that decides whether you are doing this once or every two years. A cleanup without entry rules is a cleanup you will repeat.
3. A deduplication pass you can audit
Fuzzy matching to propose merges, a human to approve them, and a record of what was merged into what, so a merge can be explained or reversed. Automatic merging with no audit trail creates a worse problem than the one it solves.
4. Sync outward through APIs
The master record feeds your CRM, accounting system, website and whatever else, on a schedule or on change, with an error log a human actually reads. Spreadsheet exports passed between teams are not integration; they are a delay with a filename.
5. Permissions and an audit trail
Who may create a record, who may approve a change to a price or a credit limit, who may delete, and who gets told when any of that happens. Role-based permissions plus an audit log deliver most of the practical value of a governance programme without the committee.
That is a tailored platform built around your actual records. It is the shape of system we build as an Enterprise Data Management platform, and it typically takes a first phase of ten to twelve weeks rather than a multi-year programme.
What a sensible first phase looks like
Narrow, and it finishes. One record type - usually customers or products, whichever causes the most arguments.
Weeks 1 to 3: audit the systems in scope and count. How many records, how many duplicates, how many rows missing a country or a tax code. The output is a short document with numbers in it, not a slide about data maturity.
Weeks 4 to 6: agree the golden record and the conflict rules, with the people who actually create and use the records in the room. List the integration points.
Weeks 7 to 11: build, dry-run the migration against a copy, reconcile counts on both sides, correct, and test with the real team. Our data migration checklist covers the steps that get skipped.
Week 12: go live for that record type, with the old source readable but read-only for a defined period.
Then widen, once the first one is stable and trusted. One record type done properly beats a platform that covers everything and is trusted by nobody.
How to build the business case
You do not need a theoretical ROI model. Count three things for one month:
- Hours spent reconciling figures that should already agree.
- Errors that reached a customer or an invoice because of a wrong or duplicate record.
- Decisions that were delayed because nobody trusted the number.
Put a cost against those and compare it to a first phase. If the phase cannot pay for itself inside two years on that evidence alone, you have picked the wrong first phase - pick the record type that hurts more.
When you genuinely do need the enterprise suite
Being honest about this matters, because the wrong advice here is expensive in both directions. Go enterprise when several of these are true: you have tens of millions of master records; you operate in a regulated industry with formal data lineage requirements; you already employ data stewards; you need multi-domain governance with complex approval hierarchies across many business units; or a parent company has standardised on a platform and you have to fit in.
If none of those apply, a tailored platform will be faster to adopt, cheaper to own and far easier to change when the business changes.
Where to start this week
Pick the record type that causes the most arguments. Export it from every system that holds it, and count the duplicates. That one number, in front of the people who sign things off, usually makes the rest of the conversation straightforward.
If you want a second opinion on what you find, or on a proposal already on your desk, send it over and we will tell you honestly whether it needs a platform or just better rules.