When SAP transformation projects talk about custom developments,

they often sound like the biggest risk factor:

too many, too complex, too opaque.

However, our benchmarks from more than 2,000 analyzed SAP systems show a different picture:

Only around 15% of custom developments are used productively on a daily basis.

More than half are no longer used at all.

So the real problem is not the number of custom developments —

but assessing them correctly.

Three perspectives create clarity

Only the combination of usage, technology, and risk provides a reliable picture of

which custom developments are truly business-critical.

Top-Down – the usage and value perspective

The question here is:

What actual contribution does a program still make in the business process today?

And even more important:

Is this contribution also relevant for the future target architecture?

This perspective clearly distinguishes between:

• business logic that is truly needed

• and technical baggage that only still exists in the system

Bottom-Up – the technical perspective

The second perspective looks at the technical function of each custom development.

It analyzes:

• What business task does the program actually fulfill?

• Are there already SAP standard functions for this today?

• Can the logic be replaced by Fiori apps or simplification items?

The result is a concrete mapping with traceable confidence levels per recommendation.

Security – the risk perspective

The third perspective is often underestimated — but is often the most critical.

It addresses questions such as:

• Which programs write to business-critical data?

• Where are authorization checks bypassed?

• Which custom developments open up potential manipulation or fraud risks?

This perspective often determines

whether a program should even still exist in the production system.

In addition, it creates reliable facts for requirements such as:

• ISA 315

• LkSG

• governance and audit requirements

The real goal

In the end, a very clear picture emerges:

A large share of the custom developments still in use can already be covered by SAP standard today.

What remains is the truly business-critical logic —

and that is exactly what should be preserved.

Regardless of whether the target architecture is later called Public Cloud, Private Cloud, or Hybrid.

Avoid two costly mistakes

With this transparency, two typical reactions can be avoided:

❌ Carrying custom developments over to S/4HANA wholesale

❌ Re-standardizing areas at great effort that no longer deliver real added value

Instead, a fact-based basis for decision-making is created.

Minimal effort on the customer side

The effort remains deliberately low:

• a one-time data export

• no intervention in the production system

• results within a short time

👉 Feel free to send me a short message.

In a 15-minute conversation, we'll clarify whether this approach is the right next step for your situation.