A compliance officer at a Dutch financial firm ran into a problem last year. Her company had been running cloud MDM for 18 months when DORA came into force in January 2025. The audit that followed showed master data for 40,000 customer accounts was being processed on servers in Virginia. She spent three months negotiating a data residency addendum that the vendor’s standard contract didn’t accommodate, at a cost that dwarfed two years of license fees.
Cloud MDM wasn’t the wrong tool. It was the wrong infrastructure decision for her situation. That distinction matters.
How cloud MDM became the default answer
For most of the 2010s, the direction looked obvious. No servers to manage, automatic updates, built-in redundancy. MDM vendors that pivoted to cloud SaaS pulled ahead in analyst rankings. The narrative became self-reinforcing: on-premise MDM was legacy thinking, a sign your IT team was behind the times.
The pitch wasn’t wrong for everyone. If you had no DBA team, no existing SQL Server investment, and no data residency requirements, cloud MDM solved real operational problems. The assumption built into that pitch — that most enterprise buyers fit that description — turned out to be less accurate than the vendors hoped.
Most mid-market organizations already had SQL Server. They had DBA teams. And by 2022, a growing number of them had data sovereignty problems they hadn’t anticipated when they signed their cloud MDM contracts.
What changed the math between 2022 and 2025
Three regulatory developments hit close enough together to force a real reconsideration.
GDPR enforcement got expensive. EU supervisory authorities issued over €2.5 billion in fines between 2020 and 2024, with data transfer violations accounting for a growing share. The Schrems II decision had already made clear that standard contractual clauses aren’t a blanket solution. Legal teams that had approved cloud MDM contracts on the basis of “we have SCCs” started revisiting those decisions as enforcement escalated.
DORA landed in January 2025 for EU financial services firms. Article 28 requires organizations to audit third-party ICT providers and maintain contracts that specify data location, data format ownership, and exit provisions. A lot of cloud MDM contracts — written before DORA existed — didn’t pass that audit without expensive renegotiation.
NIS2 took effect in October 2024 for critical infrastructure operators across manufacturing, energy, and healthcare. Organizations that hadn’t thought seriously about where their master data was processed had to start.
None of this made cloud MDM impossible. It made the procurement process longer, the legal review more expensive, and the ongoing audit burden heavier. For organizations in regulated sectors, the math stopped working.
The lock-in cost nobody puts in the business case
Cloud MDM vendors don’t advertise exit complexity. It’s not in the sales deck.
Your entity models, attribute mappings, approval workflows, and validation rules live in the vendor’s proprietary schema. When you decide to migrate — to a different tool, or back on-premise — you export to flat files and start over. There is no standard MDM interchange format. The relationship hierarchies you built over three years don’t transfer. The governance rules you tuned through six months of stakeholder workshops don’t transfer. You rebuild.
Pricing escalation compounds this. Most cloud MDM platforms start with a base fee, then layer on per-domain charges (governing products and suppliers separately each costs extra), per-user charges for data steward access, and sometimes API call charges when downstream systems query frequently. What looks like a reasonable five-figure annual license at contract signature tends to look different three years in, once usage has grown and expansion pricing kicks in.
Switching costs and pricing escalation together create a hold. Most teams only fully understand it once they’re inside it.
The SQL Server integration argument
For organizations already running SQL Server — which covers most mid-market European and North American businesses — on-premise MDM has a practical advantage that tends to get underweighted in the cloud discussion.
When your MDM system lives on the same infrastructure as your ERP and data warehouse, the master data views your ERP reads are SQL Server views. Direct. No API calls across the internet, no added latency, no authentication layer to maintain, no per-call charges. When the DBA team needs to troubleshoot, they use the same tools they already know.
Cloud MDM integration with on-premise ERP requires an extra layer: an ETL pipeline, a middleware connector, or a custom sync job. Each additional component is another failure point, another team that needs to understand it, and another thing that breaks at 2am.
When cloud MDM is the right call
On-premise MDM isn’t always the better option. It’s the better option for specific situations.
Cloud makes sense when you have no internal DBA team and no interest in building server infrastructure. When your core systems are already SaaS-based, so integration complexity is symmetric either way. When you need the vendor to manage geo-redundancy across multiple regions. Or when your industry has no data residency requirements and your legal team has reviewed the cross-border data processing.
A US-headquartered company with 150 employees, all-cloud infrastructure, and no regulated personal data probably has no argument for adding on-premise infrastructure just for MDM. Cloud is the right answer there.
Mapping your situation to the decision
The choice usually comes down to a handful of practical questions: where does your regulated data need to stay, do you already have SQL Server and a DBA team, what does your five-year cost look like as usage grows, and how painful would switching vendors be in year four?
| Your situation | On-premise | Cloud MDM |
|---|---|---|
| GDPR / DORA / NIS2 applies to your org | ✓ Clear path | ✗ Needs careful vendor vetting |
| Already running SQL Server + DBA team | ✓ Native fit | ~ Adds integration overhead |
| No IT team, SaaS-first infrastructure | ✗ Adds overhead | ✓ Vendor handles it |
| 5-year cost predictability matters | ✓ Flat pricing | ✗ Usually escalates |
| Likely to switch tools eventually | ✓ Low exit cost | ✗ Proprietary schema hold |
| Multi-region, global operations | ~ Requires own geo setup | ✓ Vendor manages it |
The honest answer
Most organizations that contact us after running cloud MDM for two or three years aren’t unhappy with the tool. They’re unhappy with the infrastructure decision — the compliance audit that got complicated, the pricing that didn’t scale the way the initial model suggested, or the integration layer held together by a contractor who left six months ago.
Those problems are solvable. They’re just easier to avoid at the start than to fix midway through a three-year contract.
If your organization runs SQL Server, has a DBA team, and operates in a regulated sector, the case for on-premise MDM is stronger now than it was five years ago. Not because cloud MDM got worse — it didn’t. But because the regulatory environment around data sovereignty got more demanding, and the full cost of cloud lock-in became clearer once enough organizations had actually experienced it.
MDM that runs where your data already lives
Primentra installs on your SQL Server, keeps your master data on infrastructure you control, and integrates directly with your ERP via staging tables — no middleware, no per-call charges, no data leaving your network. The 60-day trial includes everything.