How do you write acceptance criteria for an S/4HANA migration before you migrate?
Define done on paper, from your own ECC evidence, before the first conversion run. Otherwise done means whatever the project team says it means.
The short answer
Write acceptance criteria as business outcomes you can check against your own ECC system before anything moves: which processes must still work, what documents and balances must reconcile, and how fast the critical transactions must run. Capture a baseline from ECC first, such as order-to-cash cycle times, open-item totals, and a sample of real documents with their expected results. Then keep a portion of those cases hidden from the team doing the conversion, so passing is not just the team confirming its own work. A migration is accepted when the baseline outcomes reproduce in S/4HANA within agreed tolerances and the business owner of each process signs off, not when the cutover rehearsal merely finishes without errors.
Why do S/4HANA migrations need acceptance criteria written first?
Most migration plans define activities (convert, load, test, cut over) and leave the definition of success implicit. When the weekend ends, 'it went live without a P1' becomes the bar. That is a statement about the project, not about the business.
Think of building a house without a drawing of the finished rooms. The crew can follow a schedule perfectly and still hand you something nobody agreed to. A written specification of what must be true at the end is the drawing, and it is cheapest to produce before conversion work shapes everyone's expectations.
What should the acceptance criteria actually cover?
Good criteria are observable and tied to a process owner. We group them into four families, which is a working heuristic rather than an SAP standard.
- Process outcomes: the critical end-to-end flows (for example order-to-cash and procure-to-pay) complete with the same business result as in ECC, including pricing, tax, and output.
- Financial reconciliation: balances, open items, and sub-ledger to general ledger totals agree between source and target at the cut date, within a stated tolerance.
- Master data integrity: business partner, material, and asset records convert without loss, and duplicates or blocked records are handled by a documented rule.
- Performance and operability: named transactions and batch jobs meet agreed run times, and interfaces, authorizations, and print or output behave as specified.
Where do the baselines come from?
From your own ECC system, not from a template. Pull real figures before conversion: cycle times for key processes, counts of open documents, and a sample of historical documents with the result each produced. A customer's numbers come from their own system. In our reference estate, a live ECC system, the same evidence-first approach is used to measure things like order-to-cash behavior, but those figures describe that estate and would not transfer to yours.
Baselines also surface what you did not know to test. Custom logic that quietly sets a credit block or an output type shows up in the data long before it shows up in a workshop, which is why usage evidence and the process map belong in the specification.
What is holdout validation and why use it?
Holdout validation means reserving a portion of the test cases, and their expected results, from the people configuring and converting the system. If everyone can see every test, the team tunes to the tests, and a passing run proves less than it appears to.
The same logic applies when automation is involved. If an agent proposes configuration or code changes, it should not be able to see the held-back cases it is later judged against. Our functional-testing agent is in build and in design preview, not shipped, so today holdout sets are assembled and run through the customer's existing test tooling and people.
Who signs off, and what happens on a miss?
Each criterion needs a named owner and a tolerance agreed up front. A finance lead accepts reconciliation; a supply chain lead accepts fulfilment flows. When a case misses, the decision is explicit: fix and re-run, accept a documented deviation, or defer the item with a workaround.
Any configuration change made to close a gap should follow the customer's change process. In our approach, configuration is drafted as a governed customizing transport; the customer's change board decides whether it lands, in development systems only, and it never touches production on its own.
Frequently asked
How many acceptance criteria does a migration need?
There is no standard number. Cover each critical end-to-end process, each financial reconciliation, and each high-risk interface, and give each one an owner and a tolerance. A short list that people actually sign is more useful than a long list nobody reads.
Can we reuse our existing ECC regression tests as acceptance criteria?
Often as a starting point, but check them. Existing scripts may test screens that no longer exist in S/4HANA, or miss the processes that changed. Pair them with baselines pulled from real ECC data so the criteria reflect what the business actually runs.
Does SAP's agent-led tooling replace the need for acceptance criteria?
No. SAP has said at Sapphire 2026 that its agent-led transformation can reduce migration effort by more than 35%; that is SAP's claim (SAP News, Sapphire 2026). Faster conversion makes clear criteria more important, because you need an independent way to judge what the automation produced.
See your own Clean Core Score.
Run the free S/4 readiness scan in under a minute — no system access required.
Keep reading