An S/4HANA upgrade is a business‑process test, not just a technical upgrade

The question

Conversion programmes are usually governed as technical programmes. There is a sandbox conversion, a development conversion, a set of simplification checks, a custom-code remediation backlog, a data migration or transition, a series of rehearsals, and a cutover plan. All of it is necessary, and most of it is well understood by the teams doing it.

What that governance measures is whether the system converts. It is much less good at answering a second question, which is the one the business asks on the Monday after: do the things we do every day still produce the same outcome?

What we see in programmes

Post-conversion issues tend to fall into three groups, and only one of them is loud.

The loud group is the one everybody plans for: something errors. A program dumps, a job fails, an interface rejects. These are unpleasant but they are visible, they get raised within hours, and they get fixed.

The second group is quieter. Something behaves differently but plausibly. An approval routes to a different person. An output goes to a different channel. A tolerance behaves differently at a boundary. Nobody raises a ticket for several days because everyone assumes it is correct and that they have misremembered the old behaviour.

The third group is the one that does real damage. Nothing fails at all. A custom report runs cleanly, completes, and returns a number that no longer agrees with the system of record, because the tables it was written against are not where the truth lives any more. There is no error to detect. There is no alert to raise. It surfaces when somebody reconciles by hand, which might be at the first month-end, or the first quarter-end, or in an audit.

A technical conversion test plan is well designed for the first group. It is not designed for the third.

A better way to think about it

The useful reframe is that a conversion changes several distinct things underneath the business, and each one needs a different kind of test.

Custom code. Not whether it compiles — whether it still means the same thing. Code written against structures that have been simplified may still execute perfectly while answering a subtly different question.

Business data. Master data that has been converted, merged or extended. The conversion of the records is usually tested. What is often not re-tested is the downstream process behaviour that depends on those records having particular shapes.

Interfaces. Field lengths, message structures, partner expectations. A trading partner discovering your conversion before you do is a bad way to find out.

Process behaviour. The end-to-end path, including its variants and its exception routes. Not the transaction — the process the transaction sits inside.

Authorisations and workflow. Roles that were derived from the old landscape, and approval paths that have been re-implemented rather than migrated. These frequently work for the tester, who has generous access, and fail for the business user, who does not.

Reports and outputs. Anything the business or a regulator reads. This is where the silent class of defect concentrates.

The dangerous defects after a conversion are not the ones that fail. They are the ones that succeed and are wrong.

What good looks like

Three habits distinguish conversion programmes that come through cleanly.

Scope derived from what production actually runs. Execution statistics for custom programs and transactions are usually available and rarely used. Code that no longer runs anywhere needs no test. Code that runs at month end and is in nobody’s test scope is the exposure. Deriving scope this way tends to be both wider and cheaper than deriving it from design documentation, because it removes as much as it adds.

Reconciliation treated as a first-class test. For every custom financial or operational report in scope, a comparison of the answer before and after, on the same data. This is the only reliable defence against the silent class of defect, and it is unglamorous work that gets cut when the plan tightens.

Downstream processes re-tested after data conversion, not just the conversion itself. A business partner conversion signed off on record counts is not the same as a procure-to-pay cycle proved end to end on the converted records.

Questions leadership should ask

Which custom objects still run in production, and how many of them have a test? The gap between those two lists is the honest scope conversation.

For our critical reports, are we comparing the answer before and after — or only checking that they run?

After the data conversion, which end-to-end processes were re-run, and on the converted data?

Have we tested with a business user’s authorisations, or with a tester’s?

Which interface partners have replayed real message volume, rather than sample messages?

There is time to do this properly. SAP has stated mainstream maintenance for Business Suite 7 core applications until the end of 2027, with optional extended maintenance until the end of 2030, alongside an innovation commitment for SAP S/4HANA to the end of 2040. That is a planning horizon, not an emergency — and programmes that treat it as a planning horizon test better than programmes that treat it as a deadline.