Microsoft Master Data Services
Microsoft MDS Replacement After SQL Server 2025
Microsoft Master Data Services has been removed from SQL Server 2025.
September 15, 2026 | 3 mins read
Data Governance
Master Data Management
Article
Single View
Data Integration
Modern MDM
Microsoft Fabric
Microsoft Master Data Services has been removed from SQL Server 2025. That does not mean existing MDS implementations suddenly stop working. Microsoft continues to support MDS in SQL Server 2022 and earlier versions.
But it does mean organisations relying on MDS now have a clear architecture decision to make: what replaces it, and how do you move without turning years of master data logic into a high-risk migration project?
Quick answer
Is Microsoft MDS discontinued?
Master Data Services is no longer included in SQL Server 2025. Microsoft continues to support MDS in SQL Server 2022 and earlier versions.
So there is no immediate shutdown. But there is now a clear ceiling for organisations planning future SQL Server upgrades or wider data platform modernisation.
What has actually changed?
MDS has traditionally been used to define and manage models, entities, attributes, members, hierarchies, business rules and mastered outputs. Microsoft describes an MDS model as the highest level of organisation for master data, containing entities, attributes, hierarchies and collections. That model has served many organisations well.
The issue is not that MDS suddenly stopped being useful. It is that it no longer has a place in Microsoft's forward SQL Server platform.
The bigger question
Should you simply recreate MDS somewhere else, or use this as an opportunity to modernise Master Data Management properly?
What are the options for organisations still using MDS?
There are broadly four.
01
Stay on SQL Server 2022 for now
For some organisations, this will be the right short-term decision.
If the existing MDS environment is stable, business-critical and expensive to change, remaining on a supported SQL Server version can buy time.
But it should be treated as a transition strategy rather than a long-term architecture decision.
Use that time to understand what actually depends on MDS:
- Models and entities
- Business keys and identifiers
- Business rules
- Hierarchies
- Subscription views
- ETL jobs
- Downstream applications
- Reporting processes
- Manual stewardship workflows
02
Build a replacement using existing Microsoft technologies
Some organisations may decide to recreate parts of MDS using SQL Server, Dataverse, Power Platform, Fabric or custom applications.
For lightweight reference data management, this may be perfectly reasonable.
The risk is scope creep. What starts as somewhere to maintain records can quickly turn into rebuilding matching, rules, hierarchies, stewardship, workflows, history, publishing, permissions and governance.
At that point, you are effectively building and maintaining your own MDM platform.
03
Move to a dedicated Master Data Management platform
For organisations using MDS as a genuine enterprise mastering platform, moving to a purpose-built MDM system is usually the more sustainable option. That creates an opportunity to improve areas such as:
Entity resolution Golden Records Survivorship Data quality Enrichment Governance Lineage Workflows Multi-domain MDM
The better selection question
What should Master Data Management look like for the next ten years?
04
Use a staged migration rather than a big-bang replacement
This is the approach we generally recommend. It reduces risk, allows existing MDS contracts to remain in place temporarily and gives teams time to prove the new mastering model before cutting consumers over.
Direct MDS integration
Connect CluedIn to the existing MDS environment while MDS continues operating.
SQL-based ingestion
Reuse stable MDS subscription views or curated SQL outputs as an existing data contract.
Hybrid migration
Start with MDS, validate outputs, then progressively move toward cleaner source-system feeds.
Should you migrate MDS exactly as it exists?
Usually, no. A mature MDS implementation can accumulate years of business rules, extraction logic, hierarchies, stored procedures and workarounds.
Some are essential. Some only exist because MDS required them. Others survive because nobody has been confident enough to remove them.
Better starting point
What business outcomes and downstream contracts still matter?
What happens to MDS subscription views?
Subscription views are often one of the most important parts of an MDS estate because downstream systems depend on them.
In CluedIn, mastered data is published using Streams and Export Targets.
Synchronized streams
A downstream target mirrors the mastered Golden Records held in CluedIn.
Event log streams
Create, update and delete events can be published as changes occur.
What happens to MDS business rules?
They should not simply be copied. An MDS business rule can combine several responsibilities, including validation, defaulting, notifications and control of which records are considered valid.
Migration should be treated as translation, not replication.
The business requirement should survive. The implementation does not always need to.
In a modern MDM platform, those responsibilities may become:
- Data quality rules
- Validation logic
- Survivorship policies
- Matching rules
- Governance workflows
- Exception handling
- Publishing conditions
- Agent-assisted recommendations
Beyond replacement
Where does Agentic MDM fit?
This is where an MDS replacement can become more than a technology refresh. CluedIn is built around graph-native Master Data Management, where entities, relationships, lineage and governance context are maintained together.
Data quality detection Validation rules Duplicate detection Enrichment Classification Matching and merging
How should an MDS migration actually begin?
Not with a giant target-state diagram. Start by identifying one domain and one real downstream consumer.
For example:
Product master → trusted product records → Microsoft Fabric
Customer master → Golden Records → CRM
1. Bring the relevant MDS data into the new platform.
2. Confirm identity and business keys.
3. Recreate only the mastering logic that genuinely matters.
4. Publish a trusted output.
5. Reconcile it against the existing MDS feed.
6. Run both side by side.
7. Cut the consumer over once the output is proven.
8. Repeat for the next domain or contract.
Does moving away from MDS mean moving away from Microsoft?
No. For Microsoft-first organisations, replacing MDS can become part of a wider data modernisation programme.
CluedIn sits alongside technologies such as Microsoft Fabric, Microsoft Purview, Azure and Power Platform, handling mastering, entity resolution, data quality, enrichment and governed data operations between source systems and downstream analytics, AI and applications.
The important decision is not "when does MDS stop working?"
That is the wrong deadline. MDS remains supported in SQL Server 2022 and earlier.
How long do you want a strategic part of your data architecture tied to a capability Microsoft has already removed from its current SQL Server release?
If MDS is a small reference data application, the answer may be that you can leave it alone for now. If it sits at the centre of customer, product, supplier, asset or other business-critical master data, the case for planning the transition is much stronger.
Planning an MDS migration?
Move from Microsoft MDS without forcing a big-bang cutover.
CluedIn supports direct MDS connectivity, SQL-based ingestion, coexistence and hybrid migration patterns, so you can validate mastered outputs before progressively moving downstream consumers.
Explore MDS migration with CluedIn Read the technical migration guide
[]