Master Data Management (MDM)

What is Master Data Management?

Master Data Management, usually shortened to MDM, is the work of keeping one trusted version of your core business data across systems. Core data means the stable entities your business keeps referring to: customers, products, suppliers, locations, employees, and reference lists.

The pain is easy to recognise. A customer exists in CRM as Acme Ltd, in ERP as ACME Limited, in the support tool without a VAT number, and in a marketing list with an old address. Ask four teams how many active customers you have and you get four answers.

MDM creates a golden record: the shared version that downstream systems can trust for the fields where the organisation needs agreement. It is related to data governance, but it is more operational. Governance sets the rules and ownership. MDM applies those rules to the actual master records.

Which data belongs in MDM?

Most MDM programmes focus on one domain at a time.

• Customer master data. Accounts, contacts, members, consumers, addresses, VAT numbers, and consent status.

• Product master data. Products, SKUs, categories, units, packaging, names, and attributes used in ecommerce, logistics, and reporting.

• Supplier master data. Vendor names, payment details, contract status, risk checks, and purchasing categories.

• Location master data. Stores, warehouses, delivery addresses, service areas, and geographic hierarchies.

• Employee and organisation data. Teams, cost centres, roles, managers, and identity attributes.

• Reference data. Short controlled lists such as country codes, currencies, VAT codes, product statuses, and reason codes.

A retailer may start with customer and product data. A manufacturer often feels the product and supplier pain first. A service company may care most about customer, employee, and project structures.

How MDM works

Matching. MDM compares records from different sources and decides which ones describe the same real-world entity. It may use exact matches, fuzzy matching, tax numbers, addresses, email domains, or machine learning to suggest likely duplicates.

Merging. Once records match, MDM groups or merges them into one golden record. Some matches are obvious. Others go to a data steward for review.

Survivorship rules. These rules decide which source wins for each field. Finance may own the billing address, sales may own the account manager, and ecommerce may own the public product name. The decision is often political, so write it down.

Stewardship workflow. Real data always has edge cases. A steward needs a queue for possible duplicates, rejected matches, corrections, and split requests, with an audit trail of what changed.

Distribution. The golden record has to reach the systems that need it. That may happen through APIs, scheduled exports, warehouse tables, event streams, or direct integration with operational systems.

Implementation styles

Registry. The MDM layer stores identifiers and links back to the source systems. It is lighter to start with, but the full data still lives in the sources.

Consolidation. Data is copied into MDM and combined for analytics and reporting. It rarely writes back to operational systems, so it is a practical first step.

Coexistence. MDM maintains a golden record and synchronises approved changes back to source systems.

Centralised. MDM becomes the system where master data is created and maintained. Other systems read from it. This gives the most control and asks the most from integration and change management.

For many SMEs, consolidation is the sane starting point: centralise the important records for reporting, fix the worst duplicates, and add stewardship before forcing every system to change.

MDM in the Microsoft stack

Microsoft SQL Server used to include Master Data Services (MDS), which gave Microsoft-heavy teams an MDM option inside the SQL Server world. That path is now closing: Microsoft removed Master Data Services in SQL Server 2025 (17.x). SQL Server 2022 and older versions can still run existing MDS implementations, but a new project should not treat MDS as the future.

Microsoft Fabric does not replace MDS with a full MDM product. In a Fabric architecture, teams usually choose one of three routes: a specialist MDM tool such as Profisee or Informatica, a custom master-data layer on Fabric and Power Platform, or a pragmatic warehouse-first approach for reporting and deduplication.

A custom Microsoft route can work for a narrow domain. For example: store the customer golden record in OneLake or SQL, run matching jobs in Fabric, expose stewardship screens in Power Apps, and publish approved records through APIs or warehouse tables. That gives control, but your team owns the matching logic, workflow, history, and support burden.

What MDM gives you

Good MDM reduces duplicate customers, conflicting product names, broken reporting filters, failed deliveries, awkward audits, and manual cleanup between systems. It also makes CRM, ERP, marketing, finance, support, and BI speak the same language.

For analytics, MDM is often the missing piece behind a reliable data warehouse. The warehouse can show history, but MDM helps it know that three slightly different customer records are really one customer.

What to watch out for with MDM

Start with one domain. A company-wide MDM programme sounds tidy and usually stalls. Pick the domain with the most visible pain.

The hard part is agreement. A tool can merge records. It cannot decide that finance owns one field and sales owns another. That decision needs business owners.

Golden does not mean perfect. A golden record is the best agreed version under current rules. It still needs monitoring, stewardship, and correction.

Integration costs more than expected. The MDM layer is useful only when systems use it. Budget for APIs, change events, permissions, testing, and rollback paths.