Master Data Management Roadmap: 12-Month Plan, Domains and Owners
9 min read ยท 2026-10-25
A master data management roadmap is a phased plan for creating one trusted version of your core business data, such as customers, products, suppliers or locations, and keeping it accurate across every system that uses it. A typical roadmap starts with one domain, sets up governance and stewardship, builds the data model and matching rules, connects the main systems and then extends to the next domain. The first domain often takes 9 to 12 months.
MDM programs rarely fail on technology. They fail because nobody owns the data, because the scope tries to cover every domain at once, or because the business does not see what changes for them. The template below covers 12 months in six phases for one domain, with a milestone you can check at the end of each phase. You also get a comparison of implementation styles, a filled-in example for customer data, owners and stewards, quality metrics and a one-slide way to present progress.
The roadmap at a glance
Goal: One master data domain has a governed golden record, maintained by named stewards and used by the CRM, ERP and reporting, within 12 months. Duration: 12 months
Business case and first domain (Weeks 1-6)
Tie MDM to a business problem and pick the domain to start with.
- List the business problems caused by bad master data, such as duplicate customers, wrong prices on invoices or slow supplier onboarding.
- Score candidate domains (customer, product, supplier, location) on business pain, number of systems involved and effort.
- Pick one domain and name a business sponsor who feels the pain most.
- Inventory the systems that create or use that domain's data and who maintains each one.
- Profile a sample of records to measure duplicates, missing fields and format problems.
Milestone: Business case approved by the sponsor, with the first domain, the systems in scope and a data quality baseline.
Governance and ownership (Weeks 5-12)
Decide who owns the data, who maintains it and how decisions are made.
- Name a data owner for the domain, usually a senior leader in the business function that relies on it most.
- Appoint data stewards in each team that creates or changes records.
- Set up a data governance council that meets monthly to approve definitions and resolve disputes.
- Write the first data standards: required fields, formats, naming rules and who can create or change a record.
Milestone: Owner, stewards and council in place, with data standards for the domain approved by the council.
Data model and implementation style (Weeks 9-16)
Design the master record and decide how it will flow between systems.
- Define the master data model: attributes, hierarchies, relationships and which system is the source for each attribute.
- Choose the implementation style: registry, consolidation, coexistence or centralized.
- Write match rules to find duplicates and survivorship rules to decide which value wins when sources disagree.
- Select or confirm the MDM tool and the integration approach with enterprise architecture.
Milestone: Data model, implementation style and match and survivorship rules signed off by the data owner and the architecture board.
Build, cleanse and match (Weeks 15-30)
Load the data, clean it and create the first golden records.
- Configure the MDM hub with the data model, validation rules and steward workflows.
- Load records from each source system and apply standardization, such as address and name formats.
- Run matching, then have stewards review uncertain matches in batches.
- Test with real business scenarios, for example creating a new customer or merging two duplicates.
- Reconcile record counts and key fields with source system owners.
Milestone: Golden records created for the full domain, with match results reviewed and reconciled with source system owners.
Integrate and go live (Weeks 28-40)
Connect the main systems so they use the golden record and keep it up to date.
- Build the integrations to the CRM, ERP and reporting platform following the chosen style.
- Change the create and update process so new records go through the agreed workflow.
- Train stewards and the business users who create records.
- Run a cutover with a rollback plan and a hypercare period of two to four weeks.
Milestone: Main systems using the golden record in production, with stewards handling the daily queue and hypercare closed.
Measure and extend (Weeks 38-52)
Prove the value of the first domain and plan the next one.
- Publish a monthly data quality dashboard for the domain.
- Compare the business problems from the business case with the baseline, such as duplicate rates or invoice errors.
- Document lessons learned and turn them into a playbook for the next domain.
- Pick and scope the second domain with its own sponsor and owner.
Milestone: First quality report against baseline shared with leadership, and the second domain approved with a sponsor and scope.
Pick the right first domain
Starting with every domain at once is the most common way to stall an MDM program. Each domain has its own owners, systems and rules, so doing them in parallel multiplies the meetings and the disputes. Start with one domain, prove the value and reuse what you learned.
The best first domain has a clear business pain that leadership already talks about, a sponsor who will push for decisions and a manageable number of source systems. Customer data is a common choice when sales and finance disagree on who the customers are. Product data is common for retailers and manufacturers struggling with catalog errors. Supplier data often comes first when procurement wants faster onboarding.
MDM implementation styles compared
The implementation style decides where the master record lives and how systems use it. It affects the cost, the integration work and how much each business process must change. Many companies start with a lighter style and move to a heavier one later.
Choose with enterprise architecture and the source system owners. A style that requires every system to change how it creates records will take longer, but it gives the most control.
- Registry: the hub keeps an index that links matching records across systems, without changing the sources. Fast to start, but source data stays messy.
- Consolidation: the hub builds golden records for reporting and analytics, while operational systems keep their own copies. Good for a first step.
- Coexistence: golden records are created in the hub and sent back to the source systems, which can still edit them. More integration work.
- Centralized: records are created and changed only in the hub, then sent to every system. Most control, most process change.
Example: a customer MDM roadmap filled in by quarter
Picture an industrial distributor with a CRM for sales, an ERP for orders and invoicing, and a separate e-commerce platform. The same customer often exists three times with different addresses, and finance spends days each month fixing invoice errors. Here is how the first year could look.
The consolidation style was chosen first because it improved reporting quickly without changing how sales reps work. Moving to coexistence is planned for year two.
- Q1, Case and governance: profiling shows many duplicate customers across the three systems. Sponsor: CFO. Owner: head of sales operations. Milestone: stewards named in sales ops and finance, standards approved.
- Q2, Model and build: customer model with account hierarchies, consolidation style, match rules on tax number, name and address. Owners: MDM lead and data architect. Milestone: hub configured, first match run reviewed.
- Q3, Cleanse and go live: stewards review uncertain matches, golden records feed the reporting platform and a daily sync to the ERP. Owners: stewards and integration lead. Milestone: go-live, hypercare closed.
- Q4, Measure and extend: quality dashboard live, fewer invoice corrections reported by finance, supplier domain scoped. Owners: MDM lead and procurement director. Milestone: second domain approved.
Who owns what
MDM is a business program with a technical component, not the other way around. If IT owns the data, the business will treat quality problems as IT tickets and nothing will change at the source. Put a business leader in charge of each domain and give stewards time in their job to do the work.
Write the roles into job descriptions or objectives where you can. Stewardship that depends on goodwill fades after go-live.
- Business sponsor: funds the program, chairs escalations, keeps it tied to the business case.
- Data owner: a senior business leader accountable for the domain's definitions and quality.
- Data stewards: people in sales ops, finance or procurement who fix records, review matches and apply the standards daily.
- MDM program lead: owns the roadmap, the plan and reporting to the council.
- Data architect and integration lead: data model, implementation style, interfaces.
- Source system owners: changes to CRM, ERP and other systems, reconciliations and testing.
Metrics to track
Measure two things: the quality of the master data and the business problems it was meant to fix. Quality metrics show that the program is working. Business metrics show that it matters. Take a baseline during profiling in phase one so you can show the change.
Report the metrics monthly to the governance council and quarterly to leadership, on the same dashboard every time.
- Duplicate rate: suspected duplicate records per thousand, from the MDM matching results.
- Completeness: share of records with all required fields filled in.
- Validity: share of records that pass format and business rules, such as valid tax numbers or postal codes.
- Steward queue: open tasks and average time to resolve them.
- Business impact: the problem from the business case, such as invoice corrections or time to onboard a supplier.
How to present it to leadership
Leadership does not need to hear about match rules. Open with the business problem from the business case and the baseline, for example how many duplicate customers exist and what that causes. Then show one slide with the six phases on a timeline, the domain in scope and the milestone for each phase.
In later updates, show the quality dashboard and one business result, such as fewer invoice corrections. Ask for decisions you need, like a steward role in a team that has not committed time. Keep the data model, the tool and the integration details in an appendix for the CIO and the architecture board.
Common mistakes to avoid
- Starting with every data domain at once stalls the program in meetings, so begin with one domain that has a clear business pain and a sponsor.
- Letting IT own the master data turns quality into a ticket queue, so name a business data owner and stewards for each domain.
- Cleaning data once before go-live without changing how records are created lets the mess return, so change the create and update process at the same time.
- Choosing the MDM tool before the data model and implementation style leads to costly rework, so agree on the model and style first.
- Skipping steward review of uncertain matches merges records that should stay apart, so have stewards review borderline matches before go-live.
- Reporting only technical progress hides the value, so measure the business problem from the business case and report it to leadership.
Frequently asked questions
What are the steps in a master data management roadmap?
Most roadmaps follow six steps: business case and first domain, governance and ownership, data model and implementation style, build and cleanse, integrate and go live, then measure and extend. Each step should end with a milestone the business can check. Repeat the cycle for each new domain.
How long does an MDM implementation take?
It depends on the domain, the number of source systems and the state of the data. The first domain often takes 9 to 12 months, and later domains go faster because governance and tools are already in place. Plan one domain at a time.
Which master data domain should you start with?
Start with the domain that causes the most visible business pain and has a sponsor ready to push for decisions. Customer data is common when sales and finance disagree on accounts, and product data is common for retailers and manufacturers. Keep the number of source systems manageable for the first one.
What is the difference between MDM and data governance?
Data governance sets the rules, roles and decision process for all company data. MDM applies those rules to core business entities and adds the tools and processes to keep one trusted record for each. MDM needs governance to work, but governance covers more than master data.