MDM on Microsoft: Dataverse, Fabric, Purview or a Dedicated Platform
The short answer: Master Data Services is removed from SQL Server 2025, and Microsoft advises evaluating Purview or partner MDM platforms. In practice, MDM on Microsoft is built either from components (Dataverse, Power Apps, Fabric) or on a partner platform integrated with Purview. The choice depends on data volumes, the number of domains and how much ready-made functionality you need.
What happened to Master Data Services?
Microsoft has removed Master Data Services (MDS) from SQL Server 2025 and continues to support it in SQL Server 2022 and earlier. The MDS security documentation notes that earlier versions receive only security updates, and that the product relies on ActiveX, which requires the retired Internet Explorer. The recommendation: avoid new MDS deployments, plan a phased migration, and evaluate Microsoft Purview or partner MDM platforms.
For companies on MDS, this means a planned migration: the product is supported in SQL Server 2022 and earlier but is gone from SQL Server 2025. For everyone else, it answers the common question of what Microsoft offers for MDM: new MDM in this ecosystem is made of several components or a partner product.
What each Microsoft component does in MDM
These components are easy to mistake for interchangeable. They actually cover different parts of the job, and none of them is complete MDM alone.
| Component | Role in MDM | What to know |
|---|---|---|
| Dataverse | Stores master records or steward tasks, roles and audit data | Alternate keys simplify exchange with external systems. Built-in duplicate detection allows only five published rules per record type, and merging works for accounts, contacts and leads, two records at a time |
| Power Apps and Power Automate | Steward workspace, queues, approvals | The logic for comparing records and choosing values has to be designed around your rules |
| Microsoft Fabric | Loads from sources, processes large volumes, stores masters, publishes for analytics | Matching and golden record creation are built as part of the solution. The Dataverse link to Fabric needs no separate export but consumes Dataverse storage |
| Microsoft Purview | Catalog, glossary, data products, governance | According to Microsoft documentation, golden records are created in an integrated partner MDM solution, and their metadata is published to Purview |
| Power BI | Reports on master data, a data quality dashboard | Shows the problem and the effect but doesn't fix data by itself |
The practical takeaway: "we'll have MDM on Purview" is incomplete without a partner product or your own logic. Purview helps you see and describe data, but it won't match records between two systems.
Three paths compared
| Path | Best fit | Benefits and trade-offs |
|---|---|---|
| Dataverse + Power Platform | One or two domains, moderate volumes, Dynamics 365 or Power Platform already in place | Golden records in Dataverse, no separate MDM license, flexible processes. Matching logic is built for the project and maintained by your team or an integrator. |
| Fabric + Power Apps + Dataverse | Large volumes, many sources, strong analytics | Golden records in Fabric, steward tasks and decisions in Dataverse, no separate MDM license. Building and maintaining it takes data engineers, yours or an integrator's. |
| Partner platform + Purview | Many domains, complex hierarchies, a need for ready-made features | Golden records in the vendor's product, with matching ready but requiring configuration. It adds a separate license, and flexibility is limited by the product. |
These are guidelines rather than rules, and the actual boundaries depend on your data. If your master files are small and rarely change, Excel with a clear procedure and owner may be enough, with no separate project. Among partner products, the Purview documentation currently names CluedIn, Profisee, Reltio and Semarchy; compare them against your own domains and rules rather than a general ranking.
How to choose: six questions
These questions follow the criteria Progresia uses to define the architecture of a master data management project: volumes and change frequency, the number of domains, rule complexity and your existing Microsoft environment.
How many records are there, and how often do they change?
The larger the volumes and the more frequent the batch processing, the stronger the case for Fabric. We check the actual limits by measuring your data, not with general thresholds.
Who needs corrected data: analytics or operational systems?
If only reports do, a registry or consolidation is enough. If corrections must flow back to CRM and ERP, plan for sync directions and conflict resolution.
How many domains are there, and how complex are the hierarchies?
Counterparties in one group of companies can be managed on Microsoft components. Several domains with complex multi-level hierarchies more often justify a ready-made product.
What have you already bought, and what works?
Existing Dynamics 365, Power Platform or Fabric lower the entry barrier. Whether your current licenses cover this specific scenario needs a separate check.
Which sources will you need to connect?
BAS, 1C and other systems with local configurations can significantly affect the scope. We check whether write-back is possible for each configuration.
Who will maintain the solution a year from now?
Custom logic is more flexible but needs a team or partner. A ready-made product reduces development but adds a license and vendor dependency.
Three typical scenarios
These are generalized scenarios for orientation, not descriptions of specific clients.
Distribution: products and suppliers
Dynamics 365, BAS, a website and supplier price lists. The main task is mapping item codes and units of measure. A logical start: one domain on Dataverse or Fabric, depending on catalog size.
Agricultural holding: counterparties across legal entities
Each entity keeps its own books, but reporting has to be consolidated. A logical start: shared MDM identifiers without changing accounting systems, later adding counterparty checks through YouControl.
A company on SQL Server MDS
Models, business rules and integrations exist, but the product is gone from SQL Server 2025. A logical start: an inventory, then a decision on what to recreate and what nobody uses anymore.
How to plan a move from MDS
- Take inventory. Models, entities, business rules, change history, users and every consuming system.
- Remove what's unused. Check which models are still in use: there is no point moving the rest.
- Choose the target using the same six questions. Migration is a good reason to revisit the model rather than copy it one to one.
- Run both systems in parallel. Compare results on real data and switch consumers over in phases.
Overall, the cycle resembles a CRM migration, which we covered in our article on Dynamics 365 Activate: much of the risk surfaces during the inventory rather than when moving records. Progresia takes on this stage together with your data team.
Five architecture selection mistakes
- Starting with the platform instead of the problem. Measure duplicates and completeness in one domain first, or you'll have nothing to compare options against.
- Taking on all domains at once. One domain with a measurable result achieves more than a program for all master data with no early results.
- Looking only at license cost. Also count logic development, integrations, steward work and maintenance.
- Relying only on exact matches. They miss records with no key, while fuzzy matching without human review merges too much.
- Not appointing data owners. Without them, disputed records pile up in the queue under any architecture.
Once the architecture is chosen, put the master data to use right away in Power BI reports and Power Platform solutions: the business sees the effect sooner, and data quality becomes a shared goal.
Frequently asked questions
Does Microsoft have its own MDM solution?
Master Data Services, formerly part of SQL Server, is removed from SQL Server 2025. Microsoft now advises evaluating Purview with partner MDM platforms, and companies also build MDM on Dataverse, Power Platform and Fabric.
Does Microsoft Purview create golden records?
According to Microsoft documentation, golden records are created in an integrated partner MDM solution. Purview receives their metadata and manages them as data products in its catalog.
Is built-in duplicate detection in Dynamics 365 enough?
For keeping one system tidy, it often is. However, it works within one environment rather than across CRM, ERP and Excel, and it doesn't build master values from several sources.
What should we do if we still use MDS?
MDS is supported in SQL Server 2022 and earlier, but don't start new projects on it. Inventory your models, rules and integrations, choose a target and plan a phased migration.
Can MDM be built without a separate MDM platform license?
Yes, on Dataverse, Power Platform or Fabric, if you are ready to design and maintain matching logic. You still need licenses for those services, and whether they suffice for your scenario needs a separate check.