MDM in M&A: What I Learned Aligning Data Across 20 Countries
When two companies merge, their data doesn't merge automatically. MDM in M&A is a governance war fought on multiple fronts. Here's what I've learned from the inside.
TL;DR: When two companies merge, their data doesn’t merge automatically. Master Data Management in M&A contexts is not a migration project — it’s a governance war fought on multiple fronts simultaneously. Here’s what I’ve learned from the inside.
When a company acquires another, the press release talks about synergies, market expansion, and strategic fit.
Nobody talks about the materials master.
But behind every successful merger sits a mountain of unglamorous, mission-critical work: reconciling product catalogs, customer databases, supplier records, and organizational structures that were built in different languages, by different teams, in different ERPs — sometimes over decades.
I’ve spent the last few years doing exactly this work. As an MDM Product Designer on a global industrial data platform, I’ve been involved in aligning data referentials across acquisitions in multiple countries, working through what I’ll generously call “interesting data quality situations.”
This is what I learned.
1. MDM in M&A is a governance project, not a data migration project
The first mistake most organizations make is framing M&A MDM as a technical problem. “We need to migrate their data into our SAP.” Full stop.
That framing is wrong, and it leads directly to expensive failures.
The real question isn’t how do we move the data — it’s which data do we keep, who owns each domain, what are the rules, and what happens when two records conflict?
A Material Master record in an acquired company might represent the same physical product as one in the acquiring company’s SAP — but they’ll have different IDs, different descriptions, different units of measure, different classification hierarchies. Sometimes they’ll have subtly different specifications that matter enormously to procurement, finance, or regulatory compliance.
Migrating data without resolving those conflicts doesn’t merge the companies. It creates a new category of problem: phantom duplicates and ghost references that silently corrupt downstream reporting for months.
The governance question has to come first: who decides which record wins? That question cannot be answered by IT.
2. You need business ownership before you touch a single record
I’ve seen MDM programs stall for months because the technical team was ready but couldn’t get decisions from the business side.
In an acquisition context, this is even harder than usual. The acquired company’s teams are managing uncertainty about their jobs. The acquiring company’s teams are overloaded with integration work. Neither side wants to take ownership of a “data problem” on top of everything else.
The MDM team’s first job — before modeling, before tooling, before governance rules — is to identify a business owner for each data domain. Material. Packaging. Customer. Supplier. Organizational structure.
That person needs to:
- Understand the business impact of data quality decisions
- Have the authority to make calls when the two sides conflict
- Be accountable for the referential in their domain long-term
Without this, you’ll build technically correct MDM rules that nobody respects because nobody owns them.
3. Rebinding is the most underestimated risk
When IT systems are migrated as part of an acquisition — moving from one SAP instance to another, for example — all the internal identifiers change. A Material that was MAT-00123456 in the old system becomes something different in the new one.
This process is called rebinding (or remapping). It sounds mechanical. It’s actually terrifying.
Because every business process that was built on top of those old identifiers — purchase orders, contracts, bills of materials, quality certificates, customs documents, reporting dashboards — now needs to be updated. And in a large acquisition with thousands of materials and millions of historical documents, you cannot update everything manually.
The rebinding waves need to be:
- Planned by domain (not all at once — phase by type of material, by region, by criticality)
- Impact-mapped cross-domain before execution (MDM → Finance → Procurement → Reporting → Compliance)
- Tested in a sandbox with real production data volumes before going live
- Monitored post-migration with rollback criteria defined in advance
The wave I’ve seen go most wrong is always the one someone described as “straightforward.” There is no straightforward rebinding wave in an M&A context.
4. Cross-domain impact mapping is not optional
MDM data doesn’t live in isolation. A Material Master record affects:
- Procurement: what gets ordered, from whom, at what price
- Finance: account assignment, valuation, cost centers
- Sales: what can be sold in which market, pricing, configurability
- Compliance/Sustainability: regulatory classifications, packaging data for declarations
- Reporting: every BI dashboard that aggregates by material category
When you change a material record — even a seemingly minor attribute like the base unit of measure — you can break any or all of the above.
Before any MDM action in an M&A context, you need a cross-domain impact matrix: for each type of change, who is affected, what needs to be validated, who signs off.
This sounds bureaucratic. It’s actually the thing that saves the project.
The MDM team’s job is not just to manage the referential — it’s to be the custodian of cross-domain coherence. You’re the one who knows that changing the Packaging classification for a material will affect both the Finance reporting hierarchy and the Sustainability data model. Nobody else in the project has that complete picture.
5. Speed is the enemy in phase 1, but the imperative in phase 2
M&A integrations are always under pressure. Executive sponsors want synergies realized. Finance wants reporting consolidated. Business teams want the old system decommissioned.
The MDM team absorbs this pressure badly.
In phase 1 (stabilization), speed is the enemy. Rushing governance decisions, skipping validation steps, or merging referentials before ownership questions are resolved creates technical debt that is extraordinarily expensive to fix later. This is the phase where you need to hold firm, even when it’s uncomfortable.
In phase 2 (optimization), speed becomes the imperative. Once the referential is stable, the governance model is in place, and data quality rules are running — you can accelerate. This is when the MDM platform starts delivering actual value: unified reporting, reliable procurement, clean sustainability declarations.
The projects that fail are usually the ones that tried to do phase 2 before phase 1 was done.
Practical checklist: if you’re about to go through a merger
- Appoint business owners per domain before the technical work starts. Not “the MDM team will handle it” — actual business people who own the decisions.
- Map your data domains and their cross-domain dependencies early. Material, Customer, Packaging, Supplier, Org — know how they connect.
- Plan rebinding waves carefully. Smaller waves, more validation, real production data in testing.
- Don’t rush governance. The pressure to go fast is real. The cost of rushed governance is higher.
- Build your MDM platform to last. The acquisition is an event. The referential needs to serve you for the next 10 years.
And finally: MDM is never just an IT problem. The technical layer enables governance. But governance is a people problem — who owns what, who decides when things conflict, who is accountable for quality over time. Get that right first.
Babacar GUEYE is an MDM Specialist and Enterprise Architect with 10+ years in banking, insurance, and industrial sectors. He is the founder of Bakene — a consulting and product studio focused on data architecture and AI. Available for MDM consulting missions.
