You sit through a vendor demo and the slide arrives: our platform supports all four MDM implementation styles. Every vendor uses that line. Few buyers ask what it really means, and fewer still notice that the style they pick locks in the next five years of integration work.
The four styles are not interchangeable. Each makes a different bet about where master data lives, who is allowed to write to it, and how downstream systems consume it. Pick the wrong style and you build the right tool on the wrong architecture.
What each style buys you
| Style | Edits happen | Downstream latency | Governance burden | Migration effort |
|---|---|---|---|---|
| Registry | Source systems | Pointer lookup | Low | Lowest |
| Consolidation | Source systems | Batched publish | Medium | Low to medium |
| Coexistence | Both | Two-way, eventual | High | High |
| Transaction hub | MDM only | Immediate from hub | Highest | Very high |
Read the table top to bottom. You trade speed and control for migration cost and governance maturity. Those four rows are a ladder. Most teams have to climb it one rung at a time, even if the vendor slide pretends the rungs are equivalent doors.
Registry: the cheapest start
A registry stores keys, match results, and identity links. It does not store the data itself. The ERP keeps its supplier record. The CRM keeps its customer record. The registry tells you that ERP supplier 4287 and CRM customer A4-22 are the same legal entity.
This is the right starting point if you have no executive mandate to clean up source systems, each system works fine on its own, and your actual pain is "we cannot reconcile across systems." It buys nothing if your problem is data quality inside any single system. The registry does not cleanse and does not enforce. The source systems remain whatever they were.
Consolidation: the analytics-first choice
If the trigger for the project was the data warehouse producing wrong numbers, consolidation is probably your style. Master data is copied into the MDM, matched and cleansed there, then published downstream as a golden record. Every report, every dashboard, every Power BI query that reads from the warehouse sees one clean record per supplier.
Source systems do not change. The dirty supplier record in the ERP stays dirty. That works for a few years. It fails the moment someone in procurement notices that the report says Acme Corp and their ERP says ACME CORPORATION LTD and asks why. That is the call for coexistence.
Coexistence: the political mode
Coexistence is the style most vendors mean when they say "MDM." Source systems and the hub stay in sync. Edits can originate anywhere. The hub reconciles, broadcasts, and keeps everyone aligned.
It also carries the highest political cost. Every source-system owner has to accept that the MDM is going to write to their tables. Every integration team has to build two-way sync. Every conflict, and there will be conflicts, needs a rule for who wins. Coexistence is what you grow into. Starting there before you have the governance discipline in place is how MDM projects collapse in steering committee.
Transaction hub: when the MDM is the source
Transaction hub is the endpoint of the ladder. The MDM owns the data. ERP, CRM, and every other system reads from the hub. New suppliers get created in the hub first, then propagated outward.
A handful of organizations run a true transaction hub for one domain. Product is the most common. Customer is rare. Supplier is almost never. The reason is straightforward: transactional systems were built to own their own master data, and rewiring them to consume identity from outside is a multi-year project. If you are ten years into an MDM program and have rebuilt your integration layer twice, transaction hub becomes plausible. Otherwise it is a year-five target, not a year-one decision.
The hybrid reality
No real MDM deployment is one pure style. A typical setup looks like this:
- Customer is registry. The CRM still owns its records, the MDM only links them.
- Supplier is coexistence. The ERP and the hub sync both ways.
- Product is transaction hub. The PIM is already the source, every system pulls from it.
The style is a per-domain choice, not a platform choice. Anyone trying to sell you a single platform-wide answer has not run one of these projects through to production. Build the decision matrix one domain at a time. Six domains, four words each. The document fits on a napkin and saves you ten architecture meetings.
Where MDS quietly ended up
Microsoft MDS was nominally a consolidation tool with optional coexistence patterns. The product slide showed both. In practice, most MDS deployments became registry-by-accident: a place to write down that two ERP suppliers were the same, with the subscriber views never reaching enough downstream systems to actually publish a golden record at scale.
Teams who tried coexistence in MDS hit a wall fast. The subscriber-view pattern is pull, not push. Scheduling source-system imports to match business needs was painful, and the source-system owners almost always refused to take a scheduled write from MDS once they understood what it implied. So teams ended up with a registry by accident, not by design. The registry was good enough to keep going, so nobody pushed harder.
A replacement should let you pick the style per domain, deliberately. The earlier post on what replaces MDS subscriber views covers the downstream side. The hierarchy side is covered in MDS hierarchies and what replaces them.
Three questions to ask any vendor
Skip the styles-supported slide. Skip the reference customer logos. The three questions below separate the platforms that have shipped a real coexistence deployment from the platforms that have shipped a consolidation deployment and a roadmap.
Can I run different styles per domain?
If the answer is a confident "you can do any style you want" without acknowledging the per-domain reality, the vendor has not taken one of these projects all the way through to production. The honest answer is a yes plus a description of how the platform separates write-back, publish, and identity-link logic for each domain.
What does write-back to source systems look like on day one?
If the answer is "we have a connector for that" and stops there, expect to build the connector yourself. Ask for the exact protocol, the conflict-resolution rule, and what happens when the source system rejects the update. A real coexistence platform has a real answer to those three.
What happens when a source-system owner refuses an update?
If there is no answer, you do not have a coexistence platform. You have a consolidation platform with marketing slides on top. Owners refuse updates more often than vendors admit, and the platform has to support that refusal gracefully without breaking the rest of the sync.
What to do this week
If you are still scoping, write down which style each domain needs in the next three years. Customer, supplier, product, location, employee, account: six lines, four words per line. That document will save you more architecture meetings than any vendor demo.
If you have already started and feel stuck, the most common reason is starting with coexistence on a domain where registry would have been enough. Step back. Ask whether you actually need write-back, or whether you just need cross-system identity. The cheaper answer is usually the right one.
And if you are mid-MDS migration, do not assume the new platform should do what MDS was supposed to do on paper. Look at what MDS was doing in practice. That is usually registry plus a thin slice of consolidation, and that is a perfectly good place to start the next chapter from.
Common questions
What are the four MDM implementation styles?
Registry, consolidation, coexistence, and transaction hub. Registry stores cross-system identity links and leaves source systems untouched. Consolidation copies records into the hub, cleanses them, and publishes downstream for analytics. Coexistence adds two-way sync so cleansed values flow back into source systems. Transaction hub makes the MDM the system of record and demotes legacy applications to consumers.
Which MDM implementation style should I start with?
The lightest style that solves your actual problem. If the pain is "we cannot reconcile across systems" and source systems are fine internally, a registry is enough. If the pain is wrong numbers in the data warehouse, consolidation is the right start. Coexistence requires governance maturity most organizations are not ready for in year one. Transaction hub is a long horizon.
Can I run different styles for different domains?
Yes, and most real deployments do. A typical setup: registry for customer because the CRM is staying, coexistence for supplier because the ERP and the hub both need alignment, transaction hub for product because the PIM is already the source. The choice belongs to the domain, not the platform.
Which implementation style was Microsoft MDS?
MDS was nominally a consolidation tool. In practice most MDS deployments became registry-by-accident: a place to record that two ERP suppliers were the same, with subscriber views never reaching enough downstream systems to publish a golden record at scale. Teams who tried coexistence hit a wall because the subscriber-view pattern is pull rather than push.
One platform, four styles, picked per domain
Primentra runs on SQL Server, supports registry through coexistence patterns out of the box, and lets you configure the style per entity rather than committing the whole tenant to one architecture. The 60-day trial includes the full read, publish, and write-back stack against your real data.