MDM #11. How Cloud Platforms Are Reshaping the MDM Stack

The Master Data Management market is changing, but not in the way a simple “Big Tech enters MDM” narrative suggests.

AWS, Microsoft and Google Cloud have not all become full-scale MDM vendors in the traditional sense. Instead, they are expanding into capabilities that sit around MDM: entity resolution, data integration, cataloging, governance, data quality, data products, AI context and agent infrastructure.

At the same time, other platform companies are moving more directly.

Salesforce completed its acquisition of Informatica in November 2025, bringing Informatica's integration, governance, quality, metadata and MDM capabilities under Salesforce ownership. SAP continues to provide first-party Master Data Governance tightly integrated with its enterprise application ecosystem.

The result is not the disappearance of MDM.

It is the unbundling and rebundling of the MDM stack.

Cloud platforms are not uniformly replacing MDM. They are taking control of more of the architecture around MDM—and that is changing where master data is governed, resolved, distributed and consumed.

For enterprise architects, this distinction matters because choosing an MDM strategy now requires deciding not only which mastering engine to use, but which platform should own the surrounding data and AI context.

The MDM Stack Is Becoming More Modular

Traditional MDM discussions often treated “the MDM platform” as one large capability.

In practice, enterprise master-data architecture consists of several distinct layers.

AI & AGENT CONSUMPTION
Enterprise AI · Copilots · Autonomous Agents

↓

DATA PRODUCT & DISTRIBUTION
APIs · Events · Data Shares · MCP Tools

↓

GOVERNANCE & CONTEXT
Catalog · Metadata · Lineage · Policy · Quality

↓

MASTERING
Match · Merge · Survivorship · Hierarchy · Workflow

↓

ENTITY RESOLUTION
Identity Matching · Record Linkage · Duplicate Detection

↓

INTEGRATION
Pipelines · CDC · APIs · Event Streaming

↓

CLOUD & DATA PLATFORM
Storage · Compute · Databases · Analytics

Historically, specialist MDM vendors attempted to provide much of this stack themselves.

Cloud platforms increasingly provide the surrounding layers directly.

This changes the competitive question.

Instead of asking:

“Which vendor has the best MDM product?”

enterprises increasingly need to ask:

Which platform should own each layer
of our trusted master-data architecture?

1. Five Different Platform Strategies Are Emerging

The major technology platforms are not pursuing one common MDM strategy.

Platform	Primary Strategy	MDM Role	What It Does Not Automatically Replace
AWS	Provide composable cloud and entity-resolution services	MDM building blocks plus partner ecosystem	Full multidomain mastering, stewardship and governance operating model
Microsoft	Embed MDM into governance and Fabric ecosystem through partners	Purview + Fabric + integrated specialist MDM	Purpose-built mastering supplied by the MDM partner
Google Cloud	Build enterprise context, governance and data products for analytics and AI	Trusted-data context layer surrounding MDM	Enterprise golden-record and stewardship capability
Salesforce	Own more of the complete trusted-data stack	Direct MDM capability through Informatica acquisition	Need for architecture and integration across non-Salesforce systems
SAP	Integrate MDM closely with enterprise business applications	First-party MDG with multiple deployment models	Need to govern heterogeneous non-SAP landscapes

This is why labeling all five simply as “Big Tech MDM vendors” obscures more than it explains.

2. AWS: Entity Resolution and Composable MDM Building Blocks

AWS does not need to provide a traditional monolithic MDM suite to influence enterprise MDM architecture.

A particularly important first-party capability is AWS Entity Resolution.

AWS describes the service as helping organizations match, link and enhance related records stored across multiple applications, channels and data stores.

It supports approaches including rule-based and machine-learning-based matching.

AWS — What Is AWS Entity Resolution?

This is clearly relevant to MDM because entity resolution is one of MDM's foundational capabilities.

But entity resolution is not the same as complete MDM.

Entity Resolution Is Only One Layer

AWS Entity Resolution
Can Help Answer

“Do These Records Represent the Same Entity?”

but MDM Must Also Answer

“What Is the Authoritative Record?”
“Which Value Survives?”
“Who May Change It?”
“Which Hierarchy Is Authoritative?”
“What Workflow and Approval Apply?”

A company could build additional capabilities around AWS services and create an MDM-like architecture.

But at that point the enterprise is assembling and operating the mastering system itself.

The AWS Strategic Model Is Composability

A possible architecture can combine:

AWS Entity Resolution for matching and linkage,
storage and database services for entity state,
Glue or other integration services for pipelines,
event services for distribution,
IAM for technical access control,
Bedrock for AI use cases, and
a specialist MDM product for richer governance where required.

The strength is flexibility.

The tradeoff is that integration responsibility remains with the enterprise or implementation partner.

3. Microsoft: Make MDM Part of the Fabric Ecosystem

Microsoft's current approach is materially different.

Microsoft Purview provides enterprise data-governance capabilities including Data Map, Unified Catalog, business concepts, governance domains, data quality and metadata management.

Microsoft — Data Governance with Microsoft Purview

Purview is important to an MDM architecture.

But Microsoft itself distinguishes governance from the actual mastering capability.

Microsoft documentation includes a reference architecture that combines Purview with Profisee Master Data Management to merge, validate and correct master data.

Microsoft — Microsoft Purview and Profisee Integration for MDM

Microsoft Fabric Makes the Integration Tighter

By 2026, the boundary between platform and specialist MDM has become even less visible to users.

Microsoft Fabric provides a Profisee connector, and Microsoft lists Profisee MDM in the Fabric partner ecosystem.

Microsoft Fabric — Profisee Connector

Microsoft Fabric — Partner Ecosystem

Profisee announced in March 2026 that its MDM workload was generally available within Microsoft Fabric, including deeper Fabric integration.

Profisee — MDM in Microsoft Fabric

This illustrates a significant market trend:

THE SPECIALIST MDM ENGINE DOES NOT DISAPPEAR

It Becomes More Deeply Embedded
Inside the Strategic Enterprise Data Platform

Microsoft's Advantage Is Ecosystem Gravity

For an organization already heavily invested in:

Microsoft Fabric,
OneLake,
Power BI,
Azure,
Purview, and
Microsoft AI services,

an integrated MDM partner becomes easier to position as part of the same data architecture.

This is not Microsoft replacing MDM.

It is Microsoft influencing where MDM runs and how MDM outputs are consumed.

4. Google Cloud: From Data Catalog to Enterprise Context

Google Cloud's strategy is also better understood as a context-and-governance strategy than as traditional MDM.

In 2026, Dataplex Universal Catalog transitioned to Knowledge Catalog.

Google describes Knowledge Catalog as an AI-powered catalog that provides business context and governance across an enterprise data estate, including capabilities for:

metadata aggregation,
business glossaries,
data lineage,
data-quality scanning,
policy and access workflows,
semantic search, and
AI-agent context.

Google Cloud — Knowledge Catalog

Google Is Building Context Around Enterprise Data

Google states that Knowledge Catalog has evolved toward an AI-powered context graph designed to provide enterprise context for analytics and agentic applications.

Google Cloud — Transition to Knowledge Catalog

This is strategically relevant to MDM.

AI systems need to understand:

what data exists,
what it means,
where it came from,
which policy applies, and
how it relates to other enterprise information.

MDM provides authoritative business identity.

Knowledge Catalog provides metadata and broader enterprise context.

Those capabilities can complement each other.

Google Data Products Strengthen the Consumption Layer

Google Cloud also supports governed data products in Knowledge Catalog.

Google defines a data product as a curated logical collection of data assets packaged to be discoverable, trusted and accessible for a business problem.

Google Cloud — Data Products in Knowledge Catalog

This reinforces a pattern discussed in the next articles of this MDM series:

MDM
Establishes Trusted Business Identity

↓

Data Product
Packages Trusted Data for Consumption

↓

Knowledge / Context Layer
Explains Meaning, Lineage and Relationships

↓

AI & Analytics

Google is strengthening the upper layers of this stack.

That should not be confused with providing all of the MDM mastering layer itself.

5. Salesforce: The Most Direct Structural Change

Salesforce represents a different case because it now directly owns major MDM technology.

Salesforce completed its acquisition of Informatica on November 18, 2025.

The company explicitly stated that the acquisition brings Informatica capabilities in data integration, cataloging, governance, quality, privacy, metadata and Master Data Management into the Salesforce platform.

Salesforce — Completion of Informatica Acquisition

This is substantially different from providing an entity-resolution service or partnering with an external MDM vendor.

Salesforce Is Building a Broader Trusted-Data Stack

SALESFORCE APPLICATIONS & AGENTFORCE
↓
DATA CLOUD
↓
INFORMATICA CAPABILITIES
Integration · Quality · Metadata · Governance · MDM
↓
HETEROGENEOUS ENTERPRISE DATA

The strategic rationale is clear.

AI agents require trusted data and context from systems beyond CRM.

Owning Informatica gives Salesforce technology for managing and governing heterogeneous enterprise data rather than relying only on data generated inside Salesforce applications.

Acquisition Does Not Mean Instant Platform Convergence

Enterprises should distinguish between:

corporate ownership,
product integration,
commercial packaging, and
technical convergence.

The acquisition is complete.

The extent to which specific Informatica services become technically unified with Salesforce products should be assessed through current product documentation and roadmaps rather than assumed from the acquisition announcement alone.

This distinction is particularly important for existing Informatica customers with heterogeneous ERP, cloud and data-platform landscapes.

6. SAP: Application-Centric MDM Remains a Different Model

SAP is not a hyperscaler in the same category as AWS, Azure or Google Cloud.

Its MDM advantage comes from something else: proximity to enterprise business processes.

SAP Master Data Governance provides first-party capabilities including:

central governance,
consolidation,
data-quality management,
workflow and approval,
matching and merging, and
master-data distribution.

SAP — Master Data Governance

SAP MDG Is Not One Product with One Functional Scope

An important architecture detail is that SAP offers different deployment and consumption models.

SAP's current documentation distinguishes among:

SAP MDG on SAP S/4HANA,
SAP S/4HANA Cloud Private Edition with MDG,
SAP S/4HANA Cloud Public Edition master-data governance, and
SAP Master Data Governance, cloud edition.

Functional and domain scope differs among those options.

For example, SAP MDG cloud edition currently focuses on core Business Partner attributes, while the S/4HANA-based offering has broader domain and attribute coverage.

SAP — Master Data Governance Deployment Comparison

This matters because an enterprise cannot conclude simply that “SAP MDG supports our domain” without examining which SAP MDG deployment model is being evaluated.

7. Specialist MDM Vendors Are Not Becoming Irrelevant

If cloud platforms provide so much surrounding capability, why do specialist MDM vendors still matter?

Because the difficult part of enterprise MDM is not simply storing or matching records.

Purpose-built MDM platforms concentrate capabilities such as:

multidomain data modeling,
complex matching and entity resolution,
survivorship,
hierarchy and relationship management,
stewardship,
business workflow,
master-data quality,
source crosswalk management,
merge / unmerge, and
governed publishing.

These remain difficult capabilities to reproduce reliably from generic cloud components.

The Market Is Moving Toward Combinations, Not Pure Replacement

A realistic enterprise stack may look like:

SPECIALIST MDM
Authoritative Identity & Mastering

+

CLOUD DATA PLATFORM
Scale · Analytics · Integration

+

GOVERNANCE PLATFORM
Catalog · Metadata · Lineage

+

AI PLATFORM
Models · Agents · Reasoning

=

ENTERPRISE TRUSTED DATA ARCHITECTURE

The important architectural issue becomes where the boundaries are drawn.

8. The Competitive Battlefield Is Moving from Golden Record to Trusted Context

For many years, the core MDM proposition was the golden record.

That remains necessary.

But AI creates a larger requirement.

An AI agent may need not only the mastered supplier record, but also:

what the supplier represents,
which attributes are authoritative,
which source supplied them,
how fresh they are,
what policy applies,
which relationships matter,
what the agent is authorized to do, and
which business operation can be safely executed.

This moves competitive value upward from:

Golden Record

toward:

Trusted Entity
+ Metadata
+ Policy
+ Relationships
+ Quality
+ Business Semantics
+ Access Capability
=
Trusted Enterprise Context

This explains why hyperscalers and major enterprise platforms increasingly care about capabilities adjacent to MDM.

9. AI Makes MDM More Strategic to Platforms, Not Less

Cloud companies have strong incentives to improve the quality and context of enterprise data used by AI.

This does not require them to own every MDM function.

They need the broader architecture to ensure that AI workloads can reach trusted enterprise information.

ENTERPRISE SYSTEMS
↓
Identity Resolution & MDM
↓
Governance & Metadata
↓
Trusted Context
↓
AI Platform
↓
Agents and Applications

The more enterprises deploy autonomous or semi-autonomous agents, the more strategically valuable this context layer becomes.

10. Do Not Confuse AI Capability with MDM Capability

Another common architectural mistake is assuming that a strong AI model can substitute for MDM.

An LLM can help:

classify records,
suggest mappings,
identify possible duplicates,
generate descriptions, or
recommend corrections.

But the enterprise still needs deterministic answers to questions such as:

Which entity is authoritative?
Which merge is approved?
Which source wins?
Which identifier is persistent?
Who owns the business definition?
Can the decision be reversed?

AI improves MDM operations.

It does not eliminate the governance function.

11. Platform Consolidation Can Reduce Integration Friction

There are genuine advantages to placing MDM close to a strategic cloud or data platform.

Potential benefits include:

fewer custom data transfers,
shared security architecture,
simpler analytics consumption,
common metadata,
easier AI access,
integrated monitoring, and
faster creation of trusted data products.

The Microsoft Fabric–Profisee model is a good example of this direction.

The MDM engine remains specialized, but the consumer experience increasingly looks like one integrated platform.

12. Integration Convenience Creates New Lock-In Boundaries

Platform integration also creates dependency.

But vendor lock-in should be analyzed more precisely than saying “cloud lock-in is high.”

There are several different forms.

Lock-In Type	Example	Mitigation
Identity Lock-In	Enterprise master IDs are proprietary and difficult to preserve elsewhere.	Stable enterprise identifiers and exportable mappings
Model Lock-In	Consumers depend directly on vendor-specific internal schemas.	Enterprise contracts and abstraction where justified
Integration Lock-In	Hundreds of workflows depend on proprietary APIs or connectors.	Governed external APIs and event contracts
Workflow Lock-In	Critical business logic exists only inside proprietary workflow configuration.	Document business rules independently of implementation
Commercial Lock-In	Switching cost becomes too high after platform-wide adoption.	Lifecycle TCO, exit terms and transition rights

Multicloud Is Not Automatically an Anti-Lock-In Strategy

Running MDM on one cloud, analytics on another and backup on a third can create additional complexity without improving portability.

A stronger portability strategy focuses on:

Portable Enterprise Identity
+ Explicit Data Contracts
+ Exportable History
+ Documented Business Rules
+ Replaceable Interfaces
+ Contractual Exit Rights

Architectural portability is more useful than multicloud branding.

13. Choose the MDM Architecture Before Choosing the Vendor

A common procurement mistake is beginning with product demonstrations.

The stronger sequence is:

BUSINESS DOMAINS
↓
MASTERING REQUIREMENTS
↓
GOVERNANCE MODEL
↓
CONSUMPTION MODEL
↓
PLATFORM BOUNDARIES
↓
DEPLOYMENT MODEL
↓
VENDOR SELECTION

This prevents existing cloud preference from determining the MDM architecture before the enterprise has defined what it actually needs.

14. A Platform Strategy Decision Matrix

Enterprise Requirement	Architecture Implication	What to Evaluate
Complex Multidomain Mastering	Purpose-built MDM capability likely remains important.	Matching, survivorship, hierarchy, workflow, stewardship and extensibility
Microsoft-Centric Data Estate	Integrated Fabric/Purview MDM ecosystem may reduce friction.	Native workload integration, OneLake, Purview and AI consumption
AWS-Centric Custom Architecture	Composable services may handle selected MDM functions.	Who will implement stewardship, lifecycle and authoritative mastering?
Salesforce / Agentforce Strategic Platform	Informatica ownership creates a broader end-to-end data-management option.	Actual product integration, heterogeneous-system support and roadmap
SAP-Centric Enterprise	SAP MDG can align tightly with SAP business processes.	Domain scope, deployment model and non-SAP integration
AI Context as Strategic Priority	MDM must integrate with metadata, governance and agent-context layers.	Trusted context architecture rather than MDM feature count alone

This matrix is a Digital Future & Strategy practitioner framework. It is not a vendor ranking or product recommendation.

15. Five Questions Matter More Than the Vendor Logo

Where will authoritative master identity actually be created?

A data catalog, entity-resolution service and MDM hub solve different problems.

Who owns stewardship and business approval?

A technically unified platform does not eliminate organizational accountability.

Can trusted master context move across application and cloud boundaries?

Enterprise data rarely remains inside one vendor ecosystem.

Can AI consume the master entity without bypassing governance?

Agent integration should reuse governed MDM services and policy boundaries.

Can the enterprise replace one layer without rebuilding everything?

This is the real test of architectural modularity.

16. Common Strategic Mistakes

Mistake 1 — Call Every Entity-Resolution Service MDM

Matching records is important, but it does not automatically provide survivorship, hierarchy, stewardship or lifecycle governance.

Mistake 2 — Call Every Catalog a Mastering Platform

A catalog explains and governs data assets. It does not necessarily establish authoritative business entity state.

Mistake 3 — Assume AI Can Replace Deterministic Governance

AI can recommend. Enterprises still need explicit ownership and authority.

Mistake 4 — Choose MDM Only Because the Cloud Platform Is Already Strategic

Platform adjacency can reduce integration cost, but it cannot compensate for missing core MDM requirements.

Mistake 5 — Assume Specialist Vendors Are Automatically More Portable

A specialist product can create significant proprietary dependencies too.

Portability should be evaluated from actual data models, APIs, contracts and exit mechanisms.

Mistake 6 — Assume Acquisition Equals Full Technical Integration

Corporate ownership and product architecture evolve on different timelines.

Mistake 7 — Optimize the Platform but Ignore the Operating Model

The best technology stack will still fail if ownership, stewardship and decision rights remain unresolved.

17. The MDM Market Is Moving Toward a Control-Plane Model

A useful way to interpret the market is that master data is becoming part of a broader enterprise data control plane.

BUSINESS SYSTEMS
ERP · CRM · SCM · SaaS

↓

TRUSTED ENTITY LAYER
MDM · Entity Resolution · Reference Data

↓

GOVERNANCE & CONTEXT LAYER
Metadata · Quality · Lineage · Policy

↓

DATA PRODUCT & ACCESS LAYER
APIs · Events · Shares · Tools

↓

AI & ANALYTICS
Agents · Models · BI · Applications

No single provider necessarily needs to own all layers.

But the provider that owns more of them gains architectural influence.

Questions for CIOs, CDOs and Enterprise Architects

Are we buying a mastering capability, an entity-resolution service or a governance platform—and do we know the difference?

Which layer of our MDM architecture is currently creating the greatest cost or friction?

Would deeper integration with our strategic data platform materially improve that layer?

Are our enterprise master IDs independent enough to survive a platform change?

Can we export master records, relationships, source mappings, rules and history?

Does our AI strategy require a broader trusted-context layer beyond the golden record?

Which MDM capabilities do we genuinely need from a specialist vendor?

Which capabilities can rationally come from the strategic cloud platform?

Are we creating useful platform integration—or simply moving vendor lock-in to a larger platform?

Can each layer evolve independently enough to avoid a complete architectural reset later?

The Platform Strategy for Modern MDM

The MDM market is not being replaced by cloud platforms.

It is being reorganized around them.

AWS is productizing useful building blocks such as entity resolution.

Microsoft is embedding specialist MDM more deeply into Fabric and Purview.

Google Cloud is building a richer governance, data-product and enterprise-context layer around AI.

Salesforce has moved further by acquiring Informatica and therefore directly owning major MDM technology.

SAP continues to integrate first-party master-data governance with the enterprise application landscape where master data is created and used.

Specialist vendors still matter because mastering itself remains a deep enterprise capability.

The market shift is therefore better represented as:

YESTERDAY
Choose an MDM Product

↓

TODAY
Design the Trusted Data Architecture

↓

THEN DECIDE
Which Platform Owns
Entity Resolution · Mastering · Governance · Context · Distribution · AI

This has an important implication for enterprise architecture.

The MDM decision should no longer be isolated from cloud strategy, data-platform strategy or AI strategy.

But it should not simply be surrendered to them either.

The enterprise still needs to define:

What Is the Trusted Entity?
Who Owns It?
How Is It Governed?
How Is It Distributed?
How Will AI Use It?
How Can the Architecture Evolve?

Only after those questions are answered does vendor selection become meaningful.

The strategic shift in MDM is not that every cloud provider is becoming an MDM vendor. It is that MDM is becoming one component of a much larger trusted-data and AI architecture—and the major platforms increasingly want to own that architecture.

Sources & Further Reading

Method Note
This article distinguishes full Master Data Management from adjacent capabilities such as entity resolution, cataloging, metadata management, data quality, data products and AI context. AWS, Microsoft, Google Cloud, Salesforce and SAP follow materially different platform strategies and should not be treated as one homogeneous category of “Big Tech MDM vendors.” Product capabilities and market positions are based primarily on official vendor documentation available through September 2026. The layered MDM stack, five platform strategy archetypes, lock-in taxonomy, decision matrix and control-plane interpretation are Digital Future & Strategy practitioner frameworks rather than vendor or analyst classifications. No vendor ranking is intended. Enterprises should validate current product scope, roadmap, commercial terms, deployment options and interoperability using their own architecture and procurement requirements.

Reviewed: September 2026

Global MDM Strategy Series

Part 2 — Enterprise MDM Execution

MDM #10. Why MDM Fails During ERP Modernization: Lessons from SAP S/4HANA

Part 3 — Market, Platform & Investment Strategy

MDM #11. How Cloud Platforms Are Reshaping the MDM Stack — Without Replacing MDM
MDM #12. Cloud MDM Strategy: Choosing SaaS, Private Cloud, Hybrid or On-Premises
MDM #13. Building the MDM Business Case: Baseline, Attribution, TCO and Realized Value

MDM #10. Why MDM Fails During ERP Modernization
MDM #12. Cloud MDM Strategy
MDM #14. Master Data as a Product
MDM #17. Designing MDM APIs for AI Agents

Previous: Why MDM Fails During ERP Modernization

Next: Cloud MDM Strategy