Master Data Management (MDM) implementation styles are the architectural choices that determine how your organization will source, maintain, and govern master data across systems—whether you match and link records, create a central golden copy, or something in between.

Table of Contents

  • Why MDM Implementation Style Matters
  • Registry Style: Match and Link, No Mastering
  • Consolidation Style: A Trusted Golden Record
  • Coexistence Style: Bidirectional Sync
  • Centralized (Transaction) Style: Author in the Hub
  • Consolidation vs. Centralized: When Each Wins
  • Domain-Specific Fit: Product vs. Customer vs. Party
  • Choosing a Style by Domain and Maturity
  • The Hidden Cost of Wrong-Fit Styles
  • Transitioning Between Styles
  • Bottom Line
  • Frequently Asked Questions About MDM Implementation Styles

Opening Paragraph

Master Data Management (MDM) implementation styles are the architectural choices that determine how your organization will source, maintain, and govern master data across systems—whether you match and link records, create a central golden copy, or something in between.

Introduction

At Nestle Purina, where we managed product master data across hundreds of internal and external systems, one of the first decisions we had to make wasn’t “should we buy Profisee?” It was “what style of MDM will actually work in our business?” That question shaped everything downstream—governance model, tool selection, staffing, timeline, and ultimately whether the program succeeded or became shelf-ware.

There are four fundamental MDM implementation styles: registry style MDM, which matches and links data without centralizing; consolidation MDM, which creates a trusted golden copy; coexistence MDM, which maintains bidirectional sync between the hub and operational systems; and centralized MDM, which makes the hub the authoritative transaction system itself. Each style makes different trade-offs. None is universally “best.” The wrong choice for your domain, your technical baseline, or your organizational maturity will create friction that no amount of tooling can overcome.

The styles aren’t academic categories—they’re decision points that live in every MDM vendor’s roadmap and every implementation guide. Yet most organizations stumble into a style reactively, inheriting constraints from legacy systems or choosing the path of least resistance, only to find two years in that they’ve picked an architecture that doesn’t fit their actual use case. This article walks through each style, the concrete trade-offs, how to assess fit for different domains (product, customer, party, location), and how to think about maturity as you evaluate options.

Why MDM Implementation Style Matters

Your implementation style is the constraint that shapes governance, tooling, and success metrics more than any other decision. It determines where authority lives, how fast changes propagate, whether you accept temporary inconsistency, and what your data stewards actually do every day.

Consider a simple scenario: a customer record changes in your ERP system. In a registry style, that change may never touch your MDM hub—the hub simply notes that your ERP and CRM have conflicting versions and presents both to downstream systems. In consolidation style, the change lands in the hub, gets validated, and syncs back to source systems. In coexistence style, systems push and pull in real time, resolving conflicts algorithmically. In centralized style, the hub is the only source of truth for that customer—the ERP reads from it on demand.

Those four approaches lead to entirely different operational models. Registry style requires excellent matching logic and conflict resolution but minimal hub maintenance. Consolidation demands a strong governance layer and periodic batch sync. Coexistence needs sophisticated conflict detection and real-time infrastructure. Centralized requires the hub to perform like a mission-critical transaction system.

Different domains tolerate different styles. Product MDM often works best in consolidation or centralized—you want one golden bill of material, one set of attributes, authored in one place. Customer MDM in financial services often needs coexistence—your risk system, your core banking system, and your CRM all need to stay loosely synced because regulatory requirements prevent any one from being the sole master. Party data (suppliers, distributors, internal organizations) frequently works in registry style if you have strong matching and governance, because no single system owns all party relationships anyway.

Your maturity matters too. A greenfield organization with modern cloud infrastructure can afford centralized. A legacy environment with 80 source systems bolted together can’t—it will fail if you try to make the hub the transaction authority. An organization early in its data governance journey shouldn’t attempt coexistence; the operational complexity will overwhelm you.

The style decision is foundational. Get it right, and you’re building on solid footing. Get it wrong, and you’re fighting the architecture itself for the life of the program.

Registry style MDM is the lightest touch. The hub does not create or own records—it finds them, matches them, links them, and presents unified views. Each record stays in its source system; the registry is a map. When an application needs customer 12345, the registry says “that’s really John Smith, who also lives as CUST-67890 in the billing system and ACCT-8234 in the call center.” The registry returns all identities and lets the calling application decide what to do with the ambiguity.

This style works because it requires the least change to existing systems. You’re not asking the ERP to accept customer updates from the hub. You’re not forcing a periodic batch reconciliation. You’re not asking source systems to become read-only. The registry simply runs matching algorithms—name, address, phone, tax ID—and publishes a survivorship rule that says “if this customer exists in both systems, these identifiers refer to the same legal entity.”

I’ve found registry style invaluable for regulated environments and complex multi-tenant setups. In financial services, where you can’t arbitrarily merge or update a record without an audit trail linking back to its origin, registry is elegant—every update lives in the source system, the registry just documents the relationship. In healthcare, where a patient might be known by their insurance company ID, their provider’s medical record number, and their government identifier, registry lets you maintain all three without deciding which is authoritative.

The tradeoff is complexity in consumption. Applications using the registry must handle ambiguity. If the matching algorithm is 95% confident that two records are the same, what does the calling application do? Does it merge the views? Does it ask the user? Does it require manual stewardship? You also need excellent registry style MDM governance—someone responsible for tuning match rules, managing false positives, and handling exceptions.

Registry is also sensitive to data quality in source systems. If source systems contain garbage, the registry’s matching logic will struggle. You’re not cleansing data; you’re mapping dirty data to other dirty data. This is fine if source systems are reasonably healthy and you have clear lineage requirements. It’s a nightmare if you’re trying to roll up poor-quality data into a single view.

Registry style works well for:

  • Party data (suppliers, distributors, business partners) where no single system owns the relationship
  • Financial services customer data where regulatory lineage is paramount
  • Read-heavy use cases where you need a unified view but don’t need to author
  • Environments with strong source system governance where you trust each system’s data quality

Registry style is harder when you need a single authoritative version for operational decision-making or when source systems are constantly adding conflicting data that must be reconciled.

Consolidation Style: A Trusted Golden Record

Consolidation MDM creates a central golden record by pulling data from multiple sources into the hub, cleansing and standardizing it, applying business rules, and then publishing a canonical version back to consumers. The hub owns the master—it’s the system of record. Source systems remain authoritative for transactions (an order still lands in the ERP), but attributes of the master (customer name, address, attributes) flow through the hub.

This is the most common style in product MDM. Your product systems (ERP, PLM, e-commerce platform) all feed product information to the hub. The hub merges suppliers’ data, internal enrichment, and regulatory attributes into one product record. That golden record then publishes outbound to your catalog, your pricing engine, your supply chain system. When an attribute changes, it happens in the hub first—the source feeds in the change, the hub validates it against rules, and then it radiates outward.

Consolidation also dominates customer MDM in B2C environments. Credit card companies, retailers, and SaaS platforms often use consolidation because they need a single view for marketing, risk, and analytics—but that view must be curated. The hub is the source of truth for customer segmentation, lifetime value, preferences, and risk score, even though the customer’s transaction history lives in the transaction system.

The governance model for consolidation is clearer than registry. You have a defined master-of-record. Stewards work in the hub (or through the hub’s UI). Changes follow a defined workflow—perhaps they require approval, perhaps they’re auto-published if they meet quality thresholds. This clarity makes consolidation much easier to govern than registry.

The cost is synchronization overhead. You need periodic batch jobs (or event-driven syncs) to pull data from sources into the hub, transform it, and push it back out. You need to handle scenarios where a source system and the hub disagree—maybe an address changed in both places but differently. You need to decide: does the source system win, or does the hub? In most consolidation implementations, the hub wins on attributes (name, classification, attributes) and the source system wins on transactions (orders placed, payments made).

I’ve found consolidation style works best when you have a clear boundary between master attributes and transactional data. At Nestle Purina, our product master data included SKU, attributes, supplier information, and regulatory compliance data. Our transactional systems (ERP, demand planning) owned the forecasts, orders, and manufacturing schedules. The hub consolidated the master attributes; source systems handled the transactions. That boundary was clean enough that consolidation felt natural.

Consolidation struggles when source systems are constantly generating authoritative attributes that the hub should capture. If your ERP is the true source of bill-of-materials but your PLM also maintains its own BOM and they conflict frequently, consolidation becomes a constant firefighting exercise. You need to pick one system as the feeder and enforce discipline.

Consolidation MDM is the default choice for:

  • Product MDM where you have multiple product information systems feeding a single hub
  • Customer MDM in B2C where you need a unified customer view for analytics and marketing
  • Environments with clear master-versus-transaction boundaries
  • Organizations with moderate system complexity (not 100+ source systems)

Consolidation is harder when you have many source systems generating conflicting authoritative data, or when you need sub-second consistency across all consuming systems.

Coexistence Style: Bidirectional Sync

Coexistence MDM maintains multiple authoritative systems that are kept in continuous sync. Unlike registry, the hub is a system of record alongside others. Unlike consolidation, there’s no clear hierarchy—the hub and source systems are peers that push and pull changes to each other in near-real-time.

This style assumes you cannot eliminate any source system (maybe you’re locked into a large vendor contract, maybe the system is entrenched in critical workflows) and you cannot tolerate eventual consistency (you need all systems seeing the same data within seconds). So you build bidirectional sync—when customer data changes in the CRM, it syncs to the hub and to the ERP. When it changes in the ERP, it syncs back to the CRM and to the hub.

Coexistence is common in financial services for exactly this reason. A bank’s core platform owns accounts, a CRM owns customer relationships, and risk systems need customer data to calculate exposure. All three systems must stay in near-perfect sync because a regulatory review might pull data from any of them, and they must match.

The governance challenge is conflict resolution. If the CRM and ERP both update the same customer’s address at the same time, which one wins? Coexistence implementations typically use algorithmic conflict resolution—“last write wins,” “hub wins,” “most recent source wins,” or application-specific rules like “CRM wins for customer contact info, ERP wins for billing address.” These rules are hardwired into the sync engine. When they fail, a human data steward must intervene.

Real-time or near-real-time sync infrastructure is mandatory for coexistence. You need event streaming (Kafka, pub-sub), API-driven sync, or continuous database replication. Batch processes don’t work—if the hub syncs to the ERP once a night and the ERP syncs back once a night, you’ll have constant collisions. Coexistence demands infrastructure investment that registry and consolidation don’t.

Coexistence also demands excellent metadata and audit trails. Because change can originate from any system, you need to know which system provided the current value, when it arrived, and what conflict rule was applied. This metadata becomes your forensic trail for governance and regulatory reviews.

I’ve found coexistence works only when you have very high operational discipline and a small number of systems (two to four). Once you’re managing coexistence across more than four systems, the number of possible conflict scenarios explodes. At scale, you lose visibility into which system is actually authoritative for each attribute.

Coexistence is the right choice when:

  • You have two or three mission-critical systems that must stay in sync
  • You cannot eliminate any system and cannot tolerate eventual consistency
  • Your infrastructure supports real-time event streaming
  • Your governance team can manage sophisticated conflict resolution rules
  • You’re comfortable with significant complexity for the sake of alignment

Coexistence is the wrong choice if you have many source systems, if your teams can tolerate eventual consistency (even if it’s only minutes), or if you’re early in your data governance maturity.

Centralized (Transaction) Style: Author in the Hub

Centralized MDM makes the hub the system of record not just for attributes but for transactions. The hub is where data is authored. Source systems (or so-called “consuming systems”) read from the hub on demand—they cache data locally for performance, but they don’t own it.

This is the most ambitious style. It requires the hub to perform like a mission-critical transaction system: sub-second latency, high availability, audit trails, security, caching, API versioning. Many MDM platforms can do this. Profisee, Informatica, SAP Master Data Governance, and others are built on databases that can handle transactional load. But operational readiness is a different question—can your organization run the hub as a transaction system?

Centralized style is common in cloud-native, greenfield organizations. If you’re building a new SaaS product and you have the luxury of designing systems from scratch, you can architect all product information, pricing, and customer data to live in a central hub and be consumed by microservices. Everyone reads from the hub. Changes happen in the hub. Downstream services cache what they need and treat the cache as read-only.

Centralized also shows up in mature organizations running a second or third generation MDM program. If you’ve already got consolidation working and you’ve paid down technical debt, you might evolve the hub to be transactional—it becomes the system where customer service agents update addresses, where product teams publish SKUs, where suppliers push supplier data. Operational systems read from it.

The advantage is clarity. There’s one truth. No reconciliation, no conflict resolution, no matching. When someone asks “is this customer record current?”, the answer is always yes because the hub is the only authoritative source.

The cost is dependency. Every consuming system now depends on the hub’s availability. If the hub goes down for maintenance or crashes, no one can onboard a new customer, publish a product, or update a supplier. This is why centralized style demands high-availability infrastructure and robust disaster recovery.

Centralized also demands migration rigor. You can’t just flip a switch and make the hub transactional—you have to migrate all existing data into it, test that all downstream systems can read from it correctly, train users to author in the hub instead of in legacy systems, and decommission the old systems. This is a multi-year program for large organizations.

Centralized style is the right choice when:

  • You’re designing greenfield systems or rebuilding with modern architecture
  • You’ve already achieved stable consolidation and have the maturity to evolve further
  • Your infrastructure can support high availability and sub-second performance
  • You can afford the migration cost to move transactional authority into the hub
  • Your use case benefits from eliminating all consistency delay

Centralized style is the wrong choice if you’re early in MDM maturity, if you have legacy systems that must remain authoritative for transactions, or if you can’t guarantee the hub’s operational readiness.

Consolidation vs. Centralized: When Each Wins

These two styles are often confused because they both have a central hub, but they reverse the direction of authority.

In consolidation, the transaction system is authoritative for what happens (what was ordered, what was paid), and the hub is authoritative for attributes (product name, customer classification, supplier details). The ERP owns the order; the hub owns the product master. Data flows into the hub from sources, gets refined, and radiates back out. This is how you should think about consolidation: hub is the authoritative reference, sources are authoritative for transactions.

In centralized, the hub owns both transactions and attributes. The order happens in the hub. The product data lives in the hub. Downstream systems are read-only consumers. This is harder to achieve, more fragile operationally, and takes longer—but it’s simpler conceptually.

Consolidation is the pragmatic middle ground. It lets legacy transaction systems keep their authority and transactional integrity, while you achieve consistency on the attributes that feed analytics, governance, and cross-system decisions. Most organizations can adopt consolidation without wholesale system redesign.

Centralized is the architectural ideal. If you could redesign everything, you’d probably want centralized—one source of truth, no sync complexity, clear authority. But redesigning everything costs money and time. Consolidation gets you 80% of the benefit at 20% of the cost.

When you’re evaluating consolidation vs. centralized, ask: Can you afford to migrate transactional authority into the hub? If yes, centralized wins long-term. If no—and for most large organizations, the answer is no—consolidation is the right call. You can always evolve consolidation toward centralized over a decade, piece by piece. You can’t go backward easily—moving from centralized back to consolidation means accepting that your hub now depends on source systems for some things, which feels like a regression.

Domain-Specific Fit: Product vs. Customer vs. Party

Each master data domain has different characteristics, and some MDM implementation styles fit better than others.

Product MDM

Product data is typically hierarchical (variants nested under SKUs, SKUs under categories), relatively stable (SKU 12345 doesn’t change identities weekly), and owned by a clear source of record (maybe the PLM or ERP). Product MDM works well in consolidation or centralized style because you can make a clean call about authority. The PLM feeds the hub; the hub publishes to e-commerce, pricing, supply chain. Or the hub is transactional—product teams publish directly into the hub.

Product MDM struggles in registry style because products need stable identities. If your catalog says “this product exists in SAP as SKU-123 and also in NetSuite as ITEM-456,” that ambiguity breaks downstream consumption. You also rarely need bidirectional sync for product—you don’t need the ERP to read product changes back from the catalog. Consolidation or centralized are the natural fits.

Customer MDM

Customer data is noisier than product data—customers change addresses frequently, they have multiple ways to contact you, they appear in multiple systems at different stages of their lifecycle. Customer MDM is the most common domain where organizations implement registry or coexistence because you can’t eliminate source systems (the transaction system owns the relationship) and you often need bidirectional sync (when a customer updates their address via the mobile app, it needs to hit the CRM, the core system, and the risk system simultaneously).

That said, large B2C organizations often run consolidation for customer MDM—the hub is authoritative for segments, lifetime value, and risk score, while the transaction system owns the orders and payments. This is the “hub is the analytical master, source systems are transactional masters” model.

Party Data (Suppliers, Distributors, Partners)

Party data is famously distributed. Suppliers exist in your procurement system, but also in the ERP (because they have GL accounts), and also in your supplier portal (because they update their own bank details), and also in your logistics system (because they have shipping methods). No single system should be authoritative—they’re all peers.

This is where registry style shines. You maintain a registry that says “Acme Corp is known as SUPP-12345 in Ariba, VEND-789 in SAP, and XYZ-001 in our supplier portal.” Applications can look them up by any identifier. Registry handles the ambiguity well because party data is inherently distributed.

Party data rarely works in consolidation—you’d need to pick one system as authoritative, which creates a political battle and defeats the purpose of having multiple systems. Coexistence is possible but complex. Centralized is generally overkill because most organizations can tolerate the slight latency of registry-style lookup.

Location Data

Location master data (stores, warehouses, distribution centers) tends toward consolidation or centralized. There are usually fewer location records (thousands vs. millions), they’re relatively stable, and they benefit from a single golden record that all systems read from. If you have a location in the hub, and the ERP is stale, you want systems to read from the hub, not from the ERP. Consolidation or centralized both work—the choice depends on how much you want the hub to be transactional vs. reference-only.

Choosing a Style by Domain and Maturity

Selecting an MDM implementation style should follow a simple decision tree: domain characteristics first, then maturity, then infrastructure readiness.

For product data: Start with consolidation. It’s the default fit. Only consider centralized if you have cloud architecture and can afford transactional operations. Only consider registry if your product domain is highly distributed (e.g., you sell through many marketplaces and can’t eliminate any single source).

For customer data: Assess your need for bidirectional sync. If you have two to three systems that must stay synchronized in near-real-time, coexistence is viable if your infrastructure supports it. Otherwise, consolidation is the default. Only move to centralized if you’re greenfield or in a major rebuild.

For party data: Favor registry unless you have a compelling reason to have one authoritative party system. Party data’s strength is staying distributed.

For location data: Consolidation is the default unless you’re highly centralized (one company, one geography, homogeneous systems), in which case centralized works. If you have highly distributed operations with regional autonomy, registry is acceptable.

Then, assess your organization’s maturity:

Early maturity (just starting data governance, legacy systems): Registry or consolidation only. Do not attempt coexistence or centralized. You don’t have the operational discipline or infrastructure yet.

Mid-maturity (stable governance, some cloud infrastructure): Consolidation is your default choice for most domains. You can attempt coexistence if you have only two to three systems and genuine business urgency. You can migrate existing consolidation toward centralized if you’re committed to the multi-year effort.

High maturity (modern cloud architecture, strong data governance, cross-functional governance boards): You can afford any style. The choice depends on domain fit, not capability constraints.

Your infrastructure also matters. If you don’t have event streaming (Kafka, pub-sub), coexistence is very hard—you’ll be building custom sync code and debugging collisions forever. If you don’t have strong API gateways and caching layers, centralized is fragile. Start with what you have. Don’t choose a style that demands infrastructure you don’t possess and can’t realistically build.

The Hidden Cost of Wrong-Fit Styles

Choosing the wrong style is often invisible until you’re deep in implementation. The tool works fine. The governance model seems reasonable. But the operational reality keeps clashing with the style you chose.

I’ve seen organizations attempt consolidation style for customer data in financial services, only to discover that regulatory requirements demand that every system maintain its own audit trail and consent record. Consolidation’s periodic batch sync created gaps in the audit trail. They should have chosen coexistence or registry.

I’ve seen coexistence implementations fail because they underestimated the complexity of conflict resolution. They hardwired a “last write wins” rule, discovered that “last write” was often stale data from a cache sync, and spent six months rewriting conflict logic. A simpler style (consolidation or registry) would have prevented that.

I’ve seen centralized attempts fail because the organization underestimated the operational readiness required. The hub went down for a patch, and suddenly customer service couldn’t update a customer address. They reverted to letting the CRM be transactional, which broke the “hub is the single truth” model. They should have started with consolidation and evolved from there.

The cost is usually measured in delayed timelines, rework, and team morale. You lose six months to discovery that the style doesn’t fit your domain. Then you replatform or redesign, which costs more time. Meanwhile, your governance team is frustrated because they’re managing a system that fights them.

Avoid this by matching the style to the domain and maturity honestly. If you can’t justify why you’re not choosing consolidation (the middle ground), you probably should choose consolidation. Only pick registry, coexistence, or centralized if the domain characteristics or maturity level clearly points there.

Transitioning Between Styles

Most organizations don’t pick a style and stay with it forever. You might start with registry because it’s the fastest to implement, discover that you need better governance, and evolve to consolidation. Or you might start with consolidation and realize that you have the maturity and business case to move to centralized.

These transitions are possible, but they’re not free. Moving from registry to consolidation means building a curated golden record and convincing systems to read from it instead of maintaining their own copies. Moving from consolidation to centralized means migrating transactional authority into the hub.

The key to manageable transitions is domain-by-domain migration, not big-bang. If you’re running registry for party data and consolidation for product data, you don’t have to change them both at the same time. You can evolve the product consolidation toward centralized while keeping party in registry. This reduces risk and lets you learn from one domain before applying the lesson to another.

Documentation and steward training matter enormously when transitioning. A steward who’s been working in registry style for three years has different mental models than one working in consolidation. When you transition, you’re not just changing systems—you’re changing roles, responsibilities, and workflows. That’s why how to create efficient master data management workflows and approvals is critical—your approval workflows, steward roles, and handoff procedures must evolve with the style change.

Plan transitions to happen at natural inflection points: when you’re selecting new tools, when you’re rebuilding a major system, when you’re onboarding a new domain into MDM, or when your organization reaches a new maturity level.

Bottom Line

The MDM architecture you choose shapes every downstream decision—tools, governance structure, team skills, and ultimately whether the program delivers value or becomes a cost center. There’s no universal best style. Registry is lean and works for distributed domains like party data. Consolidation is the pragmatic middle ground that fits most product and customer use cases. Coexistence handles the rare cases where multiple systems must stay synchronized in near-real-time. Centralized is the architectural ideal but demands organizational and operational maturity that most organizations don’t yet possess.

Pick your style by matching it to domain characteristics (product data is stable and hierarchical; party data is distributed; customer data is noisy and multi-sourced) and organizational maturity (don’t choose coexistence or centralized if you’re early in governance). Be honest about your infrastructure readiness—if you don’t have event streaming, coexistence will fail. And plan to evolve: you don’t have to start with centralized, but you can migrate consolidation toward it over time.

The practitioners I’ve worked with who get this right share one trait—they choose deliberately, they document why, and they’re willing to revisit the choice if the domain or business changes. They don’t let legacy decisions trap them, but they also don’t change styles reactively. Match the style to the reality on the ground, build it well, and you’ve got a foundation that lasts.

Frequently Asked Questions About MDM Implementation Styles

What is registry style MDM?

Registry style MDM matches and links records from multiple source systems without creating a central master copy. The hub maintains identifiers and relationships—“this customer is known as ID-123 in System A and ID-456 in System B”—but doesn’t own or update the records themselves. Each system remains authoritative for its data. Registry is lightweight, regulatory-friendly, and suits distributed domains like party data.

What is consolidation MDM?

Consolidation MDM pulls data from multiple source systems into a central hub, where it’s cleansed, standardized, and validated. The hub then publishes a golden record to consuming systems. Source systems remain transactional authorities, but the hub is authoritative for attributes. Consolidation is the most common style and the pragmatic default for most product and customer data domains.

What is coexistence MDM?

Coexistence MDM maintains multiple systems that are kept in bidirectional sync. The hub and source systems are peers—changes in one propagate to others in near-real-time. Coexistence demands sophisticated conflict resolution, real-time infrastructure, and operational discipline. It’s appropriate only when you have two to three mission-critical systems that must stay perfectly synchronized.

What is centralized MDM?

Centralized MDM makes the hub the system of record for both master data and transactions. Applications and source systems read from the hub on demand; they don’t author or own data. Centralized is the architectural ideal but requires the hub to perform like a mission-critical transaction system. It’s best suited for greenfield environments or organizations with advanced maturity and cloud architecture.

How do I choose between consolidation and centralized MDM?

Choose consolidation if you need to keep source systems transactionally authoritative and you’re not ready for a wholesale system redesign. Choose centralized only if you have the maturity, infrastructure, and business case to migrate transactional authority into the hub. Consolidation gets you 80% of the benefit at 20% of the cost.

Is registry style MDM still used?

Yes. Registry style is ideal for domains like party data where no single system should be authoritative, and for regulated industries where you must maintain clear lineage between records and their sources. It’s also the fastest to implement when you don’t need curated master data.

Can I change MDM implementation styles?

Yes, but transitions are not free. You can evolve consolidation toward centralized over time. You can migrate registry to consolidation if governance requirements increase. Plan transitions domain-by-domain rather than big-bang, and budget for workflow changes, steward retraining, and system replatforming.

What infrastructure do I need for coexistence MDM?

Coexistence demands event streaming (Kafka, pub-sub, message queues), robust conflict detection and resolution logic, and strong audit trails. Without real-time or near-real-time sync, you’ll face constant collisions. Batch sync doesn’t work for coexistence.

Which MDM style is best for product data?

Consolidation or centralized are the natural fits for product data. Product records are stable, hierarchical, and benefit from a single authoritative version. Only choose registry if you have a highly distributed product domain (e.g., multi-marketplace sellers where no single system owns all products).

Which MDM style is best for customer data?

It depends on your system landscape and regulatory requirements. B2C organizations often use consolidation (the hub owns segments and risk; transaction systems own orders). Financial services often use registry or coexistence (regulatory lineage and near-real-time sync demands). B2B customer data often uses consolidation unless you have a strong business case for coexistence.