You need master data management when the same business entity lives in two or more systems that can each change it independently, and nothing decides which version is right. That is the whole test. Not headcount, not row counts, not whether you feel mature enough as an organisation. Count the systems that can write the same record, then ask what resolves a disagreement between them.
If exactly one system owns each entity, you do not need MDM — you already have it, and it is called your ERP. If several systems own it and the tiebreaker is that somebody eventually notices, you have a master data problem regardless of how big you are.
Why the usual test is wrong
Almost everything written about this frames the answer as size. Over some number of employees or records, you have graduated to needing MDM. It is a convenient story for vendors because it makes the purchase feel like a milestone, and it is wrong often enough to be actively misleading.
I have seen a 150-person distributor with a genuine, expensive master data problem: an ERP, a CRM, a webshop, and a warehouse system, all holding customers, all editable, all disagreeing. And I have seen companies several times that size where one ERP owns everything and the answer to “which system is right” is instant and unanimous. The second company does not need MDM. Size correlates with the problem, because bigger companies accumulate systems and acquire other companies, but it does not cause it. Split authority causes it.
The two questions
Take one entity. Customers is usually the clearest, but suppliers or products work. Then answer honestly:
1. How many systems hold this entity and can change it independently? Not how many read it — how many can create a record or edit a field without asking anything else. A dashboard reading from the ERP does not count. A webshop where marketing can add a customer does.
2. When two of them disagree, what decides? There are only three real answers. A rule exists and is enforced by software. A rule exists on paper and people mostly follow it. Or somebody notices during a month-end and fixes it by hand.
Four cases where the answer is no
We sell an MDM tool, so treat the following with appropriate suspicion — but these are the situations where we would tell you not to buy one, because you would be paying to solve a problem you do not have.
One system genuinely owns it. Your ERP holds customers, everyone accepts that, and other systems read from it. That is a complete master data strategy. It is the single-system version, and it is the cheapest one that works. Adding a layer above it moves the authoring somewhere new without removing any risk.
The data is small and has one real owner. Four hundred cost centres maintained by one person in finance who has done it for years does not need a platform. It needs a backup and a named successor. A governed list in one place is proportionate. Our post on where Excel stops working is fairly clear that below a certain point it has not stopped working.
Your reports disagree but your systems do not. This one gets misdiagnosed constantly. If finance and sales quote different revenue numbers but the underlying operational records are consistent, that is a definitions and warehouse problem. You need agreement on what “active customer” means and one modelling layer, not a master data hub.
All the duplicates come from one system. If every duplicate supplier was created in the ERP by people who did not search first, the problem is that ERP's intake process. A required search step and some validation on the creation form will fix more than a platform will, and cost a fraction. That is the creation-side fix rather than a tooling one.
What people mean when they say “we need MDM”
The phrase gets used for four distinct problems, and only one of them is actually MDM.
The catalog confusion is worth its own warning, because it is the one Microsoft's own guidance encourages — we took it apart in MDM is not a data catalog.
The signals you have already crossed the line
Most organisations do not decide they need MDM. They accumulate evidence and then eventually name it. The evidence usually looks like this:
- Somebody reconciles two systems by hand on a recurring schedule, and it is in nobody's job description.
- Creating a new supplier or product involves email, and takes days rather than minutes.
- A question like “how many active customers do we have” produces different answers depending on who you ask, and everyone has stopped finding this strange.
- You have acquired a company, and nobody has decided whose customer list wins.
- An integration project keeps stalling on mapping, because the two sides disagree about what a record even is.
- One person is the reason the data is correct, and they are going to retire.
If you are borderline
Do the cheap thing first. Pick the entity that hurts most — usually suppliers or customers — and try to make one system authoritative for it. Decide who owns it, turn off creation in the other systems, and have them read from the owner. If that works, you are done and you have spent nothing.
It often does not work, and the reason is usually political rather than technical: two departments both need to create records and neither will give it up, or the system that ought to own it has an interface nobody outside IT can use. That failure is informative. It tells you the authority genuinely is distributed, which is exactly the condition MDM exists for — a neutral place to hold the record that is not any one department's system.
Where we fit, and where we do not
Primentra is for the case where several systems hold the same entity, you want one governed place to author it on your own SQL Server, and you need stewards to work in something that behaves like a spreadsheet without being one. Controlled values, approval on the fields that carry risk, a full change log, and integration views the other systems read.
It is not the answer if you need probabilistic matching across millions of records from a dozen acquisitions — that is enterprise MDM territory. It is also not the answer if one system already owns your data cleanly, and we would rather say so now than during an implementation. If you are trying to place yourself by segment rather than by symptom, the mid-market gap covers that angle.
Frequently asked questions
How do I know if I need master data management?
Ask two questions. How many systems hold the same entity and can change it independently? And when two of them disagree, what decides which is right? One system means you do not need MDM. Two or more, resolved by someone noticing eventually, means you do. Split authority over the same record is the test, not company size.
When do you not need MDM?
When one system genuinely owns each entity and everyone accepts it. When the data is small with one real owner. When your reports disagree but the operational systems do not — that is a warehouse and definitions problem. And when every duplicate originates inside a single system, where the fix is that system's intake process.
Is MDM only for large enterprises?
No. Size correlates because larger companies accumulate and acquire systems, but it does not cause the problem. A 150-person company running an ERP, CRM, webshop and warehouse system that all hold customers has real split authority. A 3,000-person company with one authoritative ERP may not need MDM at all.
What do people confuse with needing MDM?
Consistent reporting (a warehouse and definitions), knowing where data lives (a catalog), fewer typos in one system (that system's validation), and systems exchanging data (integration). MDM is specifically for deciding the correct value when multiple systems can each write their own version.
If you counted more than one system
Primentra gives the contested entity one governed home on the SQL Server you already run, with stewardship, approvals and a change log. Take the entity that hurts most into the 60-day trial and see whether one authoritative version actually holds. If it turns out you did not need us, that is a good outcome too.