Shedding dead weight: finding unused custom code before your migration
Grown SAP systems carry hundreds, often thousands of custom developments — Z-programs, Z-transactions, enhancements. Little of it is documented, and over the years nobody keeps track of what is actually still needed.
Ahead of an S/4 or cloud migration, that turns into a tangible cost problem. Every single custom development demands a decision: take it along, replace it, or drop it. And the most expensive answer is the silent one: what is never questioned gets migrated anyway — including adaptation effort, test load and permanent maintenance. For code that possibly nobody has executed in years.
Why case-by-case assessment doesn’t scale
The classic approach is a manual inventory: a consulting team works through the object list, interviews developers and business users, and assesses piece by piece. With several thousand Z-objects that quickly becomes a six-figure effort — and the result is a snapshot that starts aging with the next transport.
On top of that: interviewees remember what they know. The very developments this is about — the forgotten ones — are on nobody’s radar anymore.
Two questions instead of a thousand individual cases
The decision becomes sound once you reduce it to two questions, both answerable from data:
- What does the custom development do, in business terms? Not the technical name, but the purpose: does it belong to finance, logistics, reporting? An AI-driven analysis reads the code and groups objects by business topic — an unwieldy list becomes a structured map.
- Does anyone still use it? Usage data shows per organizational unit what is actually in use — and what hasn’t been called for months or years.
Only the combination makes the difference. An unused development with no org unit depending on it isn’t “probably dispensable” — it is provably dead, and therefore safe to retire.
The cheapest part of the migration
The two answers split the custom-code inventory into three clean categories:
- Stays: in use and without a standard equivalent — gets migrated and deliberately kept.
- Gets replaced: in use, but covered by standard or cloud functionality in the target picture — worth the switch.
- Gets retired: provably unused — not migrated, but dropped.
The third category is the easiest win of the whole project: no migration effort, no test load, no future maintenance. You just have to be able to prove it — memories can be argued with, usage data can’t.
That is exactly what Conjola delivers: the AI analyzes your custom developments from the extract, clusters them thematically and maps them to your business topics. FeatureInsights shows alongside what is actually used per company code — unused features and dead custom code become evidenced. Repeatable every year, instead of a one-off snapshot.