What should testing protect during an ECC‑to‑S/4HANA conversion?

The question

“What is our conversion test strategy?” usually produces a document describing phases, environments, entry and exit criteria and a RACI. All of that is necessary. None of it answers the question that matters, which is which parts of the business the programme intends to prove still work, and in what order.

A conversion is not one change. It is six changes arriving simultaneously underneath a running enterprise, and a strategy is a set of priorities across those six.

What we see in programmes

Test strategies for conversions tend to be organised by testing phase — unit, string, integration, UAT — because that is how test strategies have always been organised. The trouble is that phases describe when testing happens and who does it. They do not describe what is being protected.

The consequence shows up at the end. Ask a programme in its final month which business capabilities it can now vouch for and the answer often has to be assembled, because nothing was tracked in that shape. Ask which phases are complete and the answer is immediate. The reporting matches the plan, and the plan was built around activity.

A better way to think about it

Six things change. Naming them separately makes the priority conversation possible.

Custom code. Remediation makes it compile and run. That is not the same as it still meaning what it meant. Code written against structures that have been simplified can execute cleanly while answering a slightly different question — and no test that only checks for errors will catch it.

Business data. Records that have been converted, merged, extended or re-keyed. Record counts and reconciliation reports usually cover the conversion itself. What is less often covered is whether the processes that consume those records still behave correctly on their new shape.

Business processes. The end-to-end paths, with their variants and exception routes. This is the layer the business experiences and the layer least well represented in a phase-based plan.

Integrations. Interfaces, middleware, EDI, third-party applications. Field lengths and message structures change; partners do not know that until something rejects.

Authorisations and workflow. Roles derived from the old landscape and approval paths re-implemented rather than migrated. These commonly work for the tester and fail for the business user, because the tester has broader access. It is a first-week-after-go-live class of defect.

Reports and outputs. Everything the business, the auditor and the regulator reads. This carries the silent defects.

Phases tell you when testing happens. They do not tell you what is being protected. Only the second one is a strategy.

What good looks like

Scope derived from production execution. Which custom programs and transactions actually run, and how often. This is available in most landscapes and used in few conversion programmes. It reliably removes work — code that no longer runs needs no test — as well as adding it. The month-end program nobody remembered is the classic find.

Reconciliation as a named workstream. For every custom financial or operational report in scope, the same input producing a comparable answer before and after. Not a check that it runs. A comparison of what it says.

End-to-end re-runs after data conversion. A business partner conversion signed off on counts is a different claim from a procure-to-pay cycle proved on the converted records.

Authorisation testing with realistic roles. Run a meaningful set of scenarios as the business user, not as a tester with wide access.

Interface replay against real volume. Sample messages exercise the shapes you thought of. Real traffic exercises the shapes you did not.

There is room to do this deliberately. SAP has stated mainstream maintenance for Business Suite 7 core applications to the end of 2027, with optional extended maintenance to the end of 2030. That is a planning window, and programmes that treat it as one make better scope decisions than programmes running against a perceived cliff.

Questions leadership should ask

Which of the six layers are we protecting first, and who decided the order?

Which custom objects run in production, and how many of those are in test scope?

Are we comparing report answers before and after, or only confirming they execute?

Have we run anything as a real business user’s role?

Which interface partners have replayed real message volume?