Master Data Management (MDM) Explained

Master data management (MDM) is the discipline of keeping one agreed, trusted record for each of the core entities a business runs on: customers, products, suppliers, employees, locations and the chart of accounts. Most organizations hold these in several systems at once (CRM, ERP, e-commerce, support desk, payroll), and the copies drift apart. MDM decides which attributes matter, who owns them, how duplicate records are matched and merged into a golden record, and how that record flows back to the systems that need it. You need it when the same customer appears three ways, when product data is re-keyed by hand, or when two reports cannot be reconciled because every system counts differently.

What master data is (and is not)

Master data describes the things a business transacts with; it changes slowly and is referenced everywhere. Transactional data records events (an order, an invoice, a shipment, a visit) and references master data. Reference data is the small controlled lists both of them use (country codes, units of measure, payment terms). Confusing the three is the first mistake in most MDM projects, because each needs different handling.

Type	What it describes	Examples	Rate of change	Managed by
Master data	The entities you do business with or about	Customer, product, supplier, employee, site, asset, account	Slow	MDM, with a named owner per domain
Transactional data	Events that reference master data	Orders, invoices, payments, shipments, tickets, encounters	Constant	The operational system that creates it
Reference data	Controlled lists and codes	Country and state codes, currencies, units, status values, ICD-10 codes	Rare	A reference data owner; often bundled with MDM

Each master data domain has a small set of attributes that must be right everywhere. For a customer that is usually legal name, tax ID, billing and shipping addresses, primary contact, payment terms and status. For a product it is SKU, description, unit of measure, dimensions and weight, category, and the identifiers partners use (GTIN, supplier part number). The golden record is the single best version of those attributes, assembled from the copies according to rules you write down.

Three examples of what this looks like. A twenty-person distributor keeps customers in QuickBooks Online and HubSpot; the golden record is a small table that says which system wins for which field. A 400-person manufacturer runs Dynamics 365 Finance and Supply Chain Management, Salesforce and a product information management tool; product master data is authored once and syndicated to the web store and the EDI partners. A division of a global group on SAP S/4HANA with several regional CRMs needs a hub that reconciles customers across regions and feeds a group-wide warehouse.

Symptoms that mean you need MDM

MDM is a response to specific pain, not a program to start because the term exists. These are the signals we see most often.

• The same customer exists several times in the CRM, with different spellings, owners and credit limits, and sales and finance each trust a different one.
• A SKU is active in the ERP, discontinued on the web store and priced differently in the quoting tool.
• Supplier onboarding means re-keying the same bank and tax details into procurement, accounts payable and the compliance system.
• Revenue by customer differs between the sales dashboard and the general ledger, and reconciling it is a monthly manual job.
• An acquisition brought a second ERP and a second customer list, and nobody can say how many customers the combined company has.
• A new channel (marketplace, mobile app, partner portal) needs product and customer data that no single system can supply cleanly.
• An AI or analytics project stalls at entity resolution: the model cannot tell which records refer to the same person, product or site.
• A regulation or contract requires one accurate record per person (consent, know-your-customer rules, patient identity).

If two or more of these apply, the cost of not doing MDM is already on your books as duplicate mailings, rejected orders, failed integrations and hours of reconciliation. Many of these symptoms are also data quality problems; MDM is the structural fix for the subset caused by the same entity living in more than one place.

MDM implementation styles

There are four recognized styles, and the choice decides most of the cost. The styles differ in where the golden record lives and whether changes flow back to the source systems.

Style	How it works	Write-back to sources	Effort	Fits when
Registry	The hub stores only identifiers and cross-references; it matches records across systems and points to the best source for each attribute at read time	No	Lowest	You need a single view for reporting and search without changing source systems
Consolidation	The hub copies records from sources, matches and merges them into a golden record used downstream (warehouse, BI, AI)	No	Low to moderate	Analytics and reporting are the main consumers; sources keep operating as they are
Coexistence	Golden records are built in the hub and published back to source systems, which keep authoring locally within rules	Yes	Moderate to high	Several systems must create and update the same entities and stay in sync
Centralized (transaction hub)	The hub is the only place master data is created or changed; sources subscribe to it	Sources read only	Highest	Regulated or high-volume environments where one authoring point is worth the process change

Most organizations start with consolidation because it needs no change to the systems people work in every day, and it fixes reporting first. Coexistence comes next when the duplicates in the CRM itself start to hurt. Centralized authoring is a process change as much as a technical one, and it only sticks when a business owner is ready to run a stewardship queue.

Whichever style you pick, the design work is the same: define the domain and its critical attributes, choose matching rules (deterministic on tax ID or email, probabilistic on name plus address plus phone), set survivorship rules that say which source wins per attribute, and design the stewardship queue where a person reviews uncertain matches. That design, with the owners who approve it, is master data governance, and it is what makes the tool choice secondary.

Master data management tools

Tools range from a few SQL scripts to multi-domain platforms. The table groups them by the kind of team that typically uses them.

Tool	Type	Notes
SQL Server Master Data Services (MDS)	Microsoft, on-premises	Entity modeling, business rules, an Excel add-in for stewards. Still shipped with SQL Server; check Microsoft’s current documentation before starting a new build on it.
Dynamics 365 and Dataverse	Microsoft, cloud	Dual-write keeps customers, products and vendors aligned between Dynamics 365 Finance and Supply Chain and Dataverse apps; Customer Insights unifies customer profiles for marketing and service. Not a general MDM hub, but often enough inside a Microsoft estate.
Profisee	Commercial platform	Multi-domain MDM designed around the Microsoft stack, with Purview and Fabric integration.
Informatica MDM (Cloud)	Commercial platform	Multi-domain, strong matching and data quality, broad connectors; common in larger estates.
SAP Master Data Governance (MDG)	Commercial platform	Native governance for business partner, material and finance master data in SAP S/4HANA environments.
Semarchy xDM, Reltio, Stibo Systems, Ataccama ONE, TIBCO EBX	Commercial platforms	Multi-domain hubs with stewardship workflow; Stibo is strong in product and supplier data.
Pimcore, Akeneo	Open source (community editions)	Product information management with MDM features; a fit for product-heavy companies with developers.
Warehouse-native MDM with dbt plus Splink or the dedupe library	Open source, build your own	Probabilistic record linkage in Python over Snowflake, Databricks or SQL Server, with golden records published as warehouse dimensions.

Catalogs and governance platforms (Microsoft Purview, Collibra, Alation, Atlan) are often mentioned alongside MDM, but they inventory and document data rather than merge it. Our comparison of data governance tools explains where each one stops and MDM begins.

Right-sized MDM

MDM has a reputation for multi-year programs because large companies run it that way. The discipline scales down. We think of it as three levels, and most organizations should stay at the lowest level that removes their symptoms.

Level 1: governance-only MDM

No new software. For each domain, name the system of record and the owner, write entry standards (required fields, pick lists, naming conventions, duplicate check before create), and run a quarterly deduplication using the CRM’s own merge tools or a spreadsheet. A founder or a twenty-person company is usually done here, and many larger companies should start here too.

Level 2: warehouse MDM

Consolidation style, built in the data platform you already have. Pipelines (Azure Data Factory, Fabric, Fivetran) land each source; dbt models standardize addresses and names; a matching step (deterministic rules, or Splink for probabilistic matching) assigns a master ID; survivorship rules build the golden customer or product dimension. BI, finance reconciliation and AI projects read the golden record, and a steward reviews uncertain matches in a simple app or sheet. This is the sweet spot for growing companies on Snowflake, Databricks, SQL Server or Fabric.

Level 3: hub with write-back

Coexistence or centralized style on a packaged platform, with stewardship workflow and publication back to the ERP, CRM and e-commerce systems through APIs or an integration layer. Justified when several systems author the same entities, when the volume of changes needs a queue, or when regulation requires a controlled authoring process.

Whatever the level, measure the same things: duplicate rate per domain, number of records with incomplete critical attributes, match review backlog, and the hours finance and operations spend reconciling. Those numbers tell you when to move up a level, and when you can stop. The ownership and definitions that make any level work come from a wider data governance program, even a light one.

Where PS3G fits

PS3G provides master data management services for organizations of every size, as part of data governance services: domain and attribute definitions, matching and survivorship rules, stewardship design and the owners who make it stick. Our data engineering team builds the level-2 warehouse pattern on SQL Server, Snowflake, Databricks or Microsoft Fabric, and implements Dynamics 365 dual-write, Profisee, Informatica or SAP MDG when a hub is justified. We run our own software products, so we have lived with customer and reference data drifting across systems and know which fixes hold. A small company usually needs level 1 and a few pipeline rules; a larger one usually needs the warehouse pattern built and handed over with a steward trained.

Related reading

• What Is Data Governance? A Plain-English Guide for Growing Companies
• Data Quality Management: Dimensions, Rules, Tools and Process
• Data Governance Tools Compared: Purview, Collibra, Alation, Atlan
• Data governance services

Frequently asked questions

What is master data management in simple terms?

Master data management keeps one trusted record for each customer, product, supplier, employee or location, even though those entities live in several systems. It defines which attributes matter, who owns them, how duplicate records are matched and merged, and how the resulting golden record reaches the systems and reports that need it. The goal is that every system and every report describes the same real-world thing the same way.

What is a golden record?

A golden record is the single best version of a master data entity, assembled from the copies held in different systems according to survivorship rules. For a customer it might take the legal name from the ERP, the email from the CRM and the shipping address from the most recent order. It carries a master ID that the source records are linked to, so changes can be traced and reconciled.

Does a small business need MDM?

A small business needs the discipline, not the platform. Naming a system of record per domain, setting entry standards, checking for duplicates before creating records and deduplicating quarterly removes most of the pain at no license cost. Software becomes worthwhile when several systems create the same entities, when volumes outgrow manual review, or when analytics and AI projects need reliable entity matching.

Which MDM style should we start with?

Consolidation, in most cases. It builds golden records in the warehouse for reporting and analytics without changing the systems people work in, so it delivers value early and carries little risk. Move to coexistence when duplicates inside the operational systems themselves cause problems, and to centralized authoring only when a business owner is ready to run a stewardship process for every change.

What is the difference between MDM and a data warehouse?

A data warehouse stores history for analysis; it copies master and transactional data from many sources and organizes it for reporting. MDM decides what the correct version of each master entity is and, in the richer styles, pushes that version back to the operational systems. A warehouse without MDM reports on duplicates faithfully; MDM is what makes the customer dimension in the warehouse count each customer once.

What is master data governance?

Master data governance is the set of decisions and roles around master data: which domains and attributes are governed, who owns each one, what the definitions and entry standards are, how matching and survivorship rules are approved, and who works the stewardship queue. It is the part of MDM that does not depend on software, and it is the part most failed MDM projects skipped.