SAP quality gates: how to set them up and where they fail

A quality gate is a formal checkpoint between project phases. Before the team moves on, it has to show that agreed criteria are met. Pass, and you move forward. Fail, and you fix the problems first. On an SAP programme, the gates sit at the SAP Activate phase transitions, each with a named owner who has the authority to say "not ready".

One major consumer goods company in Singapore was rolling out SAP globally. The team rushed through testing to hit deadlines. I watched this disaster unfold. User testing barely happened, but executives pushed for the launch anyway. Within days, problems showed up: missing setups, broken workflows, data completely wrong. The weeks of post-launch chaos were caused by problems that had been visible before go-live. Nobody stopped to check.

I never skip quality gate reviews. No shortcuts, no rubber stamps. It takes more time upfront and saves months of cleanup later.

A gate is a decision point with a written standard, documented sign-off and real authority to delay the project. It is not a progress review or a steering committee status update.

Without that authority, reviews become rubber stamps. And rubber-stamp gates are worse than none, because they create false confidence. One retail client ran "reviews" that were basically rubber stamps. Six months in, they were hopelessly behind schedule because nobody had dealt with the issues those reviews should have caught.

SAP Activate has six phases: Discover, Prepare, Explore, Realize, Deploy and Run. Each transition is a natural gate. This is what I expect each gate to check.

Phase gate	Quality focus	Evidence to see	Pass when
Discover	Business case, executive alignment	Business case, high-level roadmap	Business case signed, sponsor committed
Prepare	Governance, team, risks	Charter, governance model, risk register	Charter approved, risk owners named, team onboarded
Explore	Fit-to-standard, design, integration approach	Fit-gap decisions, process designs, integration architecture	Process owners signed off; every gap has a decision
Realize	Configuration, integration testing	Test execution reports, defect log	Test thresholds met, critical defects closed
Deploy	Data, training, cutover readiness	Migration reconciliation, training records, cutover plan	Dress rehearsal done, rollback plan agreed
Run	Stabilisation and handover	Incident log, performance reports	Incidents within agreed limits, support handover signed

In practice, Explore, Realize and Deploy carry the most risk. A problem that clears one of those three costs the most when it surfaces after go-live.

1. 01DiscoverBusiness case signed, sponsor committed
2. 02PrepareCharter approved, risk owners named
3. 03ExploreEvery gap has a decision
4. 04RealizeTest thresholds met, critical defects closed
5. 05DeployDress rehearsal done, rollback agreed
6. 06RunIncidents within limits, handover signed

Each gate signed by one owner with the authority to say not ready

Write entry and exit criteria for every gate into the project charter before configuration starts. Criteria written under deadline pressure describe what the team can currently show, not what the project needs. I had a client try to combine phases to "save time". They ended up redoing weeks of work.

Criteria that give a yes-or-no answer

"Testing complete" is not a criterion. It starts arguments. I worked with a retail client whose gate simply said "UAT completed". Half the team read that as all tests executed; the other half as all defects fixed.

"95% of test cases executed, all priority 1 defects resolved, no open priority 2 defects older than five days" is a criterion. It produces an answer.

One manufacturing client's gates failed because the criteria were too vague. Nobody knew whether they had actually passed. Once the criteria became measurable thresholds, the phase-transition arguments stopped.

One owner with authority to delay

Every gate needs a named owner who can delay the project. One person, not a committee. I saw one project crash because nobody had the power to delay the next phase, even though the team was not ready.

The opposite works. One retail client appointed a senior director as gate owner. When he said "not ready", everyone listened. Put that authority in the charter.

Executive backing before the pressure arrives

Executives love quality gates until a gate threatens a deadline. One CIO overruled a failed gate to meet a quarterly target. The resulting issues cost twice what the delay would have. I have seen this pattern repeat many times, so I now ask for executive sign-off on the gate framework before the project starts.

Evidence from the system of record

Gate decisions need evidence: test execution reports, defect logs, process sign-offs, migration reconciliations. Pull it from the tool, not from what people say is done. One of my clients discovered through Solution Manager reports that 40% of its "completed" test cases had never been executed. They caught it before the gate, not after.

1. Map gates to phase transitions. For SAP Activate, at minimum after Prepare, Explore, Realize and Deploy. One energy client created random checkpoints in between and ended up with a mess.
2. Define entry and exit criteria before configuration starts. Agree test coverage, defect thresholds and the process owners who must sign. Put them in the charter and get the sponsor's signature.
3. Schedule gates with buffer. Put each gate on the calendar as an activity, not just a milestone. One of my retail clients set aside a full week before each gate just for cleanup.
4. Choose reviewers who can decide. Business leads sign off processes. Technical leads sign off configuration and integration. Consultants never sign for the business.
5. Keep the evidence in one place. Six months later, an auditor will ask who signed off the data migration. The answer should take minutes to find.
6. Make the results visible. One client put its gate dashboard on the wall of the project room. It was impossible to ignore.

Example exit criteria for the two gates that matter most

Realize gate:

1. Test execution at or above the agreed threshold, with results stored in the test tool.
2. No open priority 1 defects; priority 2 defects within the agreed age limit.
3. Every critical process signed off by its named process owner.
4. Integration tests run across full process chains, with documented results.
5. Every custom development approved against the clean core rule set for the programme.

Deploy gate:

1. Data migration dress rehearsal completed and reconciliation signed by the data lead.
2. Training completion by role at or above the agreed threshold.
3. Cutover plan rehearsed, with timings and go/no-go decision points.
4. Rollback plan documented and tested.
5. Hypercare team named, with escalation paths and severity definitions agreed.

If the Deploy gate shows unresolved reconciliation exceptions or untrained users and the business still wants to proceed, make it a documented decision with a named signatory. Not a default because nobody wanted to say no.

Two things have changed how I design gates on current programmes.

Clean core is now a gate criterion. SAP classifies extensions from level A (released interfaces only) to level D (modifications and direct table writes). At the Explore gate, every gap should have a decision: configure it, build it as a released-API extension, or reject it. At the Realize gate, check that no new level D objects crept in. Public Edition enforces this technically. Private Edition and on-premise do not, so the gate is what enforces it.

SAP Cloud ALM is the default tool. It is included in SAP cloud subscriptions with Enterprise Support, cloud edition, and in SAP Enterprise Support for on-premise customers (SAP Support). It covers fit-to-standard, task assignment, test orchestration and traceability. SAP Solution Manager 7.2 mainstream maintenance ends at the end of 2027, and SAP recommends moving to Cloud ALM before then (SAP Support). If you are mid-programme on Solution Manager, finish there. Plan new programmes around Cloud ALM.

Tools for managing gates

The tool matters less than the discipline. One retail client built a clean SharePoint gate process that worked beautifully for a mid-sized implementation. I have also seen gates fail on a full Solution Manager setup because the team kept parallel spreadsheets.

Tool	Role in gate management	Best for
SAP Cloud ALM	Fit-to-standard, tasks, tests, traceability	New S/4HANA programmes, cloud or on-premise
SAP Solution Manager 7.2	Project tracking, test and defect management	Programmes already running on it
Jira and Confluence	Tasks, defects, gate criteria and evidence	Teams already using Atlassian tools
Tricentis Tosca	Test automation and coverage reporting	Programmes with heavy test automation
ServiceNow	Approval workflows and audit trail	Companies already running ServiceNow

Whichever you choose, it has to be the single source of truth. A parallel spreadsheet always shows the version the team wants to show. My comparison of SAP testing and validation tools goes deeper on the test side.

Skipped under schedule pressure. When projects slip, gates are the first thing cut. On one project the reviews became rubber stamps, and the go-live was a nightmare: systems crashed, orders got stuck, and they rolled back completely. The three weeks they "saved" cost them three months of recovery.

Vague criteria. Covered above. If a criterion needs interpretation, it is a conversation starter.

Reviewers with no time. When key reviewers are spread across several projects, reviews become box-ticking. A Realize gate review on a mid-size programme should take at least half a day, with evidence read in advance.

Culture. Teams used to rushing milestones look for ways around gates. That changes when an executive says at kickoff that gates are mandatory, then proves it by refusing to override the first one that causes a delay.

Three numbers that show whether gates work

Track these to see whether gates are protecting the project or only looking like they do.

1. Defect leakage: the share of defects found after a gate that the gate should have caught.
2. First-attempt pass rate: if every gate passes first time, the criteria probably have no teeth.
3. Go-live incidents: high-priority incidents in the first 30 days are a direct verdict on the Deploy gate.

Gates belong in the charter from day one. My project charter guide shows where they fit, and the steering committee guide covers who should hold the authority to enforce them.

What is a quality gate in SAP projects?

A formal checkpoint between project phases. The team has to show that specific, measurable criteria are met before moving on. Each gate has a named owner with authority to delay the project. In SAP Activate, gates sit at the phase transitions, especially after Explore, Realize and Deploy.

What are the quality gates in SAP Activate?

SAP Activate has six phases (Discover, Prepare, Explore, Realize, Deploy and Run), and each transition is a gate. Discover checks the business case. Prepare checks governance and the charter. Explore checks design sign-off and gap decisions. Realize checks test results and defects. Deploy checks data, training and cutover readiness. Run checks stabilisation and handover.

What should SAP quality gate criteria include?

Criteria that give a yes-or-no answer. For Realize: test execution thresholds, open defects by priority, process owner sign-offs and integration test results. For Deploy: migration reconciliation, training completion by role, a rehearsed cutover plan, a tested rollback plan and a staffed hypercare team. Each criterion needs an owner who produces the evidence.

Why do quality gates fail in SAP implementations?

They get skipped under schedule pressure, the criteria are vague, reviewers have no time to prepare, or an executive overrides a failed gate. The root cause is treating gates as overhead rather than protection.

Which tool should I use to manage SAP quality gates?

For new programmes, SAP Cloud ALM. It is included with SAP cloud subscriptions and Enterprise Support, and supports fit-to-standard, testing and traceability. SAP Solution Manager 7.2 leaves mainstream maintenance at the end of 2027. Jira, Tricentis Tosca and ServiceNow work well where a company already runs them. The rule is one source of truth.

How do you assess go-live readiness at the final quality gate?

Check five things with evidence: data migration rehearsed and reconciled, training complete for each role, cutover plan rehearsed with go/no-go points, rollback plan tested, and hypercare staffed with escalation paths. If any fails and the business still wants to proceed, record it as a signed business decision.