What Is Master Data Management (MDM)?

Your CRM says the customer is on the Free plan. Stripe says they upgraded to Team three weeks ago. The support dashboard shows the billing email on a different domain than marketing has in Mailchimp. These are not five different customers. They are five views of the same person, stored in five tools, and every tool is confident its version is correct. That drift has a name: master data management is the discipline that stops it.

The standard definition covers core business records of every kind: customers, products, suppliers, employees, locations. Every MDM guide published by enterprise vendors treats the fix as a platform purchase. Stand up a hub, hire stewards, convene a governance council, run a twelve-month rollout. For a team of 15 using Stripe, HubSpot, and Intercom, that is wildly disproportionate. The actual problem is that those three tools do not talk to each other.

If you are running a small team, you already have a governance layer, or you need one. The pillar piece in our cluster on customer data governance covers the audit trail and change attribution side of the story. This article is about the vocabulary and the architecture choices. What MDM actually is, why enterprises built platforms for it, and what the equivalent looks like when you have 10 SaaS tools instead of 300.

What is master data management, and why your tools need it

Master data is the shared backbone of a business. A record that multiple systems need to reference: the customer, the product SKU, the vendor, the employee, the location. Transactional data (an order, a support ticket, a Slack message) is disposable and instance-specific. Master data is the stable reference that transactional data points to.

MDM data management, then, is the set of practices and tools that keeps those reference records consistent. What is MDM in more formal terms? The Wikipedia definition of master data calls it "a technology-enabled discipline in which business and IT work together to ensure the uniformity, accuracy, stewardship, semantic consistency and accountability of the enterprise's official shared master data assets." Fair enough for the Fortune 500. Most teams will never see 80% of that sentence in practice.

The problem MDM solves is simpler than the vocabulary suggests. When multiple systems store their own copy of the same entity, those copies drift. Somebody updates a phone number in HubSpot. Somebody else corrects a company name in the billing tool. Three weeks later, nothing matches. Decisions get made on whichever copy happened to be open on the analyst's screen that day.

For consumer packaged goods companies, product MDM is the expensive version of this problem. For software companies, it is almost always customer data. Same pattern, different entity.

How traditional master data management platforms work

The classic MDM architecture, the one sold by Informatica, Boomi, SAP, and IBM, has four moving parts:

• A master data hub. A central database that holds the canonical version of every entity. Every source system writes into it and reads back from it.

• Matching and merging logic. Rules that decide when two records are the same person. Usually a mix of deterministic matching (exact email, exact tax ID) and probabilistic matching (fuzzy name match plus similar address).

• Data stewards. Humans who review edge cases the matching logic cannot resolve confidently. They own the golden record.

• A governance framework. Policies that decide who can change what, how disputes get resolved, and how new source systems get onboarded.

This works. It also costs a lot. McKinsey's research on MDM notes that many large enterprises spend "one or more days per week" resolving data quality issues even with MDM programs in place, and that only 29% have full integration between source systems and business applications. Those numbers are for companies that bought the platforms. The implementation projects run 6 to 18 months. The platform licenses start at six figures. You need a data governance council and at least one full-time data steward per major domain.

None of this is wrong for a 10,000-person enterprise with 300 internal systems, acquisitions to integrate, and GDPR regulators on speed dial. It is wildly wrong as a template for a 30-person company with HubSpot, Stripe, Intercom, and a Postgres database.

Master data management vs. customer data management vs. data governance

The three terms overlap enough that vendors use them almost interchangeably in marketing copy, which does not help.

If you care only about the customer entity, customer data management is the narrower version of MDM. If you care about product catalogs, supplier lists, and employee records as well, you are doing MDM. Data governance is the rulebook underneath; it is not a replacement, it is a prerequisite.

Most 10-to-200-person SaaS companies only have one master data domain that actually matters: the customer. Product SKUs and suppliers do not create cross-tool inconsistencies in the same way. That narrows the scope dramatically.

A master data management strategy without an enterprise platform

Here is the shift that the enterprise MDM literature does not acknowledge: if you have 10 SaaS tools and one database, you do not have a master data storage problem. You have a master data sync problem.

The traditional hub exists because you cannot make hundreds of mainframe systems, ERPs, and acquired legacy databases talk directly to each other. The hub is a forcing function. Everything goes through the hub, so everything stays consistent. But between HubSpot, Stripe, and Intercom there are no mainframes. There are REST APIs, webhooks, and reasonably well-documented object models. Those tools can talk to each other directly, if something keeps them in sync.

A small-team MDM strategy is really four decisions:

• Pick the source of truth per field. Plan status lives in Stripe. Account owner lives in HubSpot. Company name lives wherever sales enters it. Write this down once; it is the hardest part of the whole exercise.

• Decide your matching key. For customer data, email is usually deterministic enough. For B2B, you often need a combination: email domain plus company name, or an external CRM ID.

• Configure bidirectional sync between tools. Not a one-way ETL into a warehouse. Actual two-way sync with field-level change tracking, so edits propagate.

• Keep an audit trail. Know what changed, when, where it originated, and what the prior value was. This is the governance layer.

Nothing in that list requires a Master Data Hub. It requires a sync tool that understands per-field ownership, deterministic matching, and change tracking. We wrote separately about the governance piece on our customer data governance page. The sync piece is what the rest of this article is about.

Here is the version of this that nobody selling MDM software will put in their marketing copy. If your MDM problem is that HubSpot and Stripe disagree about the same customer, buying Informatica to solve it is like buying a freight train to commute to work. It will technically get you there.

Master data management tools: three approaches

There are roughly three categories of MDM tools on the market, and they are genuinely different products solving overlapping problems.

Enterprise MDM software. Informatica MDM, Boomi Master Data Hub, SAP Master Data Governance, IBM InfoSphere. Built for hundreds of systems, regulated industries, multi-domain use. Strong matching engines, stewardship workflows, lineage tracking. Expensive, long implementations, data-team-dependent. Appropriate when the cost of a wrong customer record is legal exposure or a seven-figure supply chain error.

MDM-as-a-service. Newer cloud platforms positioning as lighter-weight MDM: Reltio, Stibo Systems Step, Semarchy. Shorter implementation times, subscription pricing, still aimed at mid-market and up. They assume you want a hub; they just make standing one up less painful.

Direct tool-to-tool sync with matching. Tools like Oneprofile, and to some extent platforms like Zapier or Make when you squint very hard. No hub. Records stay in the source tools. A sync engine matches, merges, and propagates changes between tools directly. Right approach when your master data is mostly customer data and mostly lives in SaaS tools.

These categories are not competing for the same buyer. Informatica is not trying to sell to a 20-person company, and no reverse-ETL vendor has built a lineage catalog that will pass a pharmaceutical audit. The mistake is assuming that because the enterprise platforms exist, the smaller team needs a scaled-down version of the same shape. Often what they need is a different shape entirely.

When you actually need an MDM platform (and when sync is enough)

There are MDM use cases where direct sync is not enough and you really do need the hub.

• You are in a regulated industry (finance, pharma, healthcare) with explicit data lineage requirements.

• You manage product master data across dozens of internal systems, not just SaaS tools.

• You are post-merger and need to reconcile master records across acquired entities with different schemas.

• You need a data stewardship workflow where humans review and approve record merges before they propagate.

• You have hundreds of source systems, not tens.

If none of those apply, and your master data is mostly the customer entity, mostly in 10 to 20 SaaS tools, and you are a team of 5 to 200, you probably do not need a Master Data Hub. You need your tools to agree with each other.

The benefits of MDM do not come from the hub. They come from having a consistent version of the customer everywhere the customer is referenced. The hub is one way to get that. Direct bidirectional sync with field ownership, deterministic matching, and an audit trail is another. Pick the one that matches the size of the problem.

One last thing, and this is the part that will not age well: most of the MDM content on the internet was written by platform vendors who sell hubs. The market has been telling small-to-mid-market teams for fifteen years that they need a scaled-down version of enterprise MDM. They mostly do not. What they need is better plumbing between the tools they already run, and a clear answer to "which tool owns this field." That is not a platform category yet. Give it a few years.