Retire what's unused. Remediate only what remains.
Custom code is the largest and least predictable cost in an ECC-to-S/4HANA conversion. CodePrune finds what your business has genuinely stopped running, removes it through a monitored and reversible grace period, and turns SAP's readiness findings into a per-owner backlog — so the conversion budget is spent only on code that still earns its place.
The conversion is tooled. The custom code is the variable.
Mainstream ECC maintenance ends in 2027 (extended to 2030). Every customer must convert. The technical conversion is well-understood — the unpredictable cost sits in the thousands of custom objects nobody fully remembers building.
Custom code is the wild card
The technical conversion is well-tooled and understood. Custom code is the largest and least predictable cost — a 15–20-year-old system carries thousands of objects nobody fully understands.
The instinct is the expensive mistake
Run readiness checks, get a huge list, start fixing. That is the wrong order. A large share of custom code in a long-lived system is simply never executed any more.
Remediating dead code is pure waste
It spends the scarcest resource on the project — experienced developer time — on retired processes, superseded interfaces and abandoned projects that produce no business value.
Deleting felt riskier than leaving
So it accumulated. Every unused object still gets upgraded, tested, patched and explained to each new developer — a cost that recurs every single year.
Two independent programmes, one combined dashboard.
Usage analysis & controlled decommissioning
Builds a complete inventory of custom objects, joins it with real production execution data, and classifies every object as used, not used, or no data available. Anything that appears unused passes eight automated safety checks before it can even be proposed for removal.
S/4HANA readiness analysis
SAP's ABAP Test Cockpit holds the authoritative readiness checks — so the framework deliberately doesn't duplicate them. It takes their output and converts it into what ATC does not provide: management information.
Removal is never a single irreversible action.
The grace period is the heart of the design: it converts an irreversible guess into a monitored experiment. If a program really is still needed, it announces itself by running — before anything is lost. That is what makes decommissioning defensible to a risk committee, not merely efficient.
Mark obsolete
The object is flagged and its owner notified. It continues to work exactly as before — nothing changes in behaviour. This is a signal, not a removal.
ATC tells you what's wrong. CodePrune tells you what to do about it.
By package — the planning view
Findings, severity mix and estimated effort per business area, so work is assigned to named owners and sequenced sensibly.
By check — the efficiency view
The most frequently repeated problems — usually fixable as a single pattern applied many times. This is where the largest effort savings hide.
Net of retirement — the business case
The effort that disappears entirely because the affected code is being deleted rather than fixed. The number that justifies the programme.
Usage history cannot be obtained retrospectively.
Execution data exists only if something was recording it at the time. Activating SAP's execution monitoring is a low-effort, low-impact configuration step — and the single highest-value action at the start of a conversion. The window must span at least one full annual cycle, because year-end close, asset depreciation and inventory revaluation run only once a year.
How the framework stays honest: objects not covered by monitoring are reported as “no data” — never as “unused” — and are never proposed for deletion. If coverage is poor, CodePrune says so prominently rather than producing a confident-looking but unreliable number.
Spend the conversion budget only where it earns its place.
Avoided remediation
Developer effort is spent only on code the business actually uses. The effort avoided is measured and reported — not assumed.
A smaller system to convert
Less code means a faster conversion, less regression testing, and a shorter go-live weekend.
Lower ongoing cost
Retired code is never again upgraded, tested, patched or explained to a new developer. The saving recurs every year.
Predictability
The conversion becomes a measured backlog with an owner per package — not an open-ended risk.
Defensible decisions
Every deletion has a named owner, a recorded confirmation, a grace period and an archived copy. The full history is reconstructable for audit.
Reduced attack surface
Unused custom code is unmonitored, unpatched and rarely reviewed. Removing it is a security improvement as well as a cost one.
A measured twelve-month path, monitoring from week one.
If usable historical usage data already exists, retire and remediate invert — retirement comes first, which is always the cheaper order. The sequence above assumes the more common starting point of no prior monitoring.
Four decisions — one of them this month.
Decide to monitor — this month
Activate execution monitoring in production. This is the only genuinely time-critical item; every week of delay is a week of evidence that cannot be recovered.
Named owners per package
The framework identifies unused code, but only the business can confirm a process is genuinely retired.
A deletion-authority rule
Recommended: two or three named individuals, with each deletion referencing a change request like any other production change.
An agreed exclusion list
Regulatory, statutory and disaster-recovery code that is never automatically decommissioned, regardless of measured usage.
Find out what your organisation has genuinely stopped using.
A small, fixed effort now — so the S/4HANA budget is spent only on code that still matters. The clock on usage history is already running.