What is SAP Readiness Check for S/4HANA, and what does it actually tell you?

What the Readiness Check actually produces

The mechanics are straightforward and the tool is free. You implement the current collection Notes in the ECC system, run the analysis reports, and upload the archive to SAP for Me, where SAP renders it as a dashboard you can share with the project team. Nothing leaves the system except the collected result set, and the analysis itself is read-only.

The dashboard is organized as a set of findings rather than a single verdict. The sections most projects use are these:

• Simplification items — the specific S/4HANA changes that apply to your system, with the mandatory ones separated from the informational ones.
• Custom code analysis — your ABAP objects checked against the S/4HANA readiness rules, showing which are affected by a simplification and roughly how much remediation that implies.
• Add-on and business-function compatibility — the things that will hard-stop a conversion until they are resolved.
• Sizing and data volume — what the target HANA system needs, and where archiving would reduce it.
• Integration and interfaces, financial data quality, and recommended Fiori apps — the operational tail that surprises projects late if it is not surfaced early.

The question it answers is technical, not strategic

Readiness Check is a conversion-blocker inventory. That is a genuinely valuable thing to have, and a project that starts without one is planning in the dark. The trap is treating the custom-code section as a scope decision rather than a compatibility finding.

An analogy: it is a home inspection before a renovation. The inspector tells you the wiring in the west wall is not to code and the load-bearing beam has rot. That is essential. What the inspector does not tell you is whether you actually want a west wall — whether that room still gets used, whether the addition it was built for was demolished a decade ago, or whether the kitchen you are about to rewire would be better relocated. Those are design decisions, and they are the ones that move the budget.

In SAP terms: the check will tell you that an object is affected by a simplification. It will not tell you that the object encodes a credit-check rule that SAP Credit Management in FSCM now handles as standard configuration, and that the correct answer is to retire it rather than remediate it.

Three blind spots worth planning around

None of these are defects — they are outside what the tool set out to do. But each one changes conversion scope, so somebody has to cover them.

• Usage. Custom-code findings are far more useful when real execution data is attached, which requires the ABAP Call Monitor or usage logging to have been running long enough to cover annual processes. Many estates have not turned it on, so the object list arrives without any signal about what is actually dead.
• Intent. The check works at the object level, not the rule level. Knowing that an enhancement exists is not knowing what business decision it makes — and the retire-or-rebuild call depends entirely on the latter.
• Standard coverage. Nothing in the output compares the rule inside your code with what S/4HANA now delivers natively. That comparison is where the largest scope reductions come from.

What to add on top of it

The complement to a Readiness Check is evidence about behavior: read the source of each surviving custom object and summarize the business rule it encodes, pull where-used and execution evidence to separate live objects from dead weight, and compare each rule against current standard capability before anyone estimates remediation. All of that is read-only against the live system.

On a reference estate — a live ECC system we analyze end to end; a customer's numbers come from their own system — that layer of evidence found 44% of custom objects were re-implementations of capability S/4HANA now delivers as standard. A Readiness Check would have correctly listed most of those objects as affected and remediable. The evidence layer is what turns "remediate" into "retire," and retirement is the only line item in a conversion plan that removes work instead of scheduling it.

Sequence matters more than tooling. Run the Readiness Check early, because the hard blockers should be known before anyone picks a conversion approach. Then do the evidence work before the scope is frozen — after the backlog is approved, every finding is a change request.

Where this fits in a business case

Readiness Check findings quantify cost: sizing, remediation effort, blocked add-ons. They do not quantify benefit, because that is not their job. A steering committee looking only at that output sees a bill with no offsetting column, which is one reason ECC conversions get deferred.

The offsetting column comes from retirement counts, avoided rebuild effort, and measured process cycle times — arithmetic over specific, auditable reads. SAP itself is pushing the same direction with the agent-led transformation capabilities announced at Sapphire 2026, where SAP reports more than a 35% reduction in migration effort from AI-assisted tooling (per SAP News). The Readiness Check remains the honest starting inventory. What you build on top of it decides whether you migrate the estate you have or the one you want.