Your CRM says 3,200 customers. Your ERP says 4,100. Your finance team has a spreadsheet with 2,800. Your marketing platform has 5,600 — but half are duplicates from a trade show three years ago. Which number is right?
Nobody knows. That's not a data problem — that's a decision-making problem. And it's exactly what master data management is designed to fix.
What is master data?
Before you can manage master data, it helps to understand what separates it from the rest of your data.
Master data is the core reference data your business runs on. It's your list of customers, the products you sell, the locations you operate from, the suppliers you buy from. It doesn't change much — and when it does, that change has to ripple everywhere. Everything else — orders, invoices, deliveries, support tickets — points back to it.
Think of it this way: a sales order is a transaction. It captures what happened. But the customer on that order, the product being sold, the warehouse it ships from — those are master data. If your master data is wrong, every transaction built on top of it is wrong too.
Master data examples
Here's what master data looks like across common business domains:
| Domain | Examples | Referenced by |
|---|---|---|
| Customer | Names, addresses, tax IDs, contact details | Orders, invoices, contracts, support tickets |
| Product | SKUs, descriptions, categories, unit of measure | Sales orders, inventory, procurement, pricing |
| Location | Branches, warehouses, cost centers, regions | Logistics, HR, finance, operational reporting |
| Supplier | Vendor names, payment terms, risk categories | Purchase orders, accounts payable, compliance |
| Employee | Org chart, job roles, cost center assignments | Payroll, HR systems, access permissions |
| Chart of Accounts | GL codes, account types, reporting hierarchies | Finance, ERP consolidation, regulatory reporting |
What is master data management?
So what is master data management, exactly? At its core, master data management (MDM) is the process of creating and maintaining a single, authoritative version of your core business data across all your systems.
That sounds straightforward. The problem is that master data almost never lives in one place. Your CRM has customer records. Your ERP has customer accounts. Your billing system has client profiles. Each was set up at a different time, by different teams, with different conventions. Over years, they drift apart. The same customer ends up as three records, each with a slightly different name. One address is outdated. The VAT number is missing on two of them.
MDM solves this by establishing one authoritative source — the golden record — and making every downstream system pull from it. When a customer address changes, it changes once, in the MDM system, and that change propagates everywhere. No manual updates in three separate tools. No version conflicts.
The golden record, explained plainly
The golden record is the single, verified, canonical version of a master data entity. For a customer, that means one record with the correct legal name, the correct address, the correct tax ID — and that record is what every other system treats as true.
The golden record isn't a magic merge of all your existing records. Before you can maintain one, you have to clean up the mess you already have — that's a migration project, and it's real work. But you only do it once. Going forward, new entities go into the MDM system first, get validated, and are distributed to downstream systems. Not the other way around.
That shift in direction — MDM as the source, not the consumer — is the fundamental change MDM requires. It's not a technology problem. It's a process and governance change. The tool just makes it easier to enforce.
Why MDM matters more now than it did five years ago
For most of the last decade, imperfect master data was an annoyance. Reports were off by a few percent. The quarterly data cleanup took a week. Annoying, but survivable.
Two things have raised the stakes:
AI initiatives are failing on dirty master data. Demand forecasts, customer segmentation models, product recommendation engines — they all break down when the underlying reference data is inconsistent. You can't train a model on a product catalog with 40% duplicate SKUs. AI doesn't fix bad data. It scales it. If your master data is inconsistent, your AI investment produces confident wrong answers at machine speed. The AI without master data management post goes deeper on this failure pattern.
Compliance requirements have sharpened. GDPR, DORA, NIS2 — regulators expect you to know exactly what customer data you hold, where it lives, and how to locate and delete it on request. That's nearly impossible if the same customer exists as four records across three systems, each with partial information.
Do you actually need MDM software?
Honest answer: it depends. Here's a rough guide based on what I've seen in practice:
| Your situation | Recommendation |
|---|---|
| One system, data lives entirely in your ERP | Your ERP is your MDM. No separate tool needed. |
| 2–3 systems, fewer than 500 records per entity, low change frequency | A well-governed spreadsheet can work. Consider a purpose-built tool when it starts breaking down. |
| Multiple systems, thousands of records, regular updates by multiple people | Purpose-built MDM tool. Not enterprise scale — lightweight tools exist and cost a fraction of the alternatives. |
| Large enterprise, multiple data domains (customer + product + location) | Full MDM platform with dedicated data stewards. Budget and timeline accordingly. |
Most MDM vendors are selling to Fortune 500 procurement teams. If you're a 200-person manufacturer or a regional distributor, Informatica and SAP Master Data Governance are built for a different problem at a different budget. You don't need them. For most organizations in that range, the tool just needs to be simple, store data in SQL Server, and not require a consultant to operate. Our mid-market MDM guide covers the full landscape for companies in this range.
What MDM looks like in practice
A practical MDM implementation doesn't have to be a multi-year program. Start with one domain, get it right, then expand. Here's the general path:
Customer, product, or location — whichever causes the most pain. Don't try to do everything at once. One clean domain delivering real value beats five half-finished domains delivering none.
What attributes does a golden record in this domain actually need? Code, name, and the fields your systems actually use. Keep it minimal. You can always add attributes later — removing them is harder.
Migrate your existing data. Deduplicate, merge, clean. This is a one-time data project and usually involves judgment calls. Automate what you can, but accept that someone needs to make the hard decisions.
Who can create new records? Who approves changes to sensitive fields? Even one named data steward per domain and a simple approval workflow is enough to start.
Point your ERP, CRM, and reporting tools to pull reference data from the MDM system. Eliminate local copies. This is where the value compounds — every system sees the same data.
The golden record stays golden only if it's maintained. MDM is an ongoing process, not a project with an end date. Build that expectation into how you staff and resource it.
A word on Microsoft MDS
For years, many mid-size organizations handled their master data using Microsoft Master Data Services (MDS) — a tool bundled with SQL Server Enterprise. It was free if you already had the license, which is mostly why anyone used it. It wasn't elegant, but it stored everything in SQL Server — which meant IT could manage it without calling a vendor. That was worth a lot.
Microsoft removed MDS from SQL Server 2025. Organizations that relied on it are now evaluating alternatives — ideally something that still lives on their own SQL Server, doesn't cost a fortune, and doesn't need a three-month implementation. If that's your situation, our breakdown of why MDS failed and our migration guide are worth reading next.
If you're evaluating what replaces MDS — or just trying to get your master data into a single, manageable place — Primentra runs on your own SQL Server, deploys in an afternoon, and doesn't need a consultant to operate. Try it free for 60 days.
- No cloud migration — stays on your own SQL Server
- No professional services required — self-service from day one
- No credit card for the trial