SAP Readiness Check for an SAP S/4HANA conversion usually ends the same way. The Basis team runs the data collectors, the analysis lands on SAP for Me, somebody exports the results document and forwards it with a single sentence: “we have the readiness assessment”. Then the steering committee asks about the date, the budget and what will stop working during the programme. The report answers none of those three questions, because that is not what it was built for.
This is not a complaint about the tool. SAP Readiness Check does exactly what it promises: it describes the technical state of the source system and flags the items you need to work through. The trouble starts when a technical report is presented as an assessment of whether the organisation is ready for the programme. Between those two things sit several months of work and a handful of decisions no tool will make for you.
The short version:
1/ SAP Readiness Check for SAP S/4HANA covers sixteen analyses, and the most important one is based primarily on table contents and used transactions - so the tool sees the trace your system left behind, not the way your company works,
2/ three kinds of finding will stop the conversion before it starts, and for one of them SAP tells you to raise an incident, because it cannot be solved on your side,
3/ four answers are missing entirely: authorisations, the licence cost of the target model, the real downtime in your landscape, and data quality outside finance,
4/ SAP itself points back to people in several places, describing some items as requiring an expert assessment - the most honest part of the whole document.
What SAP Readiness Check actually measures
The conversion scenario covers sixteen analyses. It helps to group them, because in the document they all sit side by side and all look equally important.
Compatibility, or what blocks the start: simplification items, compatibility scope analysis, active business functions, add-on compatibility. Effort, or the work ahead: activities related to simplification items, custom code analysis, integration, app availability and recommended SAP Fiori apps. Data: financial data quality, customer vendor integration with the Business Partner record, and target system sizing. The rest: the planned downtime calculator, business process discovery, SAP Business AI capabilities and SAP Innovative Business Solutions.
One line in SAP’s documentation matters more than the others and is easy to miss. For simplification items, the check is based primarily on table contents and used transactions. That means the tool recognises the module that left data behind and the transaction somebody ran. It will not recognise the process your team runs on a spreadsheet workaround, or the module you licensed and rolled out in one company code out of fifteen. The report shows you the system’s fingerprint, not a map of the business.
The second thing deserves credit: SAP does not pretend to quantify everything. The effort ranking for a simplification item runs from low to high or explicitly states that the item requires an expert assessment. The effort drivers compare your system against reference values gathered from previous SAP S/4HANA projects. That is a useful hint and a poor basis for a budget, because the reference is somebody else’s programme, not yours.
Before the report exists
If you do not have a report yet, the path is shorter than people assume and does not require buying a service. SAP Readiness Check is available in two places: on SAP for Me for every customer with an active maintenance agreement, at me.sap.com/readinesscheck, and in SAP Cloud ALM for those who have a tenant. A guided procedure prepares the system and runs the data collectors, and once the data is in you create a new analysis from the landing page.
Two things are worth settling straight away. First, run the analysis on the production system - its data describes the real scope of the programme, unlike a quality system where half the modules never worked at production volumes. Second, results from different scenarios run against the same system can be combined into one analysis, which matters wherever SAP BW/4HANA or SAP ERP usage profiling sits alongside the conversion.
A report older than a year deserves a rerun before the programme starts. The list of analyses grows with each release of the tool, and your system moves too - if somebody activated a business function or installed an add-on in the meantime, the old result describes a landscape that no longer exists.
Three findings that stop a conversion before it begins
The first is an incompatible add-on. SAP’s documentation says plainly that incompatible add-ons will block the conversion during the execution of Software Update Manager. The tool assigns add-ons to categories: compatible, incompatible, incompatible (uninstallable) and unknown. That last category is the interesting one, because the report does not close it - it mostly holds partner solutions, and the answer to whether the vendor will ship a release for your target SAP S/4HANA version has to come from you asking them. The earlier the better, because removing an add-on from the landscape tends to be a project of its own.
The second is an active business function that is incompatible with the target release. Here SAP is even more direct: such a function will block the system conversion, and the recommended path is to raise a support incident under the application component of that function. There is no workaround available to the project team, so an item from this list belongs on the steering committee agenda in week one, not during cutover preparation.
The third is a simplification item marked as requiring an expert assessment. This is not an error state, it is a signal that the tool has done what it can. It usually covers areas where the change in the data model meets your configuration: accounting, materials management, sales with heavy custom code. Each of those items is a separate conversation with the person who knows that area in your company.
The good news is that all three can be settled before the programme starts, without running a conversion. The bad news is that hardly anyone does it, because the report looks like a document to read rather than a document to work through.
Four answers this report does not contain
Authorisations, segregation of duties and technical accounts. The list of analyses is closed and public, and not a single item on it covers roles, authorisations, service accounts or system exposure. A conversion rebuilds the authorisation model, adds SAP Fiori apps with their own catalogues and groups, and along the way opens access for a year or more that nobody would grant in business as usual. The report says nothing about any of it. We covered that separately in Secure SAP S/4HANA conversion, because it is a subject for its own article rather than a paragraph.
The licence cost of the target model. Compatibility scope analysis describes compatibility packages, meaning limited usage rights for classic SAP ERP solutions running on SAP S/4HANA, and shows which of them have a successor. It does not tell you what you will pay after the conversion, or how your licence position changes once users move to the FUE model. That is a separate analysis, built on real usage data rather than on a collector’s output - see SAP licence audit.
The real downtime in your landscape. The planned downtime calculator is in the report, and it carries an assumption stated in the open: the runtimes shown apply to a standard conversion through Software Update Manager within a single data centre. Phase durations come from other customers’ experience and from measurements on comparable systems. If you replicate between sites, negotiated a maintenance window with the business, or run integrations that will not survive a dozen hours of silence, that number is the starting point for a plan, not the plan. There are two ways to shorten it: the downtime-optimized conversion option, and archiving and housekeeping done before the programme rather than during it.
Data quality outside finance. The report checks the general ledger, asset accounting and the material ledger, sorting inconsistencies into categories that run from automated correction, through manual correction and contact SAP, to a system-specific fix. It also checks that customers, vendors and contact persons are synchronised with the Business Partner record, because the conversion will not proceed without it. And that is where data ends. Duplicates in material master data, inconsistent numbering, three versions of the same trading partner across three company codes - none of that is counted here, and that is exactly the material that breaks user acceptance testing.
How to read the report in a week
Sequence matters, because the document is organised by topic and a programme needs it organised by decision.
Day one: blockers. Incompatible and unknown add-ons, active business functions, items flagged for expert assessment. This produces the list of questions that go outside the company - to partner vendors and to SAP. Answers take weeks, so this has to go first.
Days two and three: custom code. Custom code findings only mean something once you know which of that code is actually used. The scope information, meaning the split between in-scope and out-of-scope objects, appears only if you ran the SAP Fiori Custom Code Migration app. Without it you get findings with no weight, and the difference can be that half the objects have not been touched in years and belong in a deletion transport rather than in a rewrite. While you are there, check how many findings carry a quick fix, because that genuinely moves the estimate. We normally combine this step with a vulnerability review of custom code through SAP Code Vulnerability Analyzer, so that nobody walks the same code twice.
Day four: data. Financial inconsistencies by category, the state of the Business Partner conversion, and the archiving potential from the sizing tab. This is where you decide whether the clean-up happens before the conversion, or whether you agree to move the mess onto the new platform and pay for it in memory.
Day five: integration and downtime. The interface inventory - IDocs, RFCs and BAPIs, web services, OData, SAP BW extractors, file interfaces, SLT configurations - set against the list of systems whose owners sit outside IT. Then the downtime calculator, checked against the window the business will actually agree to.
With that material in hand the steering committee stops discussing a report and starts discussing scope, dates and money. The next step, how to structure the conversion programme itself, is covered in how to prepare for an SAP ERP to S/4HANA conversion, and the testing layer in our article on SAP testing during conversion and before go-live.
The date nobody is going to move
Mainstream maintenance for SAP Business Suite 7 ends on 31 December 2027, and extended maintenance runs to the end of 2030 at an additional two percentage points on the maintenance base. A company that holds an SAP Readiness Check report today and has not settled its blockers has a little over a year for decisions that depend on conversations with add-on vendors and with SAP. That is enough time, provided the report gets worked through now rather than once the programme has a budget and a go-live date.
How we work at SNOK
We run readiness assessments on your report, not instead of it. We start the collectors where they have not been started, walk item by item through blockers, custom code and data, add the layer the report does not have - authorisations, exposure and the cost of the target model - and come out with a list of decisions for the committee instead of a document to read. The scope is described on our SAP S/4HANA conversion page.
If you already hold an SAP Readiness Check result and are not sure what to do with it, get in touch. We will walk it through with your Basis team and with whoever owns the programme budget, because those are two different conversations and both need to happen.
Sources
- SAP, SAP Readiness Check - Key Feature Overview, SAP Readiness Check Team, April 2026, public document - help.sap.com (accessed 22 September 2026)
- SAP Note 2913617, SAP Readiness Check for SAP S/4HANA - the central note for the scenario, available after sign-in at me.sap.com
- SAP Note 3344480, SAP Readiness Check Deployment Options - available after sign-in at me.sap.com
- SAP, Maintenance strategy - SAP S/4HANA and SAP Business Suite 7 - support.sap.com (accessed 22 September 2026)
The scope described here follows SAP documentation dated April 2026. SAP extends SAP Readiness Check release by release, so check the current list of analyses in note 2913617 before you base a decision on this article.