Why Microsoft MDS Failed: 7 Reasons Master Data Services Deserved to Be Retired

I've spent the better part of a decade working with Microsoft Master Data Services. Setting it up for clients, migrating data into it, training data stewards on how to use it, and (more often than not) apologizing for how it works.

So when Microsoft announced that MDS wouldn't be included in SQL Server 2025, my first reaction wasn't surprise. It was: "finally."

MDS was the tool that everybody tolerated but nobody loved. It came free with SQL Server Enterprise, and honestly, that's the main reason anyone used it. Not because the interface was good. Not because data stewards enjoyed their Monday morning sessions with it. Just because it was already there and the alternative was a six-figure Informatica license.

Now that it's being retired, I want to talk honestly about what made MDS so painful. Not to kick a dead horse, but because understanding what went wrong matters if you're looking for what comes next.

1. Silverlight. Yes, really.

The original MDS web interface ran on Silverlight. For those who don't remember (lucky you), Silverlight was Microsoft's answer to Adobe Flash, a browser plugin for rich internet applications. Chrome dropped support for it around 2015. Microsoft themselves killed it in 2021.

But MDS kept requiring it. I still remember the look on a client's IT manager's face when I explained that their data stewards needed Internet Explorer with Silverlight installed to manage the company's master data. In 2019. He thought I was joking.

Microsoft did add an HTML5 web interface in SQL Server 2016. But it was stripped-down and missing half the functionality of the Silverlight version. So you had a choice: use a dead browser plugin with full features, or use a half-built modern UI. Most of my clients stuck with Silverlight and kept a dedicated IE installation on data steward machines. Some even ran it in a VM with a pinned Windows 7 image. For managing branch codes and cost centers. In 2020.

2. An interface that fought you at every step

Even after you got past the Silverlight hurdle, the actual experience of using MDS was rough. I've onboarded dozens of data stewards onto MDS, and the most common reaction in the first session was some version of: "wait, this is it?"

Editing a record meant navigating to the right model, then the right entity, then making sure you were in the right version (more on that later), and then finding the row you wanted in a grid that offered no search, no inline editing, and no way to sort by clicking a column header in the Silverlight UI. You couldn't double-click a cell to edit it. You had to select the row, then use a detail panel. For a data entry tool. In 2016.

The administration side was even worse. Want to create a new model? Open the MDS Configuration Manager — a separate desktop application. Want to add an attribute? You could do it through the web UI, but the experience involved so many dialogs and dropdowns that most DBAs just scripted it directly through the mdm schema. Which kind of defeated the purpose of having a web UI at all.

No keyboard shortcuts. No undo. No drag-and-drop. No copy-paste from Excel into the grid. It felt like a proof-of-concept that shipped as a finished product.

3. Terminology that confused everyone

I once ran a training session where I spent the first 45 minutes just explaining MDS vocabulary. Not how to use the tool, just what the words meant. That should never happen.

Microsoft chose terminology that sounded technical and precise, but actually made everything harder to understand. A record wasn't a record, it was a "member." But not just any member: a "leaf member," as opposed to a "consolidated member" (which was a parent node in a hierarchy, obviously). A lookup field wasn't a lookup field. It was a "domain-based attribute." A database view for consuming your data was a "subscription view," which sounds like something you'd pay monthly for.

The version system deserves special mention. MDS forced you to manage versions even if all you wanted was a single live dataset. Every entity had versions. You had to select a version before editing. You could accidentally edit an old version without realizing it. I've seen data stewards spend hours entering data into the wrong version because the dropdown defaulted to something other than what they expected.

A row should be called a row. A column should be called a column. When a data steward sits down to manage branch data, they shouldn't need a glossary to understand the interface.

4. Painfully, unforgivably slow

MDS wasn't just a little slow. It was slow in a way that broke your concentration and made you dread using it.

Click on a model, wait 5 seconds. Open an entity, wait another 8 seconds. Try to scroll through more than a thousand rows and the browser tab starts choking. Every single interaction was a full round-trip to the server. No caching, no optimistic updates, no local state. Click, wait, result. Click, wait, result. All day long.

Saving was the worst part. You'd edit three cells, hit save, and then wait while MDS validated every business rule server-side, processed the changes one row at a time, and eventually came back with either a success or a cryptic error. Simple edits that should take a second could take 30 seconds. With business rules enabled? Minutes.

Bulk imports were basically unusable through the web UI. The staging table approach — where you dump data into a staging table and then run a stored procedure to process it — worked, but it required DBA-level SQL Server knowledge. Most data stewards don't have that. So they imported via the Excel add-in, 5,000 rows at a time, and prayed nothing would time out.

5. When you got stuck, you were on your own

If you Google "Microsoft MDS" today, you'll find Microsoft's official documentation and not much else. A handful of blog posts from 2014. Some Stack Overflow questions with two upvotes. Maybe a TechNet forum thread where someone asked your exact question in 2017 and got no answer.

The official docs were exhaustive in describing what each feature did, but almost useless for explaining when you'd actually use it or how to solve real-world problems. There were no walkthroughs, no best practices, no "here's what a typical implementation looks like." You had to figure that out yourself. Or hire a consultant who'd done it before.

Inside MDS itself, the help was even worse. Cryptic error messages with .NET stack traces. No tooltips on confusing fields. No in-app guidance. I once had a client call me because MDS showed an error that said "The attribute value is not valid" — with no indication of which attribute, which value, or why it wasn't valid. We spent 45 minutes tracking it down. It was a date format issue.

Compare that to Power BI or Azure Data Factory, where Microsoft invested heavily in community, documentation, learning paths, and YouTube content. MDS got none of that. It always felt like an afterthought, a checkbox feature that shipped with SQL Server but that nobody at Microsoft was particularly proud of.

6. Business rules that sounded great on paper

MDS had a business rules engine. On paper, this was a selling point: define validation rules, auto-set defaults, trigger notifications. In reality, it was one of the most frustrating features in the product.

Creating a rule meant clicking through a maze of dropdowns and nested dialogs. Even a simple rule like "Code must be unique and not empty" required multiple steps across multiple screens. There was no expression language, no formula bar, no way to write logic as text. Just click, click, click, select from dropdown, click, click.

When a rule didn't work as expected, good luck debugging it. No execution log. No trace. No "this rule fired because X." You just stared at the rule definition and tried to mentally replay what MDS was doing. I spent an entire afternoon once trying to figure out why a validation rule was rejecting valid records. Turned out the rule was evaluating against a committed version, not the pending changes. Classic MDS.

And the performance hit was real. Stack a few business rules on an entity, and suddenly save operations that were already slow became glacially slow. With no way to profile which rule was the bottleneck.

7. The Excel add-in: the part that actually worked (mostly)

The most popular MDS feature? The one that let you bypass the actual application.

The MDS Add-in for Excel was, by far, how most data stewards actually worked. Pull data into Excel, edit in a familiar spreadsheet, push changes back. It wasn't glamorous, but it worked — and it was a thousand times more productive than the web UI.

But it had its own issues. Domain-based attributes showed internal codes instead of display names, so you'd see "42" instead of "Amsterdam-Central." Connection problems were common, especially after server updates. Two people editing the same entity could silently overwrite each other's changes. And version compatibility between the add-in and the server was a recurring headache during SQL Server upgrades.

Still, people loved it. When your most popular feature is an escape hatch, that says more about the building than the exit.

So why did anyone use MDS in the first place?

Honestly? Because the alternatives were terrible in different ways.

Informatica MDM, SAP Master Data Governance, Profisee: these are serious enterprise tools that cost serious enterprise money. We're talking six-figure license fees, multi-month implementations, and ongoing consulting engagements. For a company that just needs to manage 5,000 branch records and some product codes, that's absurd.

MDS was free. It was already installed if you had SQL Server Enterprise. It stored data in SQL Server, which your team already knew. The model-entity-attribute concept was sound. And for all its flaws, it did give you a central place to manage reference data with some governance on top.

The vision was right. Master data belongs in a governed, centralized system with versioning, audit trails, and clean integration views. The execution was just awful.

What we built instead

After years of working with MDS and watching data stewards struggle with it, I started building Primentra. Not because the world needed another enterprise MDM platform (it really doesn't) but because MDS users deserved something that didn't waste their time.

The design goals were simple: keep what MDS got right (models, entities, attributes, SQL Server storage), and rebuild everything else from scratch.

Primentra stores your data in SQL Server, just like MDS did. It uses the same model-entity-attribute structure. Your BI team, your ETL pipelines, your reporting — they all keep working. The difference is that the application on top actually works the way a modern tool should. The models, entities, and attributes post explains exactly how this structure works in Primentra.

End of the line for MDS

Microsoft MDS lasted 15 years. It was better than managing master data in Excel spreadsheets, which was honestly the only competition for most of its life. But "better than Excel" is not a high bar.

If you're still running MDS on SQL Server 2019 or 2022, you have a few years of extended support left. But the writing is on the wall, and Windows updates have already started breaking MDS functionality (the September 2025 cumulative update was a rough one). The longer you wait, the harder the migration becomes — not because the data is hard to move, but because institutional knowledge of your MDS setup fades as people move on. The migration guide covers the full process for moving your MDS models and data across.

You can replace MDS with something that works. I know, because I spent years being frustrated enough to build it.

Interested in moving off MDS? Check out how to get started with Primentra, or read our step-by-step MDS migration guide.

• No cloud migration — stays on your own SQL Server
• No professional services required — self-service from day one
• No credit card for the trial