Acceptance criteria for RISE go live.

The acceptance criteria for a RISE with SAP go live are the most commercially significant set of clauses in the implementation contract, and they are also the clauses that the buyer most often signs without independent scrutiny. The implementation partner drafts them, the implementation partner runs the tests against them, and the implementation partner certifies that they have been met. The buyer reviews the certification, sees that the milestone is marked complete, and pays the milestone invoice. Months later, when the production system reveals defects that the acceptance tests did not catch, the buyer discovers that the acceptance criteria as drafted excluded the exact scenarios that have now broken. A buyer that engages the acceptance criteria as a contract negotiation rather than as a project formality protects the operating system that the contract is supposed to deliver. This article walks the categories of acceptance criteria that matter, the test evidence that supports them, and the contractual structures that make the criteria genuinely binding.

Why the standard acceptance criteria fall short

The standard acceptance criteria for a RISE implementation, as drafted by most large system integrator partners, focus on functional acceptance. The criteria describe the scenarios that the system is expected to handle, the inputs that the test cases supply, the outputs that the test cases verify, and the test environment in which the verification takes place. The criteria are passable in their structure but typically narrow in their scope. The functional scenarios are tested in a controlled environment with a limited dataset, a limited user concurrency, and a limited integration surface.

The production environment differs from the test environment along all three dimensions. The dataset is the full production volume rather than a sample. The user concurrency reflects the actual user community rather than a small test team. The integration surface includes the full set of inbound and outbound interfaces rather than the curated subset that the test cases covered. Defects that emerge in production after acceptance frequently sit at the intersection of dataset volume, concurrency, and integration complexity, three dimensions that the standard acceptance criteria did not test.

The standard acceptance criteria also typically omit non functional categories. Performance under peak load, stability across a multi day operating window, recovery from infrastructure failure, security control validation, data quality verification, and operational readiness of the support team are categories that most standard criteria touch lightly or not at all. The omissions matter because these categories are exactly where the RISE estate, once in production, encounters its first real tests.

The functional acceptance criteria

The functional acceptance criteria should cover the named business processes at the level of detail that the operating organisation needs to run them in production. For each named business process, the criteria should specify the trigger events, the inputs, the data dependencies, the integration touchpoints, the system behaviour, the expected outputs, the exception handling, and the user actions required.

The buyer side specification of the functional criteria is best done by the business process owners rather than by the IT project team. The business process owner knows which scenarios occur frequently, which scenarios occur rarely but matter when they do, which scenarios involve external counterparts, and which scenarios trigger downstream operational consequences. The acceptance criteria that the business process owner writes are more comprehensive and more grounded in operational reality than the criteria the IT project team writes.

The functional criteria should explicitly include the high impact low frequency scenarios. Year end close, quarter end close, monthly reporting, statutory submissions, supplier or customer onboarding edge cases, and the rare but operationally critical processes deserve named acceptance criteria even if they cannot be tested in the standard test cycle. Where the scenario cannot be tested, the criteria should require evidence of design completeness and of a defined operational runbook rather than evidence of a passed test.

The non functional acceptance criteria

The non functional criteria cover the categories that determine whether the system can sustain operational use. Performance criteria should specify the response time for named transaction classes under named user concurrency levels, with the test conducted under production scale data volumes. Stability criteria should specify a multi day soak test that exercises the integration surface and the batch processing schedule under realistic load.

Recovery criteria should specify the response of the system to the loss of a node, the loss of a network segment, the loss of an integration partner, the loss of an upstream master data source, and the restoration of service after each failure scenario. The recovery test plan should be a documented annex to the acceptance criteria, with named scenarios, named expected behaviours, and named completion thresholds.

Security criteria should specify the validation of the role design, the segregation of duties matrix, the authorisation object configuration, and the user provisioning workflow. The security criteria should include evidence from a configuration review and from a penetration assessment of the integration boundary, where the RISE perimeter meets the buyer environment.

Data quality criteria should specify the validation of the migrated master data, the conversion of historical transactional data where applicable, the integrity of the cross reference tables, and the reconciliation of the migrated balances. The data quality criteria should include a sign off from the business data stewards rather than from the IT migration team.

The operational readiness acceptance criteria

The operational readiness criteria sit alongside the functional and non functional criteria and address the question of whether the operating organisation can actually run the system after go live. The criteria should specify the training completion for the named user community, the readiness of the help desk and the application support team, the publication of the operational runbooks, the validation of the monitoring and alerting configuration, and the rehearsal of the incident response process.

The operational readiness criteria should include a rehearsed cutover plan. The cutover plan is the sequence of activities that converts the legacy estate into the production RISE estate over the cutover window, typically a long weekend or a week. The rehearsal should be conducted in a dry run environment with the full participation of the buyer team, the implementation partner team, and the SAP operations team. The acceptance criteria should require evidence of a successful rehearsal before the actual cutover begins.

The operational readiness criteria should also include a hyper care plan. The hyper care plan covers the elevated support model during the first weeks of production operation, with named individuals on call, defined response times for the named incident severity levels, and a defined handover from the implementation team to the steady state operations team. The acceptance criteria should require the hyper care plan to be documented, agreed, and resourced before go live.

Making the criteria contractually binding

The acceptance criteria become contractually binding through the milestone payment structure. The implementation contract should tie the milestone payment to the completion of named acceptance criteria, with the criteria attached as a contractual annex and with the test evidence required for completion specified in the annex. The standard partner contract usually structures the milestone payment around a partner certification of completion. The buyer side position should require independent verification of the test evidence, either by the buyer project team, by an independent quality assurance partner, or by a defined buyer sign off committee.

The contract should also include a retention mechanism. A defined percentage of the implementation fee, typically ten to twenty percent, should be held back at go live and released only after a defined post go live stability period during which the system operates without material defect. The retention mechanism aligns the partner economic interest with the post go live stability of the system, which is the moment when the buyer most needs the partner attention.

The contract should include defect remediation obligations. The standard partner contract often treats post go live defects as change orders. The buyer side position should require the partner to remediate defects against the acceptance criteria at no incremental charge for a defined warranty period, typically ninety days to twelve months depending on the engagement size.

Conclusion: the acceptance criteria are the system

The acceptance criteria are the operational specification that the buyer is paying for. A system that meets weak acceptance criteria is not a system that meets the buyer operational requirements. The standard partner drafted criteria are usually adequate for the partner economic interest, which is the certification of completion that releases the milestone payment. They are usually not adequate for the buyer operational interest, which is the receipt of a system that the operating organisation can actually run. The buyer that drafts the criteria in collaboration with the business owners, that covers functional, non functional, and operational readiness categories, and that ties the criteria to milestone payment and retention mechanisms, receives a system that meets the operating requirement. The buyer that signs the standard criteria receives a certification and a set of post go live problems. The acceptance criteria are not a project formality. They are the contract for the system that the implementation produces.