How to Read an SAP Readiness Check Report

Decision context

The SAP Readiness Check is a good instrument and a poor plan. It tells you what your system contains as of the moment the data was collected, and it is routinely read as though it told you what the conversion will cost.

Three of its results change a plan and the rest inform it. An incompatible add-on is a hard dependency on somebody else's delivery date. An incompatible active business function can be irreversible. And a simplification item marked relevant with a failing consistency check is data work that has to happen before the conversion, not during it.

Everything else, including the sizing figure and the custom code count, is a function of what your system looked like on the collection date. Archive data or retire unused custom code and the same check returns different numbers, which is exactly why it should be re-run rather than quoted.

How the result is produced, and why that matters

The analysis data is collected in the source system by a collection report delivered through SAP Notes and the service tools, packaged, and uploaded to SAP's Readiness Check application, which renders the dashboard.

The available sections depend on the version of the check, your source release, and which service tool content is installed, so a section described elsewhere may simply not appear in yours. Confirm the current collection procedure and note in SAP's own documentation before running it, because the notes are updated regularly.

• The result is a snapshot of the collection date. It ages, and it ages fastest in the areas you are actively working on.
• Several sections depend on usage data collected over a period. A short collection window under-reports both custom code usage and integration.
• The check runs against the source system, so it reflects what production actually contains rather than what the documentation says it contains, which is usually its most valuable property.
• Re-run it after archiving, after custom code retirement, and before any budget commitment, because those are exactly the actions that move its numbers.

The three results that change the plan

Read these first. They are the ones that alter sequence, scope, or feasibility rather than effort.

• Add-on compatibility. An add-on with no compatible version for your target release is a hard stop until the vendor ships one, and vendor timelines are not negotiable from inside your program. Get this answer in week one, not in month four.
• Active business functions. Some business functions cannot be carried into the target, and activation decisions are frequently irreversible. This is a feasibility question, not an effort question.
• Simplification items marked relevant, with their consistency checks. The item list tells you what applies. The consistency checks tell you what data has to be corrected before the conversion will run. That data work is often the longest lead time in the whole program and it does not compress.

The sections that are estimates, and what moves them

These are useful for direction and misleading when quoted as facts. Each one has a specific lever that changes it.

• Sizing. Derived from your current data volume. Archiving and data volume management change it materially, which is why the data volume section should be read together with the sizing section rather than separately.
• Custom code analysis. Counts findings against your custom objects. Without usage data, everything looks used, and remediating custom code that has not executed in a year is the most expensive way to discover it was dead. Collect usage before you scope remediation.
• Integration. Based on connections observed during the collection window. Interfaces that run monthly or quarterly can be entirely absent from a short window, and those are frequently the ones nobody remembers.
• Recommended Fiori apps. A catalogue suggestion based on what you use today. It is an input to a user experience conversation, not a work package.
• Financial data quality checks. Genuinely useful and frequently deferred, because the corrections belong to finance rather than to the technical team. Start them early for that reason, not despite it.

Turning the report into a plan

The report gives you an inventory. The plan needs sequence, ownership, and the things the report cannot see.

• Assign an owner to each relevant simplification item, not to the item list as a whole.
• Separate the data corrections from the technical work, because they have different owners, different lead times, and different sign-off.
• Collect custom code usage data before scoping remediation, so retirement is on the table alongside remediation.
• Build the interface inventory from the report plus the interfaces the team knows about, since the observed set is a floor rather than a total.
• Re-run the check after the first round of archiving and retirement, and use the second result for the business case.
• Record what the report does not cover: business process change, organisational readiness, testing scope, data quality beyond the delivered checks, and the third-party landscape.

What the workflow must cover

• Findings with dependency paths. Connect readiness and ATC findings to the objects, data, interfaces, and processes around them, so a finding becomes a scope rather than a row.
• Usage-aware remediation scope. Combine findings with execution evidence so unused custom code is retired rather than remediated.
• Coverage boundaries. Keep unsupported inputs and unobserved dependencies visible rather than presenting an incomplete inventory as complete.
• Re-runnable comparison. Compare successive analyses so the effect of archiving and retirement on scope is measured rather than asserted.

Implementation workflow

Start with a bounded customer scenario and explicit acceptance criteria. Preserve native SAP permissions and accountable review while the software creates a repeatable evidence chain.

1. Confirm the current collection procedure and run the collection in the source system.
2. Read add-ons, business functions, and relevant simplification items first.
3. Collect custom code usage data before scoping remediation.
4. Start the data corrections and financial data quality work immediately, since they have the longest lead time.
5. Archive, retire, then re-run the check and use the second result for planning.

Evidence to require

A transformation claim should resolve to observable artifacts, decisions, and execution receipts. Ask for the following evidence in a representative evaluation:

• Collection date and window
• Add-on compatibility result
• Active business function findings
• Relevant simplification items and consistency check results
• Sizing figure and the data volume behind it
• Custom code findings with usage evidence
• Observed integration inventory
• Second run after archiving and retirement

Boundaries and non-claims

Adranum separates analysis, proposal, human review, package creation, customer-local validation, and production execution. A later state never rewrites the evidence that supported an earlier decision.

• The result is a snapshot. It ages, and quoting a number from an old run into a business case is a common and expensive mistake.
• Sections and their contents depend on the check version, the source release, and installed service tool content.
• The check does not cover business process change, organisational readiness, test scope, or the third-party landscape. Those are the parts of a conversion that overrun.

Buyer checklist

• What was the collection date and how long was the usage window?
• Is any add-on incompatible with the target release?
• Which simplification items are relevant, and which consistency checks fail?
• Was custom code usage data available when the findings were produced?
• Has the check been re-run after archiving and retirement?