Open Microsoft’s discontinued features page for SQL Server 2025 and the first two bullets are the same sentence twice, with one name changed. Data Quality Services is removed. Master Data Services is removed. Everybody wrote about the second one. We wrote about the second one. Almost nobody wrote about the first, and the first is the one that quietly reaches into three other places.
If your MDS instance ever found a duplicate supplier for you, that was DQS doing it. If an SSIS package standardizes country names on the way into the warehouse, that is probably DQS too. Neither shows up on a checklist that only says “replace MDS”.
Four things stop working, not one
DQS installed as two halves. A Data Quality Server, which Microsoft describes as three SQL Server catalogs, and a Data Quality Client, which is the application a steward actually sat in front of. Around those two, other things grew.
Data Quality Client
The standalone application your steward opened to build knowledge bases, run a cleansing project and review match clusters. It installs as a SQL Server shared feature. There is no 2025 version of it.
The DQS Cleansing Transformation in SSIS
A data flow component that calls a published knowledge base as rows pass through. It is a client, not a self-contained rules engine, so it needs a Data Quality Server to talk to. Every package holding one has to be opened and reworked.
Matching inside MDS
This is the one people miss. Microsoft describes the MDS data quality functionality as being based on DQS. The fuzzy matching in MDS was never really MDS. It was DQS wearing an MDS coat, and both left in the same release.
The knowledge bases themselves
DQS_MAIN and DQS_PROJECTS hold years of domain rules, term-based relations, matching weights and thresholds. The databases survive a backup fine. Nothing else reads them.
There is a fifth item, and it is not software. Data Quality Server also needs two SQL Server logins, ##MS_dqs_db_owner_login## and ##MS_dqs_service_login##, plus an initialization procedure called DQInitDQS_MAIN sitting in master. Restore the two databases somewhere without those and you get a Data Quality Server that is present and not functional, which is a worse outcome than one that is plainly missing.
What the knowledge base was actually worth
Before deciding how hard to fight for it, read the mechanics. A matching policy in DQS is a set of rules. Each rule names the domains that count, gives each one a weight, and says whether the values must match exactly or may be similar, and to what degree. You can mark a domain as a prerequisite. DQS then groups every record scoring above your threshold into a cluster.
That was a reasonable design, and it was ahead of what most SQL Server shops had in 2012. Three details in Microsoft’s own documentation are worth reading again before you mourn it.
First, this line, verbatim: “Null values in the corresponding fields of two records will be considered a match.” Two supplier rows with no VAT number score as agreeing on VAT. Your newest and thinnest rows are the ones most likely to be duplicates, and they are also the ones full of blanks, so that default pushes the score the wrong way on the exact records you were hunting.
Second, the survivor. DQS picks one record in each cluster as the pivot, and the documentation says it picks it randomly. You then choose a survivorship rule: pivot record, longest record, most complete record, or most complete and longest. If several records in the cluster satisfy that rule, DQS breaks the tie randomly as well. Run the same project twice against the same data and the row that survives can differ.
Third, it compares every row to every other row. Microsoft says so plainly, and it is also why the matching project that ran in four minutes against a sample takes an afternoon against the real supplier master.
None of that makes DQS bad. It makes the thing you are trying to preserve smaller than it feels. The part worth saving is the argument your team already had and settled: these five fields identify a supplier, name outweighs address, a missing tax number counts as nothing. Write that down. It transfers to any tool. The rest transfers nowhere.
One more thing about that upgrade page
Microsoft Learn still hosts a page called Upgrade Data Quality Services. It carries the removal notice at the top and then, underneath, walks you through running Setup, choosing Upgrade from a previous version, and finishing with dqsinstaller.exe -upgrade. The version numbers in its folder-path examples stop at SQL Server 2017.
So the official guidance for moving DQS forward is a page about moving it to a version that still has it. Do not plan a 2025 upgrade around it, and do not assume Setup will explain the problem at the moment you run it. Take an inventory instead. Which instances have a Data Quality Server, which SSIS packages contain the cleansing component, and is anyone still opening the Data Quality Client at all. Ask that last one out loud before anybody budgets for a replacement. A Data Quality Client nobody has launched in three years is a very different project from one a steward lives in.
Three ways out
The cheapest one is to do nothing yet. Mainstream support for SQL Server 2022 ends 11 January 2028 and extended support delivers security patches until 11 January 2033, and DQS keeps running the whole time. Be sceptical of anyone selling you 2028 as a cliff. What actually constrains you is the next SQL Server upgrade, whenever it lands, and infrastructure teams schedule those without asking the data steward.
Buying a matching engine is the right answer for some of you. It is a real product category with real vendors in it, and if you are reconciling a million unkeyed customer rows from six acquisitions, that is what the job needs. We do not sell one and we are not going to pretend otherwise. Budget for tuning time rather than licences alone. Those weights and thresholds you spent two years settling in DQS have to be settled again in whatever replaces it, by the same people, in meetings that feel very familiar.
The third option is to stop making the duplicates. Matching is cleanup. It exists because the second Acme Corporation got created, and it runs forever because the third one is coming. A unique key on the combination of fields that really identifies a supplier refuses that second row while somebody is still typing it, which costs one person ten seconds instead of costing a steward an afternoon of cluster review six months later. That is the end of the problem Primentra works on. It is a different bet from a matching engine, not a cheaper version of one.
In practice most teams take the first one by default, because nobody schedules a SQL Server upgrade in the same quarter they find out about this. Use the time. Write the identity rules down while the people who argued about them are still in the building, and by the time the upgrade is real you will know whether the backlog underneath needs an engine or a good filter.
What we do and do not have
Primentra ships no matching engine. There is no probabilistic scoring and no cluster review screen. What it has is the prevention side: unique and combination-unique rules that refuse a duplicate at entry, business rules for the near-misses a key cannot express, and approvals so a person sees the record before it becomes real. For the duplicates already sitting in the table, the grid’s search and filters do the hunting, and a staging import can correct a code without creating a second row.
That is a smaller claim than the one on a matching vendor’s home page, and it is the accurate one. For the longer version, including where prevention runs out, how master data matching actually works lays out the five stages and the three limits no algorithm gets past.
Common questions
Is DQS really removed, or only deprecated?
Removed. Microsoft Learn now carries the same sentence at the top of every DQS page: Data Quality Services is removed in SQL Server 2025 (17.x), and continues to be supported in SQL Server 2022 (16.x) and earlier. It sits on the discontinued database engine functionality page one bullet above the identical sentence about Master Data Services.
What happens to my SSIS packages?
The DQS Cleansing Transformation connects to a Data Quality Server. Remove the server and the component has nothing to reach. Go looking for it before the upgrade rather than after. It tends to be buried one level down in a data flow inside a package nobody has opened since the person who wrote it left.
Can I move a knowledge base into another product?
No vendor imports it. Microsoft itself describes the DQS databases as holding assemblies and other complex objects rather than ordinary tables, which is also why backing them up correctly was always fiddlier than backing up a normal database. What is worth keeping is the thinking, not the file: which fields your team decided identify a record, and what score they settled on.
Does Microsoft name a replacement?
It does not. Purview catalogs and governs. It does not cleanse a name, standardize an address or decide that two supplier rows are the same company. The removal notice points nowhere, which is the same answer MDS customers got.
How long can I stay on SQL Server 2022?
Mainstream support ends 11 January 2028, extended support runs to 11 January 2033, and security patches arrive throughout. Nothing breaks on either date. The deadline that actually bites is your next SQL Server upgrade, whenever the infrastructure team schedules it, because DQS cannot come along.
If you are working through the MDS half of the same removal, the MDS end-of-life checklist covers the upgrade dates and what to audit before you move. For why Microsoft has no MDM product left to point you at, see what the Microsoft stack actually covers.
Try refusing the duplicate instead of finding it
The 60-day trial installs on your own SQL Server. Point it at your real supplier list, set a combination-unique rule on the fields that identify a row, and see how many entries it turns away.