Now that MDS is gone, I keep hearing the same instinct from SQL Server teams weighing build vs buy for master data management: skip the tools, we will build something ourselves, we know T-SQL better than any vendor knows our data.
I understand the instinct. You just got burned by a product Microsoft abandoned, and the idea of depending on another vendor feels worse than depending on yourself. Building looks cheap, because the part you can picture is cheap. The trouble is that the part you can picture is about 10% of what an MDM actually is.
You already ran this experiment. It was called MDS.
It is worth sitting with one fact before you write a single CREATE TABLE. MDS was a build. Microsoft built a master data tool, shipped it, and then slowly stopped caring about it until it quietly disappeared from SQL Server 2025. The pain you are feeling right now is the pain of being downstream of a homegrown tool whose owner moved on.
If you build your own, you do not escape that story. You become it. You become the vendor with exactly one customer, the one team that understands the code, the single point of failure standing between your master data and a rewrite. The only difference is scale. Microsoft could afford to let MDS rot for years. You cannot.
What “just build it” actually means
Every estimate for a homegrown MDM is built around the visible part. The data model. And the data model genuinely is easy. It is the rest, the part nobody sketches on the whiteboard, that turns a two-week project into a permanent line item.
| The piece | What you estimate | What you actually live with |
|---|---|---|
| The data model | An afternoon | True. A few CREATE TABLE statements and you have somewhere to put records. This is the part everyone pictures, and it is the cheapest 10%. |
| Validation rules | A few CHECK constraints | Until rules need to vary by record, reference other tables, or report a violation rate. Now you are building a rules engine, not a constraint. |
| Approval workflow | A status column | Then someone wants two-step sign-off, a reject reason, a queue per steward, and a way to see what changed. A status column does not survive contact with a real process. |
| Audit trail | A trigger | Easy to write, hard to live with. Querying it, showing it to a non-technical auditor, and keeping it from bloating the database are the parts that take the time. |
| Permissions | We have AD groups | Read, propose, approve, and delete are four different rights, often per attribute. Mapping that to groups and enforcing it everywhere is its own small project. |
| The UI | A few CRUD screens | The screens are the entire reason stewards adopt the tool or quietly go back to Excel. This is where homegrown tools die, not in the database. |
None of these are exotic. Every one of them is a solved problem in any MDM you could buy. Building your own means solving them again, in-house, with no one whose job is to keep them solved.
It always starts as one table and a trigger
I have seen the first version of a homegrown MDM more times than I can count, and it always looks reasonable. A table for the master records, a trigger to log changes, a couple of constraints. Something like this:
-- Day one. Looks finished. It is not.
CREATE TABLE dbo.Supplier (
SupplierId INT IDENTITY PRIMARY KEY,
Name NVARCHAR(200) NOT NULL,
VatNumber NVARCHAR(20),
CountryCode CHAR(2),
IsActive BIT NOT NULL DEFAULT 1
);
-- "And we'll just log changes with a trigger."
CREATE TRIGGER trg_Supplier_Audit ON dbo.Supplier
AFTER INSERT, UPDATE, DELETE AS
BEGIN
INSERT INTO dbo.SupplierAudit (SupplierId, ChangedAt, ChangedBy)
SELECT SupplierId, SYSUTCDATETIME(), SUSER_SNAME()
FROM inserted; -- handles deletes how, exactly?
END;Then the requests start. The audit needs to capture the old value, not just that something changed. A steward needs to propose a change without it going live, so now there is a pending state. Someone has to approve it, so there is a workflow. The VAT number needs to be validated against a real format, per country. Finance needs read access but not write. The trigger that handled deletes “how, exactly” turns out to handle them not at all.
Eighteen months later you have a sprawling internal application, a stack of stored procedures nobody fully remembers writing, and a UI bolted on in whatever framework was in fashion when you started. It works. It is also load-bearing, undocumented, and understood by one person.
The real cost is the decade after, not the build
The build is a one-time number, and even if it runs over, you can absorb it. The maintenance is forever, and almost nobody puts it in the business case.
SQL Server gets a major version and your custom code needs revalidating. A regulation changes and the audit format has to change with it. A steward asks for a feature that is obvious in any commercial tool and trivial-sounding to them, and it lands on the backlog of the one developer who knows how the thing fits together. Then that developer changes teams, or leaves, and the knowledge walks out with them. The tool does not break the day they go. It just stops getting better, and then it stops getting fixed, and you are back where MDS left you, except this time there is no migration guide because nobody else has ever run this software.
That bus factor is the part I would push hardest on. A bought tool has a roadmap, a support line, and other customers hitting the same bugs you do. A built tool has whoever is left.
When building is actually the right call
I am not going to pretend the answer is always buy. There are real cases where building wins, and they share a shape: small, stable, or strategic.
Build when the scope is genuinely tiny and frozen. One domain, a dozen fields, rules that have not changed in years and will not. A lookup table with an approval step around it is not an MDM project, and reaching for a platform would be its own kind of overkill.
Build when master data management is your product. If you sell something where the data model and its governance are the differentiator, you cannot outsource the core of your business. Own it.
Build when a hard constraint rules everything out. A sovereignty requirement that no vendor can satisfy, an air-gapped environment, a compliance rule with no commercial answer. These are rarer than they are claimed to be, but they are real.
Notice what is not on that list: “we know SQL.” Knowing SQL is exactly why building feels safe and exactly why it is a trap. The database was never the hard part.
The fair case against buying
Buying has a real downside, and skipping past it would be the kind of vendor move this audience sees through immediately. The risk is lock-in. A lot of MDM tools are cloud-only and SaaS-only. They take your master data somewhere you cannot query it, price you per record, and make leaving expensive enough that you stop considering it. Trading one dependency for another is not progress.
The way out of that is narrow but clear. Buy a tool that runs on infrastructure you already own and keeps the master data in your own SQL Server, where a normal query still reaches it. Then you get the validation engine, the workflow, the audit trail, and the steward UI without giving up the one thing building was supposed to protect: control of the data itself. That is the whole reason an on-premise, SQL-native tool exists.
The question that actually decides it
Strip away the SQL pride and the vendor wariness and the decision comes down to four honest questions.
| Ask yourself | Leans build | Leans buy |
|---|---|---|
| Is master data tooling your core product? | If yes, build. You need to own it. | If no, you are building infrastructure for something that is not your business. |
| How many domains, how stable? | One tiny domain that never changes can be worth a small build. | Multiple domains or an evolving model means features you will keep adding forever. |
| Who maintains it in three years? | Only build if there is a named team, not one clever person. | The vendor maintains it. Upgrades arrive instead of being your backlog. |
| Where does the data have to live? | A true sovereignty rule may force a build. | A tool on your own SQL Server already satisfies most on-premise requirements. |
For most teams coming off MDS, the answers line up on the right. Master data is not your product, you have more than one domain, you do not have a team standing by to maintain a platform, and your on-premise requirement is satisfied by anything that runs on your own SQL Server. That is a buy, and specifically a buy that keeps the data where you can see it.
If you are still mapping out the move off MDS, the practical migration guide covers the steps, and the post on running MDM without consultants covers what buying does and does not save you.
Common questions
Should I build my own MDM or buy one?
Build only if master data tooling is something you want to own and staff for a decade. The data model is the cheap, visible part. The validation engine, approval workflow, audit trail, permissions, import/export, and steward UI are the expensive 90%, and buying gets you all of it on day one.
Why does building an MDM cost more than it looks?
Because the cost is the decade of maintenance, not the build. A homegrown tool starts as one table and a trigger and ends as an undocumented system one person understands. When they leave, it stops being maintained. That is the MDS story at the scale of your own company.
When does building actually make sense?
When the scope is genuinely tiny and stable, when MDM is your core product, or when a hard regulatory constraint rules out every tool. Outside of those, building is usually the expensive way to recreate features that already exist.
Is buying a lock-in risk?
It can be, which is the honest case against buying. Neutralize it by choosing a tool that runs on infrastructure you own and keeps the data in your own SQL Server, where you can still read it with a normal query.
Get the 90% without building it
Primentra is the validation engine, approval workflow, audit trail, permissions, and steward UI already built and maintained, running on your own SQL Server with the data in a database you can still query directly. The 60-day trial runs on your real data, which is long enough to find out whether buying beats the build you were about to start.