Table of Contents
- 1. The Observation: Too Many ERP Projects Falter Because of Data
- 2. What Is an MDM, and Why Timing Matters
- 3. Centralizing Data and Preserving Transactional Flows
- 4. Harmonizing Data Outside the System: Independence from the ERP
- 5. Data Governance as a Lasting Foundation
- 6. Why Data Migration Is the Real Cause of ERP Project Failure
- 7. Less Risk on ERP Version Upgrades
- 8. An Investment That Pays Twice: MDM in the Age of AI
- 9. The Direct Impact on Change Management
- 10. Why Companies Still Don’t Do It
- FAQ
- Expert Insight
- Take Action
- References
1. The Observation: Too Many ERP Projects Falter Because of Data
Across fifteen years of transformation missions, one pattern keeps recurring with a consistency that should raise more alarm than it usually does: most ERP projects that go off track — over budget, past deadline, or with poor adoption — don’t go off track because of the tool chosen. They go off track because of the data being fed into it. The ERP, however modern and well configured, becomes the receptacle for years of accumulated inconsistency: duplicated customer records across subsidiaries, product hierarchies that were never harmonized, business rules hardcoded into spreadsheet macros that nobody can fully explain anymore.
This isn’t a new observation, but it remains oddly absent from project scoping conversations. Companies budget for the finance module, the procurement module, the CRM integration, user training — and treat data migration as just another technical line item, when it actually determines whether everything else succeeds. A perfectly configured ERP running on dirty data produces dirty results, faster and at greater scale than the legacy system it replaced, which people had at least learned to work around.
Deploying a Master Data Management platform — an MDM — before launching an ERP project fundamentally changes the nature of this risk. It isn’t a matter of technical convenience: it’s a strategic choice that determines whether switching ERPs becomes a full rebuild of governance from scratch, or an adjustment to a new tool on top of foundations that are already solid.
2. What Is an MDM, and Why Timing Matters
A Master Data Management platform — MDM — is a discipline and a dedicated system for centralizing, qualifying, and governing an organization’s master data: customer, supplier, product, site, and item records, and any structuring data that feeds multiple systems simultaneously. Unlike a transactional database tied to a single application, an MDM lives independently of any particular business tool — ERP, CRM, or otherwise.
It’s precisely this independence that makes timing so decisive. An MDM deployed after the ERP almost always inherits the same inconsistencies the ERP itself inherited from prior systems — it becomes a retroactive cleanup exercise, expensive and politically difficult, since it requires convincing teams already exhausted by an ERP project to take on yet another data initiative. An MDM deployed before the ERP, by contrast, allows data to be cleaned, structured, and governed upstream, then feeds the ERP with already-reliable master records — the ERP consumes clean data instead of inheriting a problem it didn’t create but will carry for years.
This sequencing difference isn’t an academic nuance. It determines whether the ERP project spends its first months in endless data migration workshops — the number-one cause of schedule slippage on this type of project — or can focus directly on functional configuration and user adoption, with reliable master data already validated upstream.
3. Centralizing Data and Preserving Transactional Flows
The first tangible value of an MDM lies in centralization itself. Before it’s in place, an organization’s master data typically lives scattered across several systems that don’t natively communicate: a customer record in the CRM, an item record in a legacy ERP, pricing rules in a spreadsheet maintained by a single person, supplier records duplicated between accounting and procurement. Each system holds its own version of the truth, with its own identifiers, its own formats, and often its own errors, never corrected for lack of cross-functional visibility.
An MDM centralizes these master records into a single environment, with a pivot identifier for each entity — a customer, a product, a supplier — that stays stable regardless of which downstream application is used. Centralization doesn’t mean every piece of data must physically live in one database: it means there’s a single, governed source of truth that other systems consume rather than independently duplicate.
Beyond static master records alone, a well-designed MDM also preserves modeled data structures and their associated transactional flows — the rules defining how data transforms, propagates, and updates across systems. This dimension is often overlooked in generic MDM discussions, which tend to focus solely on product or customer record quality. Yet it’s precisely this modeling of flows that makes a future ERP change far less risky: transformation and propagation rules aren’t locked inside the old ERP’s proprietary configuration — they live in an independent layer the new ERP can consume without having to rediscover and rebuild them from scratch.
In practice, a company migrating its ERP without an upstream MDM generally has to manually rebuild, inside the new system, the entire set of business rules accumulated over years in the old one — often undocumented, simply because someone on the team remembered how it worked. A company that already has an MDM sees those rules preserved independently of the tool change, reducing both the risk of error and the rebuild time.
4. Harmonizing Data Outside the System: Independence from the ERP
Harmonizing data outside the system is perhaps the most underrated aspect of an MDM deployed ahead of an ERP project. Many companies conflate data harmonization with ERP configuration itself — they assume the new ERP, once configured, will naturally impose consistency across the organization. That’s a common and costly mistake: an ERP enforces technical structure, not governance. It can function perfectly well with inconsistent data definitions as long as each individual module receives data in the format it expects, without any real cross-functional consistency ever being guaranteed.
An MDM, by contrast, carries harmonization as its primary function, independently of any particular application system. This independence has a major strategic consequence: it decouples governance from the tool. Whether the company uses one ERP today, a different one tomorrow, or several ERPs simultaneously across different subsidiaries — a common situation in groups built through acquisitions — master data governance stays stable and consistent, because it doesn’t depend on any of those systems in particular.
This independence becomes especially valuable in multi-subsidiary or multi-country organizations, where different entities have historically chosen different ERPs for local, regulatory, or simply inherited reasons following successive acquisitions. Without an MDM, harmonizing data across these subsidiaries requires either forcing a single ERP onto the entire group — a heavy, expensive, and often politically difficult project — or living with inconsistent records between entities, which complicates any consolidated reporting or group-level decision-making. With an MDM, each subsidiary can keep its local ERP while sharing a harmonized master data layer, making group consolidation possible without requiring full application uniformity.
5. Data Governance as a Lasting Foundation
An MDM, technically, is just a tool. Its real value comes from the governance it carries and sustains. That governance rests on concrete, documented elements: who owns each type of data, what validation and quality rules apply to each field, what the arbitration process is when sources conflict, and how changes to those rules are decided and tracked over time.
What distinguishes a lasting governance foundation from a one-off documentation exercise is its ability to survive organizational and technological change. Data governance locked inside an ERP’s proprietary configuration disappears — or must be entirely rebuilt — the moment that ERP is replaced. Governance carried by an independent MDM survives that change, because it was never coupled to the tool in the first place.
This durability changes the nature of the decisions a leadership team can make. Without an MDM, every major technology decision — switching ERPs, adding a CRM, deploying a new e-commerce platform — carries an implicit risk of regression in data quality and consistency, since each new system potentially starts from a blank slate on governance. With an MDM, that risk is structurally reduced: governance no longer depends on the technology choice of the moment — it becomes a genuine company asset, valuable independently of any single application’s lifespan.
6. Why Data Migration Is the Real Cause of ERP Project Failure
Studies on ERP project failure converge on one recurring factor, far more decisive than vendor choice or tool sophistication: the quality and reliability of data migration. An ERP project typically unfolds across several phases — scoping, configuration, testing, data migration, training, go-live — and it’s almost always the data migration phase that consumes the most unplanned time, generates the most friction between business teams and integrators, and most frequently pushes back go-live dates.
This isn’t surprising: at the point of migrating data, the project team often discovers, for the first time, the real scale of inconsistencies accumulated in existing systems. Duplicates that were suspected but never measured. Business rules that vary from site to site with no documentation explaining why. Mandatory fields in the new ERP that were simply never populated in the old system. This late discovery, mid-project, under schedule pressure, leads to decisions made under urgency rather than rigor — exactly the conditions that produce errors surfacing months later, once the system is live.
An MDM deployed before the ERP project moves this discovery upstream, to a point where it can be handled methodically rather than under the pressure of an already-committed go-live schedule. Inconsistencies are identified, arbitrated, and corrected in a context where the goal isn’t hitting a cutover date, but building a reliable reference dataset. When the ERP project then starts, the data migration phase becomes an exercise in technical connection to an already-clean reference source, not an emergency cleanup under time pressure.
This difference in context has a direct effect on budgets. The most frequently observed budget overruns on ERP projects come less from initial functional configuration than from poorly anticipated data migrations, which generate costly back-and-forth between the integrator and business teams — sometimes even after go-live, when data anomalies surface in real production use.
7. Less Risk on ERP Version Upgrades
Discussions around MDM often focus solely on the scenario of a full ERP replacement, overlooking a scenario at least as common and just as risky: upgrading an existing ERP’s version. Major ERP vendors regularly impose significant technical migration cycles — moving from a legacy version to a cloud architecture, for example, or ending support for an older version on a fixed timeline that forces migration.
These version upgrades are often, wrongly, perceived as purely technical operations, less risky than a full vendor switch since the system stays broadly the same. In practice, they carry data migration risks very close to those of a full replacement, particularly when the new version deeply changes the underlying data models — which is common during transitions toward more modern architectures.
A company whose data governance lives entirely inside the old system inherits the same problem as a full replacement: it must rebuild, in the new version, a detailed understanding of business rules that were often never formally documented. A company whose governance lives in an independent MDM approaches this upgrade with a structural advantage: master records and business rules stay stable throughout the operation, and effort concentrates on the technical connection between the MDM and the new version, not on a full rediscovery of the data.
This advantage repeats at every future version upgrade cycle, making it a cumulative benefit over time, not a one-off gain limited to the initial project.
8. An Investment That Pays Twice: MDM in the Age of AI
The rise of artificial intelligence in the enterprise adds a dimension often missing from traditional MDM discussions, and it strengthens the case for this kind of investment considerably. AI use cases — conversational agents, process automation, predictive analytics — all depend, without exception, on the quality and structure of the master data they run on. An agentic AI model connected to an inconsistent product catalog, full of duplicates and conflicting definitions, will produce unreliable outputs faster and at greater scale than an equivalent manual process — AI amplifies whatever strengths and weaknesses already exist in the data, it never spontaneously corrects them.
A company that invests in an MDM before its ERP project isn’t just securing that specific ERP project — it’s building a data infrastructure that becomes the foundation for every future AI use case, whatever form they take. It’s an investment that pays twice: once immediately, by reducing the risk of the ongoing ERP project, and once durably, by preparing the organization to extract real value from AI without having to redo, under the pressure of a new AI initiative, the same data reliability work that should have happened upstream of the ERP in the first place.
This perspective also changes how such an investment should be presented at the leadership level. An MDM framed purely as a technical prerequisite for the ERP project is often perceived as an added cost imposed by that project’s constraints. An MDM framed as the data infrastructure that will condition the success of every future technology investment — ERP included, but also CRM, AI, and Business Intelligence — fundamentally changes the nature of the decision: it’s no longer a line item in the ERP project’s budget, it’s a strategic investment for which the ERP is merely the first beneficiary, not the only one.
9. The Direct Impact on Change Management
One of the most concrete, and yet least often anticipated, effects of deploying an MDM before an ERP project plays out in change management. When data governance stays stable through an ERP change — because it’s carried by an independent MDM rather than the ERP itself — what users actually have to learn changes dramatically.
Without an MDM, switching ERPs generally forces users to learn a new tool and new underlying business rules at the same time, since data governance was intrinsically tied to the old system and must be rebuilt in the new one. This double cognitive load — new tool, new rules — is one of the leading causes of resistance and slow adoption observed in the field: users must relearn not just where to click, but what each field means, how it should be filled in, and why results sometimes differ from the old system’s.
With an MDM in place, data governance — definitions, rules, master records — stays identical before and after the ERP change. Change for users then concentrates purely on adjusting to the new interface, the new screens, the new data-entry flows — not on questioning what they already know about the meaning and use of the data itself. This narrower real scope of change, subtle as it may seem, has a measurable effect on adoption speed and on the level of resistance encountered.
Another benefit, less obvious but just as real, concerns process portability. When the new ERP technically allows it, business processes already defined and documented at the MDM level can be duplicated directly into the new system, rather than rethought from scratch. This possibility of duplication — rather than reconstruction — significantly speeds up configuration and testing phases, since the project team starts from an already functionally validated set of processes and focuses on their technical translation into the new tool rather than their complete redefinition.
10. Why Companies Still Don’t Do It
If the benefits of an MDM ahead of an ERP project are this structural, a fair question follows: why do so few companies actually do it? The answer lies in several reinforcing organizational and perceptual biases, worth naming precisely rather than ignoring.
The first is a deeply ingrained cultural bias: most organizations default to « pick the ERP first, think about data later. » The ERP is visible, tangible, associated with a change the whole company can perceive — new interface, new processes, new training. The MDM, by contrast, is largely invisible to end users: it has no dedicated interface most employees will use daily, and it produces no impressive demo for a leadership meeting. This relative invisibility makes it structurally harder to sell internally, despite its real impact on the success of the visible ERP project.
The second obstacle is the perceived upfront cost and organizational complexity. An MDM requires governance ex ante — naming data owners, arbitrating conflicting definitions between departments that have never had to agree before, building validation rules that will be enforced consistently. This governance work is often perceived as politically harder than the technical configuration of an ERP, because it involves cross-departmental arbitration rather than purely technical decisions settled by IT alone.
The third obstacle, arguably the most decisive in practice, is the absence of a natural executive sponsor for an MDM project. An ERP project almost always has a clear sponsor — often finance or the CEO’s office, driven by a direct and visible ROI: lower operating costs, better financial visibility, regulatory compliance. An MDM project, by comparison, has no immediately visible ROI in the same way — its value materializes indirectly, by reducing the risk of another project, or by preparing future AI-related benefits that aren’t yet quantifiable at decision time. This lack of an immediate, measurable benefit makes it hard to find a sponsor willing to champion it alone against competing priorities that promise a faster, easier-to-demonstrate return.
These three obstacles combine to create a status quo that’s comfortable in the short term but costly in the medium term: pushing MDM until after the ERP, because it’s easier to justify immediately, while often implicitly knowing that this delay only postpones the problem rather than avoiding it.
FAQ
Is an MDM essential for every company size, including SMEs?
The principle holds regardless of size, but the scale of deployment should be proportional: an SME with few subsidiaries and a limited product catalog needs a lighter governance approach than a large multi-country group, without abandoning the underlying principle of centralization and independence from the ERP.
How long does it take to deploy an MDM before launching an ERP project?
It varies by complexity and the number of master records involved, but a useful first structuring phase — naming data owners, defining priority rules, centralizing critical records — can often be achieved within a few months, without needing to reach perfect maturity before starting the ERP project in parallel.
Does the MDM mechanically delay the ERP project’s start?
Not necessarily — both projects can run in parallel with smart sequencing, prioritizing the MDM structuring of critical records used in the earliest phases of ERP data migration.
Do you need a dedicated MDM tool, or is good governance enough?
Governance matters more than the tool, but a dedicated tool makes applying that governance consistently at scale far easier — centralizing rules in a document doesn’t guarantee they’re actually followed day to day by every consuming system.
How do you convince leadership to invest in an MDM without an immediately visible ROI?
By explicitly tying the investment to the risk of the already-budgeted ERP project — an MDM is easier to justify as risk reduction for a decision already made than as a standalone initiative with no apparent link to current priorities.
Can an MDM coexist with several different ERPs within the same group?
Yes, that’s actually one of its most relevant use cases — an independent MDM allows subsidiaries running different ERPs to harmonize master data without requiring full application uniformity.
Expert Insight
I see too many wobbly ERP projects caused by poor data governance — not because the chosen tool was bad, but because nobody took the time, before signing the integration contract, to ask what data that new tool would actually run on. MDM isn’t an optional module you bolt on afterward to « improve data quality » — it’s the foundation that determines whether an ERP change, or a version upgrade, gets experienced as a full rebuild or as a simple adjustment. On the ground, that distinction translates into months of project time won or lost, and into resistance to change amplified or considerably reduced. That conviction directly shaped the design of VGS, our modular ERP+CRM+PIM+DAM+MDM platform: building MDM natively into the architecture, rather than bolting it onto an ERP that was never designed for it in the first place.
Take Action
Assess your data governance maturity before launching your next ERP project. Discover Diagnoz®, our organizational diagnostic platform, 7-day free trial.
