Microsoft MDS End of Life: Your Migration Checklist for SQL Server 2025

If you are running Microsoft Master Data Services and planning your next SQL Server upgrade, you have a decision to make. MDS was deprecated in SQL Server 2025. It is not gone yet — it still works on SQL Server 2022 — but it will not be there when you upgrade, and Microsoft has made clear there is no path forward on the Windows side. For a broader look at what SQL Server teams are doing instead, that post covers the landscape.

This is a practical guide. If you need background reading on what master data management is, this is not the post. If you need to know exactly what is affected, what your deadline looks like, and what to actually do, read on.

What Microsoft actually announced

Microsoft marked Master Data Services as deprecated in SQL Server 2025 (version 17.x). Along with it: the MDS Excel Add-in, and the MDS web application. None of these features are included in the SQL Server 2025 installer. If you upgrade your SQL Server instance to 2025, MDS stops working — period.

SQL Server 2022 (16.x) still includes MDS and will receive security patches through October 2028. So you are not being cut off today. But you are being told, clearly, that this is the last train. After 2028, you are on unsupported software.

Microsoft's stated direction for organizations that need cloud-native data governance is Azure Purview (rebranded Microsoft Purview). This is a very different product — cloud-hosted, catalog-focused, designed around Azure Data Factory and Fabric pipelines. If your organization runs SQL Server on-premise and uses MDS for managing cost centers, product hierarchies, or location data, Purview is not a like-for-like replacement. It is a different paradigm for a different architecture.

What "deprecated" means for your team

Deprecated does not mean offline tomorrow. It means Microsoft is done investing in the product. No new features, no bug fixes beyond security, and a hard wall when you try to move to a newer SQL Server version. Here is what that looks like concretely:

Your MDS database on SQL Server 2022 will keep working normally. Nothing breaks until you upgrade the SQL Server instance itself.
When your infrastructure team schedules the next SQL Server upgrade — to 2025 or later — MDS cannot come with you. The features are not in the installer.
The Excel Add-in is also gone. Anyone using it for data entry will need a different workflow.
SQL Server 2022 extended support runs to October 2028. After that date, you are running unsupported software with no patches — including security patches. That is a real risk if your server is on the network.
There is no upgrade-in-place. You cannot migrate your MDS configuration forward into a new SQL Server version and expect things to work. You need to migrate to a replacement tool first, then upgrade SQL Server.

Most organizations have two to three years before this becomes urgent. That sounds like plenty of time until you factor in procurement cycles, IT project queues, and the time it takes to actually migrate twelve MDS models with a hundred derived hierarchies and thirty downstream integration views. Start now, not in 2027.

Your MDS migration checklist

Work through these in order. The first section is about understanding what you have. You cannot scope a migration without it.

Before you start

Audit your MDS models — list every model, every entity, and every attribute. Count members. How large is each entity? Which models are actively used vs. created years ago and never touched since?

Identify all subscribers — what systems read from MDS staging tables or subscription views? ETL jobs, ERP integrations, BI reports, and any custom application that queries the MDS database directly need to be mapped before anything else.

Document your current permission structure — which users have access to which models and entities, and at what level. Re-creating permissions in a new tool is tedious; do not leave it until migration week.

Inventory your Excel Add-in usage — which teams use it for data entry, how often, and for which entities. The Add-in is also deprecated. Every person using it needs a replacement workflow, and that change management effort is often underestimated.

Check your subscription views — document every subscription view by name and identify which downstream system depends on it. These views are your integration contract. Any replacement tool needs to replicate them, or you need to update the downstream consumers.

Review your derived hierarchies — these are the most structurally complex part of MDS and the part most likely to require manual re-mapping. Document each one and understand whether your replacement tool has an equivalent concept.

Note any custom business rules and workflows built around MDS — approval chains, validation rules, or any automation that fires on staging table changes. These are rarely documented anywhere but the person who set them up.

Evaluating alternatives

Decide whether you need full enterprise MDM or a like-for-like replacement for what MDS was actually doing. Many MDS deployments are pure reference data management — cost centers, locations, product categories, currencies — which does not require a full MDM platform.

Check whether your use case is reference data (entities, hierarchies, domain values) or whether you need match-and-merge for customer or supplier records. These are fundamentally different problems with different tooling requirements.

Evaluate SQL Server-native options (Primentra, SQL Spreads) if you are staying on-premise and want minimal infrastructure change. Your MDS data is already in SQL Server — the closer the replacement tool stays to that architecture, the simpler the migration.

Evaluate Profisee, CluedIn, or Semarchy if you genuinely need match-and-merge, golden record management, or multi-domain governance at scale. Do not buy an enterprise MDM platform to manage a list of cost centers.

Request trials from shortlisted vendors and test against your actual data — not a demo dataset. The real test is whether your specific models, hierarchies, and integration views can be reproduced without excessive manual work.

Planning the migration

Export all MDS data — models, entities, members, and domain values. The MDS Configuration Manager can export model packages (.pkg files). Keep these as your baseline; you will need them for validation after migration.

Map your MDS model structure to your replacement tool's data model. Models, entities, and attributes usually map cleanly. Derived hierarchies and domain-based attributes require careful review — not all tools handle these the same way.

Plan subscriber migration — update ETL jobs, ERP integrations, and downstream systems to point to the new staging tables and integration views. Do not wait until go-live to discover which jobs have hardcoded references to MDS schema objects.

Test the migration against non-production data first. Validate row counts, attribute values, and hierarchy structures before touching production. Import errors in a staging environment are a minor inconvenience; the same errors discovered after you have decommissioned MDS are not.

Plan a parallel running period — both the old MDS system and the new tool live simultaneously while you validate data consistency and user workflows. How long depends on your data change frequency; at minimum, two or three full business cycles.

Update Excel-based data entry workflows. If your team used the MDS Excel Add-in for bulk data entry, decide now whether they move to a grid-based tool, a direct database interface, or something else. Do not leave this to the last week — retraining users takes longer than migrating data.

Your replacement options

There is no universal answer here. The right tool depends on what MDS was actually doing in your organization and what constraints you are working with. See our full comparison of the five best MDS alternatives for a ranked breakdown with pricing.

Primentra

Built on SQL Server, designed explicitly for teams moving off MDS. The data model is intentionally similar — Models, Entities, Attributes, and Hierarchies — so the conceptual translation is direct. Includes a built-in import wizard that reads your MDS database and creates the corresponding structure in Primentra automatically. Integration views replace subscription views and feed the same downstream systems. Flat pricing at €7,500/year, unlimited users. The right choice if your use case is reference data management and you want to stay on SQL Server without a major architectural change.

Profisee

A serious enterprise MDM platform with match-and-merge capabilities, golden record management, and broad multi-domain support. Worth evaluating if your organization has complex customer or supplier data quality problems that go beyond reference data. Pricing starts around €30,000/year and rises significantly with usage. Expect a several-month implementation engagement. Not the right answer for managing a list of cost centers, but a legitimate choice if the scope genuinely warrants it.

SQL Spreads

An Excel-centric approach to SQL Server data management. If your users are deeply Excel-native and the primary requirement is editing SQL Server tables from a familiar interface, SQL Spreads covers that well. Less suited for enforcing governance structures, approval workflows, or integration views at any scale.

Azure Purview (Microsoft Purview)

Microsoft's stated direction for cloud-native data governance. A data catalog and lineage platform built around Azure services. Only relevant if your organization is already committed to Azure and looking for a catalog-first governance approach. Not a replacement for managing structured reference data on SQL Server — the architecture and use case are fundamentally different. If you are asking whether Purview can replace MDS for managing your chart of accounts hierarchy, the answer is no, not without significant custom development.

Build your own

Technically possible. SQL Server tables, a few stored procedures, an SSRS report or two — the basic data storage is straightforward. What gets underestimated every time: the approval workflow layer, the audit trail, the permission model, the staging table infrastructure, and the ongoing maintenance burden as requirements evolve. Teams that go this route often end up with something that works for the initial scope and gradually becomes a liability as the organization's data governance needs grow. Price the hidden cost honestly before choosing this path.

Questions to answer before choosing

Before you evaluate any vendor, answer these honestly. They will eliminate most of the wrong options before you waste time on demos.

Is your primary use case managing reference data — cost centers, product categories, locations, currencies, organizational hierarchies — or do you need customer and supplier deduplication with probabilistic matching? These are different tools solving different problems.
Are you committed to SQL Server on-premise, or is your organization actively moving to Azure? If the latter, the answer may be Purview or a cloud-native MDM platform and a broader architectural conversation. If you are staying on-premise, a SQL Server-native tool eliminates a category of migration risk entirely.
How many people actively use MDS today? Will all of them migrate to the new tool, or will some revert to spreadsheets or other systems? The answer affects both licensing and change management scope.
What is your next planned SQL Server upgrade? If it is within twelve months, migration is urgent. If it is two or three years out, you have time to do this properly — but "properly" still means starting the evaluation now, not the quarter before the upgrade.
What is your organization's tolerance for implementation complexity? A tool that takes nine months to deploy has a very different risk profile than one that can be stood up in a day. Factor in what happens if the project runs over.

If your team is on Microsoft MDS and starting to plan the migration, Primentra's built-in migration wizard imports your models, entities, and hierarchy members directly from your MDS database. Most teams complete the technical migration in a day. Start the 60-day trial →

Same SQL Server infrastructure — no cloud migration required
Built-in MDS import wizard — models, entities, hierarchies, domain values
No credit card required for the trial