Updated October 2026.

SAP is moving fast. AI-driven insights, S/4HANA migrations and Business Data Cloud all promise to change the way businesses run. But none of it delivers if your data is a mess.

Without clean, governed and trusted master data, AI produces flawed recommendations, S/4HANA projects inherit old inefficiencies and data-driven strategies fall apart under inconsistent numbers. Master data is the foundation of a scalable, future-ready SAP strategy, and it deserves to be treated that way.

Here are eight best practices, drawn from real SAP MDM projects, that separate the programmes that deliver from the ones that stall. If you work in retail, see our retail MDM best practices for the industry version.

1. Start with a clear business case

Many organisations rush into MDM without defining what they want from it. Before investing in tools or people, pin down why MDM matters to your business: inconsistent customer data, compliance risk from poor record-keeping, or procurement waste traced back to duplicate vendors. In SAP, this usually means tying the case to an initiative already on the roadmap, such as an S/4HANA migration, a clean core programme or an AI rollout that will only be as good as its data. A business case anchored to something the business already cares about gets funded faster than a general pitch for better data quality.

2. Define your single source of truth for each domain

Master data should be accurate, consistent and trusted by everyone. In practice, that means deciding what counts as the golden record for each domain (customers, suppliers, materials, financial data) and setting clear rules for how that record is validated, updated and kept in sync. In SAP, the move to the S/4HANA Business Partner model matters here. It combines what used to be separate customer and vendor objects into one framework, which is a chance to define a real single source of truth instead of inheriting years of fragmented ECC records.

The golden record also needs a model behind it. Before any build, agree which attributes belong to each domain, which are mandatory, how records relate to each other (a customer’s ship-to points, a material’s plants and storage locations) and which system owns each field. In SAP, that model has to fit the standard data structures, so new attributes are added through supported extension points. Our guide to structuring a master data model goes through the three modelling layers.

3. Assign clear ownership and accountability

Every data domain needs a named owner and a named steward, backed by more than a policy document. Should approvals sit with a central data team, or with the business users closest to the domain? Getting this structure right (see our guide to MDM roles) is what turns governance from theory into something that happens every day.

4. Automate governance instead of just documenting it

Policies that only live in a document get ignored under deadline pressure. Building governance into automated workflows, with mandatory field validation, approval routing and duplicate detection, means quality and compliance happen by default. On SAP landscapes, this is usually done with MDM automation tools alongside standard SAP MDG capabilities, catching bad data before it reaches the core. For a balanced view of MDG, read SAP MDG: Pros, Cons, and How to Evaluate Your Implementation Approach.

5. Integrate master data across ERP, CRM and BTP

Master data never lives in one place. It has to move consistently across every system that uses it: the core ERP, CRM, e-commerce platforms and any custom extensions built on SAP BTP. Weak integration is exactly how duplicate and conflicting records creep back in after an initial cleanse.

In practice, a sound integration design answers four questions for every domain:

• Where is the record created? One system should be the place new records start, usually the MDM tool or S/4HANA.
• How does it travel? SAP Integration Suite on BTP is the standard route between SAP and non-SAP systems, using APIs and events instead of nightly file transfers.
• Who wins on conflict? If the CRM and SAP disagree on a customer’s address, the design must say which system is right for which field.
• How fast must it arrive? A new customer may be needed in the web shop within minutes. A cost centre change can wait for a scheduled run.

Document these answers before the first interface is built. Changing them later means reworking every integration that depends on them.

6. Start small with a pilot, then scale

MDM programmes that try to govern every domain at once tend to overrun, go over budget and lose support before showing any return. Start with the domain causing the most visible pain (product or vendor data are common starting points), prove the value there, and use that momentum to extend to other domains. Our guide to the 4 styles of MDM implementation helps you choose the right set-up for the pilot.

This is also the point to bring in outside expertise if your team has not run an MDM programme before. A specialist who has seen the common failure points is often the difference between a pilot that builds confidence and one that quietly stalls.

7. Train your people as well as your systems

Technology alone does not fix data problems. User acceptance testing and proper training for data owners, stewards and end users decide whether a new MDM process gets followed or quietly worked around. A team that understands why the data matters, as well as how to fill in a field, keeps governance working long after go-live.

8. Measure business value with KPIs, continuously

Track the metrics that prove the programme is working: fewer duplicate records, better accuracy and completeness, efficiency gains and compliance. Measurement carries on well past project close. Master data degrades as new records are created and systems change, so ongoing monitoring and regular audits belong in the normal operating rhythm. Our data quality guide sets out the KPIs to use.

What We See Go Wrong in Real MDM Programmes

Across our SAP MDM projects, the programmes that stall tend to share a few patterns:

• The tool is chosen before the process is agreed. Teams buy software, then discover nobody has decided who approves a new supplier.
• The pilot covers too many domains. Customer, vendor and material all at once means none of them is finished when funding is reviewed.
• Clean-up happens once, before go-live. Without validation at the point of entry, duplicates return within months.
• Business users are trained last. If the people creating records only see the new process at go-live, they find workarounds.
• Success is measured in records cleansed. Leadership responds better to fewer blocked orders or faster supplier onboarding than to a count of fixed fields.

Each of these is a planning issue, and each is avoided by following the eight practices above in order.

Frequently Asked Questions

What are the most important MDM best practices?

Clear ownership for every domain, one golden record per domain, quality rules applied when records are created, and a pilot on the domain causing the most pain.

How long does it take to see results from MDM?

A focused pilot on one domain can show measurable results within a few months. Enterprise-wide programmes take longer and work best when phased by domain.

Do I need SAP MDG to follow these practices?

No. The practices apply whatever tool you use. SAP MDG and Maextro are two common ways to put them into action in an SAP landscape.

What’s Next

MDM is a strategic priority for any business investing in SAP AI, S/4HANA or Business Data Cloud. Governed data is what lets those investments deliver real value.

For the fundamentals behind all eight practices, see our Ultimate Guide to MDM. If you are choosing a platform to put them into practice, our MDM software guide covers what to look for. Or talk to our MDM team about where to start.