How do you scope regression testing for an ECC to S/4HANA migration?

Why test scope is the overrun that lands last

Regression testing is the last major cost line in an S/4HANA program and the one with the least slack behind it. That is a structural problem, not a discipline problem. The test plan is sized against the number of custom paths that must be proven, so if the customization count in the estimate is optimistic, the test plan is undersized by construction — and nobody finds out until the code has been converted and the team starts writing scripts.

By then the levers are poor. You can add testers, which raises cost and coordination overhead late in the program. You can automate, which has real value but takes build time you no longer have. Or you can reduce coverage, which is the decision most programs quietly make and the one that produces the post-go-live stabilization period everyone remembers.

The fix is upstream. If the customization count is evidenced before the plan is built, the test scope stops being a discovery and becomes arithmetic.

Scope from what executes, not from what exists

A repository scan tells you how many custom objects exist. That is the wrong denominator. Twenty-year-old ECC estates carry dead reports, superseded interfaces, and copies of copies that no longer run. Testing all of them is waste; testing none of them is risk. The distinction between the two has to come from evidence in the system.

Four inputs, all readable from a live ECC system, are enough to build a defensible scope:

• The custom object inventory with execution evidence — which programs, exits, enhancements, and interfaces still fire, and which have not been called in years. Where-used and usage evidence separates the live estate from the archaeology.
• The business rule each surviving object encodes. A user exit is not a test case until you know what it does; once you know, you can tell whether the behaviour is business-critical, cosmetic, or already standard in S/4HANA.
• The process variants that carry document volume. Order-to-cash cycle times and volumes derived from real sales and billing document flows — 8,360 orders on the reference estate — show which paths are the business and which are edge cases that deserve a single confirmation test rather than a suite.
• The interface inventory with its counterparties. Integration regression is routinely underestimated because the SAP side is visible and the partner-system side is somebody else's calendar.

Retirement is the largest single test-scope lever

The cheapest regression test is the one you deleted. Every custom object retired before the conversion removes its scripts, its data setup, its defect triage, and its share of the integration matrix. This is why fit-to-standard analysis pays back twice: once in clean-core terms and once, larger, in test effort.

The pattern that produces most of the retirement candidates is consistent. A custom exit was written years ago because ECC standard could not do something; S/4HANA now can. The classic example is a sales-order credit check hard-coded into MV45AFZZ, where the underlying business rule is a credit policy that S/4HANA delivers through FSCM credit management as configuration. Read the rule out of the code, match it to the standard capability, and the object becomes a configuration decision instead of a test case.

The discipline that matters here is honesty about the disposition. Retire, re-implement in standard, or carry forward — each object gets one, with the reasoning attached, and the test plan is generated from the carry-forward and re-implement columns.

The standard paths S/4HANA changes anyway

Custom code is only half the scope. S/4HANA changes several standard behaviours whether or not you customized them, and those changes need coverage even in an estate with no custom code at all. These are predictable, which means they can be planned rather than discovered.

• Business partner conversion — customer and vendor master become the business partner model, which touches every process that resolves a partner, including pricing, output, and credit.
• Credit management moves from the classic SD credit check to FSCM, changing where limits, blocks, and release behaviour live.
• Material valuation and the material ledger become mandatory, which affects costing, inventory valuation, and period-end results.
• Output management shifts toward the BRF+ based framework, so determination logic and forms need re-proving even when the document content is unchanged.
• Reporting built on ECC table structures needs re-pointing, because the underlying tables and the CDS view layer are not the same shape.

Where AI agents fit — and where they do not yet

Agents are already useful at the front of this problem. Reading a live system, inventorying custom objects, recovering the business rule from source, checking usage, and mapping objects onto process stages is analytical work with verifiable output, and it is exactly the work that turns an assumed test scope into an evidenced one. That part is available today and is how the reference-estate numbers above were produced.

Execution is a different maturity. Our functional-testing agent — which would take the evidenced scope and drive the test cases — is in build and design preview, not shipped, and we say so rather than implying otherwise. SAP is pointing the same direction: at Sapphire 2026 SAP described agent-led transformation with a claimed reduction of more than 35% in migration effort (SAP News, Sapphire 2026), which is SAP's figure and worth watching rather than banking.

The practical stance for a CIO planning a 2027-constrained program is to use agents now for the discovery that sizes the test plan, keep humans on the judgment calls about coverage and risk, and re-evaluate agent-driven execution as the tooling actually ships.