Microsoft removed Master Data Services from SQL Server 2025. It stays supported in SQL Server 2022 and earlier, and Microsoft has not shipped a successor. For most companies, that means the chart of accounts, cost centers, legal entities and mapping tables that have lived in MDS for a decade now need a new home, chosen on a database upgrade timeline rather than a finance timeline.
The replacement conversation is usually framed as a choice between Profisee and Semarchy, with Microsoft Purview somewhere in the picture. That framing is right for some MDS customers and wrong for others, and the difference is what MDS was actually holding. This guide is written for the finance systems leader and controller whose MDS models are financial structures feeding an ERP such as Dynamics 365 Finance, SAP or Oracle Fusion, an EPM platform such as Oracle EPM Cloud or OneStream, and a warehouse or lakehouse. It uses Microsoft's own documentation to describe what MDS did and did not do, lays out the three realistic replacement lanes with their trade-offs, and provides a construct-by-construct migration map.
One disclosure up front: EPMware, our product, is a finance-focused master data management platform and appears in the third lane. Profisee and Semarchy are strong products, and for some MDS customers one of them is the right answer. We say when.
MDS was never a finance product. It was a general-purpose master data repository that shipped inside the SQL Server license, with an Excel add-in that let business users edit governed tables. Finance teams adopted it because it was already paid for and because the Excel add-in made it feel like a controlled spreadsheet. The chart of accounts went in, then cost centers, then the entity list, then the mapping tables between the ERP and the consolidation system.
Microsoft's lifecycle page is blunt about the status: "Master Data Services (MDS) is removed in SQL Server 2025 (17.x). We continue to support MDS in SQL Server 2022 (16.x) and earlier versions." The page offers no migration path and names no successor. Microsoft's own Purview documentation points instead to partner MDM products, and the Purview page on master data management is co-authored with Profisee, which it describes as having been "built on Microsoft Master Data Services" and now "the premier upgrade and replacement solution."
So the replacement decision is really the first time these finance teams choose a master data tool on purpose. That is worth doing carefully, because the successors on offer are built for different jobs than the one MDS was quietly doing for finance.
Before picking a replacement, it helps to be precise about what the MDS models contain and which MDS features they depend on. The documentation describes four constructs that matter most for financial structures, and each has a documented limitation.
Hierarchies: a member appears once. MDS has two hierarchy types. Explicit hierarchies are ragged, built by placing each member under a parent by hand, from a single entity. Derived hierarchies are level-based, built from the relationships between entities and their attributes. Both follow one rule: "a hierarchy includes a member only once." If finance wants an account under both a legal rollup and a management rollup, MDS requires two separate hierarchies over the same members. There is no concept of a shared member whose properties differ by rollup.
Explicit hierarchies are deprecated. Microsoft's deprecated features page states that "explicit hierarchies, collections, and related components are deprecated" and that members previously modeled as consolidated members "are modeled as leaf members in derived hierarchies." The replacement is the recursive derived hierarchy, converted through a stored procedure. For finance this matters because ragged, hand-placed structures are what a chart of accounts looks like. Teams that kept explicit hierarchies for that reason are now migrating a deprecated construct.
Recursive hierarchies carry three limits. A derived hierarchy "cannot contain more than one recursive relationship." Recursive hierarchies "cannot include circular relationships." And, directly relevant to governance: "You cannot assign member permissions (on the Hierarchy Members tab) to members in a recursive hierarchy." The parent-child structure finance relies on most is the one where MDS cannot secure individual branches.
Versions are model-wide, and rules are not approvals. A version "contains all members, attribute values, hierarchy members, hierarchy relationships, and collections for the model." Versions move from unlocked to locked to committed, and committed versions "form an auditable record of changes." That is a snapshot of the whole model, not a record of who approved one change. Business rules can set defaults, change values, validate and trigger an external action, but validation can be bypassed at entry ("the value can still be saved"), and "changes made to data when business rules are applied are not logged as transactions." Approval workflow was never inside MDS; the start workflow action handed off to SharePoint or custom code.
Subscription views are a pull. MDS publishes approved data as SQL views. Every downstream system, the ERP, the EPM application, the warehouse, pulls from those views on its own schedule and loads the result its own way. Nothing in MDS confirms that the chart of accounts in Dynamics 365, in the consolidation system and in the lakehouse are the same version.
None of this is a criticism of MDS. It was designed as a repository with an Excel front end, and it did that well. It is a description of the gaps a finance team has been working around with spreadsheets, scripts and tribal knowledge, which is why the replacement should close them rather than reproduce them.
Many MDS customers are told that Purview is the destination. The documentation is clear that it is not, at least not on its own. Microsoft describes Purview as focused "on governance to find, classify, and define policies and standards," while "the tasks of enforcing policies and standards, cataloging data sources, and remediating deficient data fall to technologies like MDM systems." Purview does not hold the golden record, does not run approval workflow on a chart of accounts change, and does not publish a hierarchy to an ERP or an EPM application. It catalogs, classifies, tracks lineage and holds the glossary.
That makes Purview a complement to whichever MDM you choose, not a replacement for MDS. The practical consequence is that the Microsoft-documented path from MDS runs through a partner MDM product, and the partner product Microsoft documents is a multi-domain hub whose heritage is matching customer and product records. If your MDS held customer and product domains, that path fits. If it held accounts, entities and cost centers, the path takes you through a tool built for a different problem.
The AI assistants and analyst roundups that MDS customers consult have already converged on a shortlist. The useful move is not to add another name to it, but to sort the shortlist by what each option is built to do.
Three replacement lanes, sorted by what each is built to do. The deciding question is how many MDS entities are financial dimensions.
Lane 1: Build it on the Microsoft stack. Dataverse as the store, Power Apps for maintenance, Power Automate for approvals, Fabric or Azure pipelines to publish, Purview to catalog. Benefits: no new vendor, familiar tooling, and the lowest license cost. Downsides: Microsoft's own Purview documentation notes that without a dedicated MDM "you likely need custom hard-coded scripts" for survivorship and merge logic, and the same is true of hierarchy versioning, alternate rollups and deployment to EPM targets. Every one of those is a build, and a build has an owner who eventually leaves. Fits best when: a small set of simple reference tables, strong internal Power Platform skills, and no EPM platform downstream.
Lane 2: Multi-domain enterprise MDM. Profisee or Semarchy xDM. Benefits: mature stewardship, matching and data quality, broad connectivity, and in Profisee's case a documented MDS migration utility and deep Azure alignment. Semarchy's hierarchy modeling and Excel-like interface are well regarded by finance analysts. If the MDS estate spans customer, product, supplier and finance, one of these is the right answer, and Purview integrates with both. Downsides: finance structures are one modeled domain among many. The EPM-specific properties, the validations that reference the consolidation application, and deployment to Oracle EPM, OneStream or Hyperion are integration work rather than product features, and the finance team usually ends up with a second owner in IT for the model. Fits best when: finance is a minority of the master data, customer and product matching are the core need, and the EPM platform is small or absent.
Lane 3: Finance-focused MDM. A hub built around financial dimensions, hierarchies, properties and mappings, with approval workflow, separation of duties and audit trail as product features, and prebuilt deployment to ERP, EPM and data platforms. EPMware is in this lane. Benefits: the three MDS gaps above are the product's reason to exist: shared members across alternate rollups with rollup-specific properties, change-level approval and evidence, and deployment of one approved version to every target. Finance owns the model without IT modeling work. Downsides: it is not a customer or product MDM, and should not be bought as one. Teams with large non-finance domains will still need a multi-domain hub alongside it. Fits best when: the MDS models are accounts, entities, cost centers, products as a finance dimension, and mapping tables, feeding an ERP such as Dynamics 365 Finance, SAP or Oracle Fusion, an EPM platform, and a warehouse or lakehouse.
The honest test: list the entities in your MDS models and count how many are financial dimensions. If it is most of them, you are in lane 3 and lanes 1 and 2 will each ask you to rebuild what lane 3 ships. If it is a minority, start in lane 2 and let the finance hub be a later decision.
| Criterion | Microsoft stack build | Multi-domain MDM (Profisee, Semarchy) | Finance-focused MDM (EPMware) |
|---|---|---|---|
| Alternate rollups with shared members | Custom data model | Configurable through modeling | Native, with properties per rollup |
| Approval workflow with separation of duties | Power Automate, built per entity | Configurable stewardship workflow | Product feature, enforced by the system |
| Change-level audit evidence | Custom logging | Available, model dependent | Request, approver, deployment, version on every change |
| Validation before approval | Custom | Data quality rules | Rules aware of each target application |
| Deployment to Dynamics 365, SAP, Oracle Fusion | Pipelines you build | Connectors and APIs, integration work | Prebuilt adapters and integration framework |
| Deployment to Oracle EPM, OneStream, Hyperion | Pipelines you build | Custom integration | Prebuilt adapters |
| Publishing to Databricks, Fabric, Snowflake | Native to the stack | Connectors | Prebuilt adapters and SQL publishing |
| Customer and product matching | No | Core strength | Not the purpose |
| Purview integration | Native | Documented, Profisee is the reference partner | Catalog and lineage through standard connectors |
| MDS migration tooling | None | Profisee ships a utility | None; modeling and load exercise |
| Day-to-day owner | IT or Power Platform team | Data steward, usually IT | Finance |
The last two rows deserve emphasis. There is no EPMware utility that converts an MDS model in place. The migration is a modeling exercise, described in the next section, and for a typical finance estate it is measured in weeks, because the structures are already known and the hard work was done when the model was first designed. And the question of who owns the model day to day is the one most MDS customers skip. MDS was owned by whoever set it up. The replacement should be owned by the people who are accountable for the numbers.
MDS customers think in MDS vocabulary. This map takes each construct and says where it goes in a finance MDM, and what changes on the way.
Where each MDS construct lands in a finance MDM, and what changes on the way.
| MDS construct | What it held in finance | Where it lands in a finance MDM | What changes |
|---|---|---|---|
| Model | A grouping of related entities, usually one per domain | An application or dimension set | Versioning moves from the whole model to each change |
| Entity | Accounts, cost centers, entities, products, mapping tables | A dimension | Properties are typed for each target application, not generic attributes |
| Attribute, domain-based attribute | Account type, currency, owner, parent references | Dimension properties and relationships | Properties can vary by target and by rollup |
| Explicit hierarchy (deprecated) | Ragged chart of accounts, management rollups | A hierarchy with shared members | Members can sit in several rollups with rollup-specific properties |
| Derived and recursive hierarchy | Parent-child structures from a self-referencing attribute | A parent-child hierarchy | Member-level security is available, which MDS did not allow on recursive hierarchies |
| Collection (deprecated) | Ad hoc groupings | An alternate hierarchy or attribute-driven view | No separate construct to maintain |
| Business rule | Defaults, value changes, validation, email | Validation rules and workflow conditions | Validation blocks approval; it is not advisory |
| Version (open, locked, committed) | Model-wide snapshot | Request-level versioning plus point-in-time history | Every change carries its own version; snapshots are derived, not maintained |
| Subscription view | SQL views that targets pulled from | Deployment to each target, plus SQL publishing for the warehouse | Push with confirmation replaces pull with hope |
| Excel add-in | Business-user editing | No-code request interface, with bulk upload | Edits become requests that route for approval |
| Security (model, entity, member permissions) | Who could edit what | Role-based security with approver authority by dimension | Approver authority is enforced, not only edit access |
Two practical notes. First, export the MDS model before anything else: entities, attributes, hierarchies, business rules and the subscription view definitions. The views are the most important artifact, because they document who consumes the data and in what shape. Second, do not migrate deprecated explicit hierarchies as they stand. Microsoft's own guidance converts them to recursive derived hierarchies, and the finance MDM target handles ragged structures natively, so the conversion is the moment to clean them up rather than preserve them.
Of the gaps above, alternate hierarchies are the one finance teams notice within the first month of running without MDS, so it is worth being concrete.
A consolidation needs a legal rollup. Management reporting needs a management rollup. A regulatory filing needs a third. In MDS, those are three hierarchies over the same members, each maintained separately, each capable of drifting. The rule that a member appears once per hierarchy means the member's relationship to each rollup is held in a different place, and a new account has to be placed three times.
In MDS a member appears once per hierarchy, so alternate rollups are separate trees. In a finance MDM the member is placed in each rollup from one request.
In a finance MDM, the member is created once with its properties, and it is placed in each rollup from the same request. The properties that differ by rollup, such as a consolidation operator or a reporting attribute, are held against the placement rather than the member. When the account is retired, every rollup sees it. When an auditor asks how the account rolled up at year-end in the legal view, the answer comes from the change history rather than from a committed snapshot of the whole model.
Profisee and Semarchy can model this with relationship entities and configuration, and both do it competently in multi-domain programs. The difference is that it is modeling work with an IT owner, rather than a product behavior the finance team configures.
Much of the MDS install base runs Dynamics 365 Finance, or Dynamics AX before it, which is one reason the replacement question is so often framed in Microsoft terms. The finance structures in Dynamics 365, the main account, financial dimensions and account structures, legal entities and the consolidation configuration, are exactly what MDS was feeding through subscription views.
In a finance MDM, Dynamics 365 Finance becomes one deployment target alongside the EPM platform and the warehouse. A new cost center is requested once, validated against the rules that Dynamics 365, the EPM application and the lakehouse each enforce, approved with separation of duties, and deployed to all of them from the same version. The same model serves companies that run Dynamics 365 next to an acquired SAP or Oracle Fusion instance, which is where the cross-ERP mapping tables that lived in MDS become governed relationships rather than a lookup someone maintains.
Answer those in writing before the first vendor demo. Most MDS replacement projects that go wrong went wrong at question one, by choosing a tool for the domain that was loudest rather than the domain that was largest.
EPMware is a finance-owned master data management platform. For MDS customers whose models are financial structures, it is the lane 3 answer: dimensions, hierarchies with shared members and rollup-specific properties, approval workflow with separation of duties, change-level audit evidence, and deployment to Dynamics 365 Finance, SAP, Oracle Fusion, Oracle EPM Cloud, Hyperion, OneStream and Databricks from one approved version. It is not a customer or product MDM, and we will say so in the first conversation if that is what your MDS estate needs. If you want to see your MDS model mapped onto a finance hub before SQL Server 2022 reaches the end of its road, that is a useful exercise to do with a real export rather than a slide.
Yes. Microsoft's documentation states that Master Data Services is removed in SQL Server 2025 and remains supported in SQL Server 2022 and earlier. There is no Microsoft-built successor. Customers can stay on a supported SQL Server version while they plan a migration, but a database upgrade to 2025 means leaving MDS.
No. Microsoft describes Purview as a governance layer for finding, classifying and defining policies and standards, and says enforcement and remediation "fall to technologies like MDM systems." Purview catalogs master data and tracks lineage; it does not hold the golden record, run approval workflow, or publish hierarchies to an ERP or EPM application. It complements whichever MDM replaces MDS.
Both are capable multi-domain MDM platforms. Profisee has the closer Microsoft alignment and a documented MDS migration utility; Semarchy is often preferred for flexible hierarchy modeling and an Excel-like interface. Both model finance hierarchies as a configured domain, so EPM-specific properties, validations and deployment to Oracle EPM, OneStream or Hyperion are integration work. They fit best when finance is one domain among several.
Three things, each documented as an MDS limitation: shared members across alternate rollups with rollup-specific properties, where MDS allows a member once per hierarchy; change-level approval and audit evidence, where MDS versions the whole model and does not log rule-driven changes as transactions; and deployment of one approved version to every target, where MDS publishes views that each target pulls on its own.
No. The migration is a modeling and load exercise: export the MDS entities, attributes, hierarchies, business rules and subscription view definitions, map each construct to the finance MDM equivalent, convert deprecated explicit hierarchies rather than preserving them, and load the result. For a typical finance estate this is measured in weeks, because the structures are already known.
Yes. Dynamics 365 Finance is treated as one ERP target alongside SAP and Oracle Fusion, so a chart of accounts or cost center change approved once is deployed to Dynamics 365, the EPM platform and the warehouse from the same version.
Sources: Microsoft, Master Data Services backward compatibility (SQL Server 2025); Microsoft, Hierarchies (Master Data Services); Microsoft, Deprecated Master Data Services features; Microsoft, Recursive hierarchies; Microsoft, Versions; Microsoft, Business rules; Microsoft, Master data management with Microsoft Purview and Profisee.