Master data governance for the S/4HANA project kickoff: checklist
A readiness checklist for the PMO and sponsor: what master data governance must prove before an S/4HANA project kickoff and how to handle each gap you find.
Master data governance is ready for an S/4HANA project kickoff when every critical item can be backed by evidence: roles named per object, a minimum policy approved, a decision forum with deadlines, a measured quality baseline and a quality criterion per object for moving between phases. Gaps do not have to delay the project, but each one needs an owner and a date before the Explore workshops.
It is common for an S/4HANA kickoff to arrive with a schedule, a communication plan, a risk register and a staffed team, and not a single line on who decides about the data. The slides show the phases, the workstreams and the mock load dates. When someone asks who will approve the material description standard, the answer is usually "we will sort that out in Explore".
Then, in Explore, the procurement workshop stalls because nobody in the room can say whether a field is mandatory. The consultant suggests a standard, the business accepts it to keep things moving, and three months later the first mock load comes back with errors in a large share of the suppliers. The conversation turns into "the customer's data is bad", when what was missing was a decision made earlier by someone with the authority to make it.
What does SAP Activate provide for master data?
SAP Activate, SAP's implementation methodology, organizes a project into workstreams. According to SAP Learning, one of the suggested workstreams is Data Management, covering data loading, data cleansing and data lifecycle management, with three subflows: Data Migration, Data Volume Management and Master Data Management. The stated target of Master Data Management is high data quality, data unification and its efficient management (SAP Learning, Discovering the Workstreams).
The same lesson describes Signoff within the Project Management workstream: how to verify whether the project is ready to move on (the Q-Gates) and with which criteria. It also presents project governance as the framework in which the project manager and sponsors make decisions, which includes establishing governance roles, responsibilities and authorities and making escalation decisions; whoever sets up that governance needs to identify the key players who will be part of it. The lesson talks about project governance and does not use the term "data governance". That is why the checklist in this article is a recommendation for fitting master data governance into that structure, not a requirement of the methodology.
One point in the lesson shows why names need to exist early. In the table of project roles by workstream, the Data Management row lists, on the customer business side, Business Data Owner (which SAP describes as data custodian), Data Preparation Expert, Master Data Change Requestor, Master Data Maintainer and Master Data Sponsor; on the customer IT side, Data Extraction Expert, DVM ALM Process Owner and Master Data Manager (described as data steward); and, on the implementation partner side, Data Migration Architect, Data Migration Developer and Data Volume Management Consultant. These SAP names do not map one to one to the owner and steward roles described in the post on who is the data owner and who is the data steward, and each company adapts the naming. Among the project governance bodies, level 3 includes an Integrating Committee, which makes decisions on integration and master data management across projects (SAP Learning, Discovering the Workstreams). If SAP itself lists master data roles on the customer side, it makes sense for them to have names before the kickoff.
How do you know master data governance is ready for the kickoff?
The useful question for the PMO and the sponsor is: what already exists and can be shown? An answer like "we are aligning on it" does not count. Each item needs evidence someone can open: a signed list, meeting minutes, a dated report.
Step 1: list the objects in scope
Material, supplier, customer, service, asset. The checklist is applied per object, because one object can be ready while another is not. It is common for material to have a clear owner and for customer to have nobody.
Step 2: ask for the evidence behind each item
Use the table below. For each row and each object, mark "exists" or "does not exist". Avoid "in progress": either the evidence is ready, or the item becomes an open point with an owner and a date.
Step 3: decide what to do with each gap
Not every gap delays the kickoff. The "If it is not ready" column gives a way forward for each item and its deadline, which is almost always the end of Prepare or the start of the Explore workshops.
Step 4: take the result to the project decision forum
Open points become items in the project plan, with an owner, a date and follow up in the same forum that handles risks and scope. That way they come up in the Q-Gate discussion instead of surfacing in the first mock load.
Master data governance readiness checklist
| Item | Evidence that proves it | Who provides it | Risk if missing | If it is not ready |
|---|---|---|---|---|
| Roles named per object | List with the name of the data owner and the data steward for each object in scope, validated by the sponsor | Sponsor and business area directors | Data decisions end up with the consultant or with IT; workshops have nobody who speaks for the business | Name an interim owner per object by the end of Prepare, with a date for the permanent one |
| Minimum policy approved | Short document, approved and published, with items such as who requests a new record, who approves it, what a mandatory field is and where each object's standard lives | Master data lead, with sponsor approval | Each project team creates its own rules and they contradict each other | Approve a minimum version with what affects the Explore workshops and log the rest with an owner and a date |
| Decision forum with escalation and deadlines | Record of who decides about data, how quickly they respond and where a deadlock is escalated | PMO and sponsor | Data issues pile up and only appear in the mock loads | Use the project governance forum with a standing data item until a dedicated forum exists |
| Data standards per object | Description standard, mandatory fields and entry rules defined, or with an owner and a date to define them | Data owners, supported by data stewards | The standard is decided in a rush during the workshop by whoever is in the room | List the open standards, each with an owner and a date before that object's workshop |
| Quality baseline measured | Report with legacy indicators per object (completeness, material duplicates, validity of supplier documents) and the measurement date | Master data lead, with the extraction done by IT | Nobody can size the cleansing effort or prove improvement later | Measure at least completeness and duplicates for the main objects during Prepare |
| Quality criterion per object for phase transitions and mock loads | Written criterion per object, accepted by the PMO as part of the project Q-Gate | PMO with the data owners | A load is approved because it ran, not because the data is correct | Set a provisional criterion before the first mock load and review it against the baseline |
| Owner of the mapping and transformation rules | Name of the person responsible per object and a single place where the field mapping and rules are maintained | Data owners with the migration team | Conversion rules are decided by whoever writes the load program | Record the owner for each object by the end of Explore |
| Rule for creating records during the project | Written decision: freeze from a given date, or dual maintenance with a named person and a control | Sponsor, operations and PMO | Records created in the legacy system after the last mock load are left out or loaded without treatment | Decide before the first mock load and inform the teams that create records |
| Governance plan for Run | Definition of who maintains each object after go-live, with a request and approval flow | Sponsor and master data lead | Master data starts degrading again soon after go-live | Add it as a project deliverable, with an owner and a date before cutover |
| Key users enabled on master data concepts before Explore | Enablement schedule and attendance list | PMO and master data lead | Workshops spend time explaining concepts instead of deciding | Schedule the enablement at the start of Explore, before the Fit-to-Standard workshops |
Three notes on the table. It asks for roles to be named, not for the full responsibility matrix to be finished; to choose who is the owner and who is the steward, see the article on data owner vs. data steward in master data. The baseline asks for a few indicators and a date; how to calculate each one is covered in how to measure master data quality. And the table does not decide what to clean before the conversion; for material data, that triage is in the article on the material master before an S/4HANA conversion.
What does the checklist look like in practice? (hypothetical example)
Hypothetical example, created only to illustrate how the checklist is used. It is not a customer case and the numbers are illustrative.
A manufacturer is about to start an S/4HANA project with three objects in scope: material, supplier and customer. Three weeks before the kickoff, the PMO runs the checklist with the sponsor.
- Material: has a named data owner (the supply manager), a defined description standard and a duplicate measurement taken the year before. The quality criterion for mock loads and the rule for creating records during the project are missing.
- Supplier: has a steward, but no owner has been named, because procurement and finance disagree on who is accountable. There is no baseline for expired documents or for registration data that does not match official records.
- Customer: none of the items exist.
In this hypothetical count, most of the 30 combinations (10 items by 3 objects) are marked "does not exist". The sponsor does not postpone the kickoff. He names an interim owner for supplier and another for customer, approves a one page minimum policy, decides that the project forum will have a standing data item with five business days to reach a decision, and makes the supplier and customer baseline a Prepare deliverable. The other gaps get an owner and a date before the Explore workshops.
What comes out of the meeting is a short list of gaps, each with someone responsible, which the PMO tracks like any other project risk.
Where to start
- List the master data objects in the project scope and, for each one, who creates, changes and approves records today.
- Go through the table above with the PMO and the sponsor, object by object, marking only "exists" or "does not exist".
- Measure the baseline for the main objects before the kickoff, even if it is just two or three indicators.
- Turn each gap into an item in the project plan, with an owner and a date before the Explore workshops.
- If customers and suppliers are in scope, also review the points about Business Partner master data in S/4HANA, so the data standard is ready for the workshops.
- To see how migration and data cleansing fit into the project phases, visit the page on data migration to SAP S/4HANA.
Frequently asked questions
Can the project start before master data governance is ready?
Yes, as long as the gaps are visible and each one has an owner and a date. The risk lies in starting without knowing what is missing. The recommendation is to close the items that affect the workshops (roles, decision forum and standards per object) by the end of Prepare, and the quality items (baseline and criterion per object) before the first mock load.
Who should sponsor data governance in the project?
Someone with authority over the business areas that create and use the data, in addition to IT. In many projects it makes sense for this to be the project sponsor, who already arbitrates conflicts between areas. What does not work is leaving the role with the implementation partner's project manager, who is not accountable for the business after go-live.
Do I need SAP MDG to have master data governance in S/4HANA?
The checklist items are decisions about roles, rules and criteria, and none of them depends on a specific tool. The tool choice comes after those decisions. To compare approaches, see the article on SAP MDG or a complementary MDM.
Is data governance the same as project governance?
No. In SAP Learning, project governance is the framework in which the project manager and sponsors make decisions, covering the project's roles, responsibilities, authorities and escalation. Master data governance answers who decides about the data, under which rules and with which quality criterion, and it continues after go-live. The two meet in the decision forum and at the Q-Gate, which is why the checklist suggests using the project forum until a dedicated one exists.
What changes between greenfield and brownfield for governance?
The checklist items apply in both cases; what changes is where the weight falls. When the current system is converted, the existing master data moves forward with the project, so the baseline and the decision on what to clean first matter early. When data comes from one or more legacy systems into a new environment, the field mapping, the transformation rules and the target standards need more attention. Confirm with the project team which approach has been chosen before prioritizing the items.
How 4MDG can help
In data migration to SAP, 4MDG works with acceptance criteria in each SAP Activate phase, quality reports with before and after metrics, and ongoing governance in the Run phase after go-live. If the checklist revealed gaps, start with the free assessment: it is done on a real sample of your data, with nothing to install, and shows in numbers how much is duplicated, incomplete or irregular. Would you rather talk first? Reach us through the contact page.
Sources
- SAP Learning, course Discovering SAP Activate: Implementation Tools and Methodology, lesson "Discovering the Workstreams". https://learning.sap.com/courses/discovering-sap-activate-implementation-tools-and-methodology/discovering-the-workstreams_e34f1cd2-362f-4008-a6bd-8085da9caabe. Accessed on October 30, 2026.
- 4MDG, Data migration to SAP S/4HANA. https://4mdg.com.br/en/migracao-sap-s4hana. Accessed on October 30, 2026.
- 4MDG, Consulting and assessment. https://4mdg.com.br/en/consultoria-e-diagnostico. Accessed on October 30, 2026.