SAP Readiness Check tells you what will break. It cannot tell you what deserves to survive.
Every conversion program starts with the same artifact: a report counting custom objects, simplification-item conflicts and adjustment findings. The number is usually in the thousands, the first reaction is usually alarm, and the first instinct — remediate everything the report flags — is usually the most expensive mistake available.
The report is an inventory. The plan is a triage. Confusing the two prices the past into the future.
Most custom code is dead, and usage data proves it. Remediate what earns its place; retire the rest without ceremony.
What the tooling genuinely gives you
Three things, and they are valuable: an inventory of custom objects, a mapping of where they collide with S/4HANA’s simplifications, and — when usage logging has been running long enough — evidence of what is actually executed in production. Together they turn “we have a lot of custom code” from folklore into data.
SAP’s toolset here — Readiness Check plus the custom-code migration checks in ABAP Test Cockpit — identifies conflicts and adjustment effort. Usage statistics need months of collection to be trustworthy; switching them on is one of the cheapest early moves a program can make.
What it cannot tell you
Whether anyone still runs the object
A conflict finding on a report nobody has executed since 2019 is not a work item — it is a deletion candidate wearing a work item’s clothes. Without usage data, the report treats the dead and the living identically.
Whether the requirement behind it still exists
Custom objects outlive the process changes, reorganizations and regulations that justified them. The question “what business capability does this serve today?” is not in any log — it belongs to the process owners, and asking it retires more code than any syntax fix.
What the survivors should become
“Adjust the code” is only one of four verdicts. The report cannot see that a surviving requirement is now covered by standard, or that it is differentiating enough to deserve a proper rebuild as a clean extension. Those are design decisions, not findings.
The four verdicts
Measure usage→Retire the dead→Interrogate the survivors→Route per clean core
Why the triage changes the program
The arithmetic is dramatic and typical: of the headline count, a large share is never executed, another share duplicates what standard now does, and the genuinely differentiating remainder — the code worth engineering properly — is a fraction of the original number. The remediation estimate built on the raw count and the one built on the triaged count are different projects.
The triage also produces something the raw report never can: a defensible story for the audit and the steering committee about why each object lived or died — capability by capability, not line by line.
VISCAP perspective
The unit of remediation is a business capability, not an object. Code is only ever evidence of a requirement — interrogate the requirement.
We treat the Readiness Check as the opening of a conversation with process owners, not as a backlog. The report says where the past is incompatible with the future; only the business can say which parts of the past were worth keeping. Programs that skip that conversation pay engineers to preserve habits.
The number that matters
Not the finding count on page one — but the share of your custom estate with zero executions in the last year. Ask for that number first. It reframes every conversation that follows, usually within a single meeting.