Master data management: a practical guide

Ask three systems in the same company for customer C-1042 and you often get three different answers. The ERP has the legal name and the VAT number. The CRM has a newer phone number and a different contact person. The e-shop has the customer twice, once with a personal email and once with a work email, and neither knows the customer is the same company that pays invoices in the ERP.

None of these systems is wrong on its own. The problem is that nobody owns the question “who is this customer, really?” Master data management (MDM) is the discipline, and the tooling, that answers it. This guide explains the core ideas, the main architectural styles, when you need a dedicated MDM product and when you don’t, and how to compare tools.

Master data vs transactional data

Master data describes the things your business deals with: customers, suppliers, products, materials, locations, employees. It changes slowly, it is shared by many systems, and errors in it spread everywhere.

Transactional data records what happens to those things: orders, invoices, payments, shipments, tickets. It is created in high volumes, usually belongs to one system, and refers to master data (“invoice 2026-0815 for customer C-1042, product SKU-778”).

The distinction matters because the two need different treatment. Transactions are moved between systems by application integration flows. Master data also has to be moved, but first it has to be agreed: which record is the correct one, and which value wins when systems disagree.

The building blocks

The golden record

The golden record is the single, trusted version of an entity, assembled from all the systems that know about it. It keeps links to the source records it was built from, so you can always answer “which ERP code and which CRM ID belong to this customer?”

Matching

Before you can merge records, you have to find out which ones describe the same thing. Matching compares incoming records against existing ones using rules:

Exact rules, such as “same VAT number” or “same email address”. Fast and safe, but they miss typos.
Fuzzy rules, such as “similar name and same postcode”. They catch “Papadopoulos SA” and “Papadopoulos S.A.”, but they can also produce false matches, so they need thresholds and review.

Most real setups combine both: an exact rule on a strong identifier first, then fuzzy rules as a fallback.

Merging and survivorship

When two or more records match, the system has to decide which value of each field goes into the golden record. Those decisions are survivorship rules. Common ones are:

Source priority: for the legal name and VAT number, trust the ERP; for the phone number, trust the CRM.
Most recent: take the value that was updated last.
Most complete: prefer a value over an empty field.

Survivorship is usually decided per field, not per record. That is the part business people underestimate most.

Data quality

Validation and enrichment before or during matching: required fields, format checks (a Greek VAT number has nine digits), address standardisation, normalising phone numbers to one format. Good data quality makes matching far more reliable.

Data stewardship

No rule set is perfect. Some records will be ambiguous (“these two might be the same customer”), some will fail validation. Data stewards are the people who review these cases, decide, and fix the data. A usable stewardship screen, and a named person with time to use it, is what keeps MDM working after the project ends.

The four MDM styles

MDM tools and projects are usually described in terms of four styles. They differ in where the golden record lives and whether it flows back to the sources.

Style	Where data is authored	Golden record flows back?	Typical use
Registry	In the sources	No, only an index of links	Cross-system lookups, low disruption
Consolidation	In the sources	No, to analytics only	Reporting and BI on clean data
Coexistence	In the sources and in the hub	Yes, synchronised	Keeping ERP, CRM and e-shop consistent
Centralised	Only in the hub	Yes, hub is the master	Strict governance, e.g. product data

Registry stores only the matches and the links between source IDs. Sources stay untouched. It is the lightest option.
Consolidation builds golden records for reporting, typically feeding a data warehouse, but does not change the operational systems.
Coexistence builds golden records and synchronises the agreed values back to the systems that want them. This is the most common style for mid-sized companies, because people keep working in the tools they know.
Centralised means records are created and edited in the MDM hub (often through an approval workflow) and pushed to every other system. It gives the most control and requires the most change.

Many companies start with registry or consolidation and move to coexistence for one domain, usually customers.

When an SME doesn’t need full MDM

A dedicated MDM product is a real investment, in licences and especially in ownership. You may not need one yet if:

One system is clearly the master and the others only read from it. If the ERP creates every customer and the e-shop and CRM receive copies, a well-built integration flow plus a cross-reference table of IDs may be enough.
Duplicates are rare and manageable in a spreadsheet once a quarter.
You only need clean data for reporting. Deduplication in the data warehouse (the consolidation style, done in SQL) can cover it.

You probably do need MDM if customers or products are created in several systems, duplicates cause real problems (double shipments, wrong credit limits, GDPR requests you can’t answer completely), or you are about to replace or add a major system and need a stable “who is who” in the middle.

Common mistakes

Starting with the tool. Agree first on what a “customer” is, which fields matter and who decides. A tool cannot settle a disagreement between sales and finance.
Trying all domains at once. Pick one domain (customer, supplier or product), prove it, then expand.
Fuzzy matching without review. Automatically merging on a similar name will eventually merge two different companies. Route uncertain matches to a person.
No steward. If nobody owns the quarantine queue, it grows until people stop trusting the hub.
Ignoring the way back. If a golden record is corrected but the ERP keeps the old value, the next sync brings the error back. Decide which systems accept updates from the hub.
Treating MDM as a one-off cleanup. A cleanup project fixes today’s duplicates; MDM prevents tomorrow’s.

How to compare tools

Which domains? Customer, product, supplier, or several. Some tools are strongest in one domain, product data in particular.
Which style? If you need coexistence, check how the tool synchronises updates back to sources, not only how it builds golden records.
Matching and survivorship. Can you combine exact and fuzzy rules, set survivorship per field and test rule changes before applying them?
Stewardship experience. Ask to see the steward’s screen with real-looking duplicates. This is where the daily work happens.
Integration effort. How does data get in and out? Built-in connectors to your ERP, CRM and e-shop, or custom APIs?
Scale and pricing. Per record, per domain, per user or flat. Model it with your actual record counts.
Who runs it? Cloud service or self-managed, and how much configuration expertise it needs.

Tools in this space

These are products we come across often, in alphabetical order. The right one depends on your domains, your existing stack and how much you want to invest.

Boomi DataHub. A cloud MDM service that is part of the Boomi platform. You define models with match rules and data quality steps, attach source systems that contribute data and/or accept updates, and resolve exceptions in a stewardship UI. It fits best when you already integrate your systems with Boomi, because the processes that feed and synchronise the hub are built on the same platform.
Informatica MDM. A long-established, comprehensive MDM offering, now centred on Informatica’s cloud platform (IDMC). Strong in multi-domain MDM, data quality and governance, and common in large enterprises.
Profisee. MDM built closely around the Microsoft ecosystem, with strong ties to Azure and Microsoft Purview. Users often cite fast time to value for mid-sized and larger organisations.
Reltio. A cloud-native, multi-domain MDM platform built around a graph-like data model and real-time APIs. Popular with organisations that want customer 360 views and continuous matching at scale.
SAP Master Data Governance (MDG). The natural choice for SAP-centric companies, with centralised creation and approval workflows for materials, customers, suppliers and finance data inside the SAP landscape.
Semarchy xDM. A flexible platform that combines MDM, reference data and data quality, known for letting teams model domains and stewardship apps quickly.

If you already have a strong platform for integration or ERP, start your evaluation there: MDM succeeds or fails on how well data moves in and out of the hub.

Where to go next

Two practical articles show these ideas in Boomi DataHub:

Building a customer golden record from ERP, CRM and e-shop with Boomi DataHub: repository, model, sources and the integration processes around them.
Match rules and duplicate handling in Boomi DataHub: exact and fuzzy matching, quarantine, stewardship and source ranking.