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 is built for: the AI analyzes your custom developments from the extract, describes what each object does, clusters them thematically and maps them to your business topics. Alongside sits transaction usage from ST03N per system and company code, and FeatureInsights shows what is actually used per company code — so it becomes evident which Z transactions and features nobody calls any more. The decision per object is yours, and whatever gets retired you record as a decommission note. Repeatable every year, instead of a one-off snapshot.