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.

What does SAP Readiness Check not tell you?

SAP Readiness Check is the right place to start, and every S/4HANA programme should run it. It tells you which simplification items apply to your system, how many custom-code findings you carry, which add-ons are compatible, what the target sizing looks like and which Fiori apps are recommended. What it does not tell you is what to do about any of it at the level of an individual object or process.

• What each custom object does for the business. A finding count says how much custom code needs attention. It does not say which programs carry real business logic and which are forgotten copies of a standard report.
• Whether standard now covers it. Many custom objects were built because ECC lacked something S/4HANA now has. Spotting that overlap needs a Fit-to-Standard view of the process, not a syntax scan of the code.
• The disposition decision. Retire, replace, refactor or retain is a judgement per object, with usage, dependencies and business purpose behind it. The check gives you the list; the assessment gives you the decision.
• How your processes fit S/4HANA standard. Readiness Check works on the technical estate. Whether your order-to-cash or procure-to-pay variants match standard, and which divergences are genuine requirements, is a process question it does not ask.
• The effort. Programme estimates depend on the disposition list, not on the finding count. Two systems with the same number of findings can differ by a factor of three in remediation effort.

This is why the readiness check is an input to the readiness assessment, or pre-assessment, and not a substitute for it. The check tells you the system is not ready in these places. The assessment tells you what to do about each one, in what order, and what it will cost.

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.

Also published on SAP Community, with the full first-person case: What SAP Readiness Check told us, and what it did not: one ECC to S/4HANA assessment.

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.

See also: S/4HANA Migration with AI for the full use-case view across custom code, Clean Core, simplification mapping, and process discovery.