SAP S/4HANA readiness assessment: a practical, evidence-based guide

Most S/4HANA programmes start with a readiness assessment, and most readiness assessments start with a room full of people and a spreadsheet. That gets you a plan built on memory and opinion. The alternative is to read the running system and let the evidence tell you what is actually there. This guide covers what a real readiness assessment should check, why the spreadsheet version falls short, and how to run one from live evidence.

What is an S/4HANA readiness assessment?

An S/4HANA readiness assessment is a structured evaluation of whether your current SAP estate is ready to move to S/4HANA, and what has to change before it can. It inventories your custom code and its disposition, checks how far your processes fit S/4HANA standard, and surfaces the SAP simplification items that touch your data and configuration.

Done well, it is not a one-off document. It is the factual baseline the whole programme scopes, estimates and sequences against. Get the baseline wrong and every downstream number, from effort to timeline to cost, inherits the error.

What should it actually check?

A readiness assessment worth the name looks at four things in depth, and it looks at them against the real system rather than against what people remember building. The four cover the custom estate, the processes, the documentation gap, and the target-design constraints.

• Custom-code inventory and disposition. Every custom object, with a decision attached: retire, replace, refactor or retain. That means knowing what exists, what is actually used, what a standard capability now covers, and what genuinely needs to move. A count of objects is not a disposition. See our deeper guide to SAP custom code assessment for S/4HANA.
• Fit-to-Standard. Where your processes already match S/4HANA standard, where they diverge, and whether each divergence is a genuine requirement or an accumulated habit. This is the heart of a Clean Core target. More in SAP Fit-to-Standard analysis.
• Reverse documentation. For custom objects worth keeping, a clear account of what they actually do, so functional and technical teams share one view before anyone decides its fate. See reverse-engineering an ABAP object into a functional spec.
• Clean Core scoring and simplification items. How far the target design keeps the core clean, using released extension patterns like RAP and CDS rather than modifications, and which SAP simplification items affect your specific data and configuration. Where custom logic reaches into tables directly, the fix is usually a released SAP API instead of a direct table access.

Why do spreadsheet-based assessments fall short?

A spreadsheet-based assessment captures a snapshot of opinions and counts at a single moment, and it starts going stale the instant the system changes. It usually cannot tell you which custom objects are still used, how they depend on each other, or whether standard S/4HANA now covers what a custom report was built to do years ago.

The result is a familiar pattern. Objects nobody touches get carried forward and re-tested at cost. Genuinely critical logic gets missed because the person who wrote it left. Effort estimates swing wide because they rest on recollection rather than measurement. The assessment reads well and holds up until the build team opens the system and finds a different reality.

SAP Readiness Check and ATC give you real, tool-generated signals here, and they are worth running. The gap is that their output still has to be turned into an object-by-object plan, and that step is where a spreadsheet quietly reintroduces opinion. An evidence-based assessment closes that gap by reading the live system directly.

How does C16 assess readiness from live evidence?

C16 analyses the live SAP estate read-only and builds the assessment from what the system actually contains, not from workshops alone. It scores Fit-to-Standard, classifies every custom object as retire, replace, refactor or retain, documents what the objects worth keeping actually do, and drafts candidate remediation for a human expert to approve. The evidence traces back to the system, so the findings can be checked rather than argued.

Two principles do not bend. C16 is read-only by default, so it analyses without changing anything, and any change it drafts ships only through your own change process. When remediation is agreed, changes are built in a development system, approved by an expert, and promoted through the customer's own change process. C16 drafts the candidate; a person approves every change.

This is meant to complement the tools you already trust. SAP Readiness Check, ATC and SAP Cloud ALM stay in the picture. C16 adds the deeper, object-level disposition and the remediation drafting that turn their signals into a plan, and it keeps everything grounded in current evidence rather than a point-in-time export.

• Read-only analysis. The estate is read as it runs today, across the landscape, without touching production data.
• Scored, not guessed. Fit-to-Standard and Clean Core are scored against the system, so the numbers have a source.
• Every object classified. Retire, replace, refactor or retain, with the reasoning attached to each decision.
• Expert-in-the-loop. Remediation is drafted as a candidate for a human to review and approve, never applied on its own.

Readiness work happens before go-live. Once you are live, the same read-only, evidence-first approach carries into support and continuous improvement, which is the subject of our companion guide on reducing SAP AMS ticket volume. Readiness before go-live, AMS after.

Where should you start?

Start with the estate you can measure, not the one you remember. Point the assessment at a real system, a sandbox or a copy of production, and let it produce the custom-code inventory and the Fit-to-Standard picture first. Those two outputs settle most of the early scoping arguments because they replace opinion with evidence.

From there the disposition list drives the plan: retire what is unused, replace what standard now covers, refactor what must stay but needs cleaning up, and retain the rest with documentation attached. That sequence is what turns a readiness assessment from a slide into a programme you can estimate and defend.

See a readiness assessment built from your real system. C16 reads your SAP estate read-only and shows you the custom-code disposition and Fit-to-Standard picture, on ECC or S/4HANA. Book a walkthrough.

C16 is PEOL Technologies' own product and is not an SAP product; PEOL is an SAP Partner. C16 reads SAP through standard interfaces and the permissions you grant, read-only everywhere and never writing to production. It queries the system on demand and does not retain your business data or use it to train models. Any change is built in a development system, approved by an expert, and promoted through your own change process. PEOL is ISO 27001 certified and SOC 2 Type II compliant.