SAP Readiness Check and S/4HANA migration assessment

An S/4HANA migration assessment tells you what your ECC system will cost and take to move, and which path fits. The SAP Readiness Check is the technical half of that assessment: it compares your system against S/4HANA and lists what will break, but it does not make the decisions for you.

Short answer: run the Readiness Check first, in production, with custom code results uploaded. Then spend the real effort on what it cannot see, which is whether your processes, data, custom objects and interfaces should move at all.

For the full migration sequence, start with my ECC to S/4HANA migration guide.

SAP Readiness Check for SAP S/4HANA is a cloud application from SAP. You run data collectors in your ECC system, upload the results and get an interactive dashboard of how S/4HANA affects that system.

According to SAP's Readiness Check key feature overview (September 2026), it is available on SAP for Me to all customers with an active SAP maintenance agreement. Customers with an SAP Cloud ALM tenant can also run it there, and push findings into Cloud ALM as project tasks.

You do not buy it separately. The real cost is the time of your Basis team and the people who read the results.

SAP runs separate scenarios for upgrades, BW/4HANA and other products. For an ECC migration you want SAP Readiness Check for SAP S/4HANA. The target can be S/4HANA on-premise or SAP S/4HANA Cloud Private Edition, the RISE with SAP target, as SAP's learning content on conversion preparation explains.

SAP's current list for the S/4HANA scenario has 17 checks. The table below groups the ones that matter most for a migration decision, with what each tells you and where I'd be careful.

Check	What it tells you	Where to be careful
Simplification items	Which S/4HANA changes apply to your system, with an effort ranking and related activities	Based mostly on table contents and used transactions, so it shows relevance, not your fix
Add-on compatibility	Whether each SAP and third-party add-on is compatible, incompatible or unknown for your target release	Incompatible add-ons block the conversion in SUM; "unknown" means a vendor call
Active business functions	Business functions that are incompatible and would block the conversion	A blocker here needs an SAP support incident early
Custom code analysis	ATC or Custom Code Migration app findings, grouped by impact, with quick fix counts and used or unused scope	Only appears if you upload the custom code results separately
SAP S/4HANA sizing	Initial HANA memory and disk size, top tables and archiving potential	A starting point for sizing, not a final hardware or RISE sizing
Integration	Inventory of IDocs, RFCs and BAPIs, web services, OData, BW extractors, flat files and SLT, with likely impact	Shows technical interfaces in this system only, not the systems on the other end
Customer vendor integration	How many customers and vendors are already business partners, and the data quality issues	Business partner conversion catches more teams than any other prerequisite
Financial data quality	Inconsistencies in general ledger, asset accounting and material ledger, by year and company code	Category D findings need system-specific correction, which takes time
Planned downtime calculator	Expected business downtime for a standard SUM conversion in one data centre	Indicative only; your cutover plan sets the real window
App availability and recommended Fiori apps	Transactions that are deprecated or replaced, and Fiori apps suited to your usage	Recommendations, not a UX design
Business Process Discovery	Process automation rates, overdue backlog and non-standard order types	A preview of process insight, covered more fully below

The central guidance is SAP Note 2913617, SAP Readiness Check for SAP S/4HANA. Read the current version before you start, because SAP updates the prerequisite notes regularly.

Running the Readiness Check

1. 01

   Prepare

   Implement the notes listed in SAP Note 2913617 in the system you will analyse, normally production.

2. 02

   Collect

   Run the data collection report RC_COLLECT_ANALYSIS_DATA as a background job, choose the target release, then download the ZIP.

3. 03

   Custom code

   Run the S/4HANA custom code checks in ATC or the Custom Code Migration app and export the results.

4. 04

   Upload

   Create a new analysis on the SAP Readiness Check page in SAP for Me and upload both files.

5. 05

   Review

   Walk through every check with Basis, finance, the process owners and your custom code lead.

A few points the step list does not show.

1. Use production. SAP's guidance is to analyse production, because those are the results you will plan with. Several checks rely on real usage history, which a sandbox does not have.
2. Upload the custom code results. The main data collection does not analyse your custom code on its own. If nobody uploads the ATC or Custom Code Migration app results into the same analysis, the custom code section stays empty and the report looks cleaner than your system is.
3. Check the target release. Pick the S/4HANA or Private Edition release you will actually land on. Simplification items and add-on status change between releases.
4. Expect some back and forth. Data collectors fail, notes are missing and jobs run long on large systems. Plan elapsed time for it, not just effort.

The landing page is at me.sap.com/readinesscheck.

The check is good at one question: what in this system collides with S/4HANA. It is not built to answer whether that thing should exist.

Custom objects

In my experience, what the Readiness Check misses that hurts later is custom objects. It tells you which custom code breaks against the simplification items. It does not tell you which Z-programs, tables, enhancements, forms and reports still serve a business purpose, which duplicate standard S/4HANA function, or which nobody has run in years.

That gap matters because custom code is the phase that overruns most often on the programmes I see. It is also the hidden cost most often forgotten in the budget.

The number of findings and the number of custom objects are different numbers. On one programme, analysis with smartShift took us from 18,000 custom objects to 3,200. The Readiness Check alone would not have made that cut, because it measures impact, not value.

So I treat the custom code section as the start of the inventory, not the end. The Custom Code Migration app adds used and unused scope, smartShift adds automated analysis and remediation, and someone in the business still has to agree what gets retired.

Everything outside the analysed system

The check looks at one ECC system. It does not see:

1. Process design. Whether your order-to-cash or record-to-report should be redesigned, which is what decides greenfield, brownfield or selective.
2. The other end of interfaces. It lists the interfaces in ECC. The middleware, third-party systems and their owners are outside it.
3. Data you have not loaded yet. Data from non-SAP systems, and the data quality outside finance and business partner.
4. Organisation and change. Who owns decisions, how ready users are and what the business can absorb during the programme.
5. Commercials. Licence conversion, RISE scope and partner cost are not in any SAP dashboard.

Business Process Discovery gives a first look at process performance. A deeper SAP analysis is SAP Signavio Process Insights, discovery edition, which SAP's value of support page describes as recommendations on process improvements across six lines of business. Useful input, still not a design.

A migration assessment takes the Readiness Check as one input and turns it into decisions you can fund. This is how the two compare.

Question	SAP Readiness Check	Full migration assessment
What in ECC conflicts with S/4HANA?	Yes, in detail	Uses the check results
Which custom objects should we keep, retire or rebuild?	Partly: impact, plus usage if you use the Custom Code Migration app	Yes: object inventory, usage, business owner, decision
Greenfield, brownfield or selective?	No	Yes, based on process and data findings
Which interfaces and external systems change?	ECC side only	Both ends, with owners and remediation
How clean is our data beyond finance?	Partly	Yes, with a cleansing plan and owner
How long will it take and what will it cost?	Downtime and sizing estimates only	Timeline, cost range and contingency
Which deployment and commercial model?	No	On-premise, Private Edition or Public Edition, and what to negotiate

The tools I use are the SAP Readiness Check, the Custom Code Migration app and smartShift for custom code, and SNP or Natuvion where selective data transition is on the table. None replaces a design review with your process owners.

My path rule then does the rest. Greenfield when you are moving from other systems or new processes must be defined, brownfield when processes are defined and working, selective when the processes of some areas need to be redefined. My free S/4HANA migration assessment tool walks through the same trade-offs if you want a first read before spending money.

The output should feed straight into a migration timeline and project plan and a migration cost estimate. It is also what you hand to partners: if they cannot respond to your assessment with a specific high-level design, that tells you something. My guide on how to choose an S/4HANA migration partner covers that step.

It depends. I won't give a single number, because the drivers vary too much between companies.

These move it:

1. Number of systems and clients. One ECC production system is a different job from five, with separate BW, CRM and SRM.
2. Custom code volume. Thousands of custom objects need usage analysis and business decisions, and that is people time, not tool time.
3. Interfaces. Every external system needs an owner who can say what changes on their side.
4. Entities and countries. More company codes means more localisation, tax and reporting questions.
5. Data quality. Large financial inconsistencies or messy business partner data need investigation before anyone can estimate.
6. Business availability. Process owners who can give the assessment real hours shorten it more than any tool.
7. Access. Waiting for notes to be approved and production jobs to be scheduled adds elapsed time with no analysis done.

What I would not do is cut the assessment short to start build sooner. Across the 21 SAP programmes I have led or rescued, the biggest mistake I see is not planning properly at the start. The assessment is where that planning begins.

Ask your Basis team to implement SAP Note 2913617 in production this month and run the Readiness Check with custom code results included. Then book a half day with your finance lead, a process owner and your custom code lead to read it together and list the questions it does not answer.

That list is the scope of your migration assessment. If you want an independent view on it before you go to partners, get in touch.

What is the SAP Readiness Check for S/4HANA?

It is a cloud application from SAP that analyses your SAP ERP system against SAP S/4HANA. You run data collectors in the system, upload the results on SAP for Me and get a dashboard covering simplification items, add-ons, business functions, custom code, sizing, interfaces, business partner, financial data quality and recommended Fiori apps.

Is the SAP Readiness Check free for SAP customers?

SAP makes it available on SAP for Me to all customers with an active SAP maintenance agreement, and in SAP Cloud ALM for customers with a Cloud ALM tenant. The real cost is the internal and partner time to prepare the system and interpret the results.

How do you run the SAP Readiness Check?

Implement the notes in SAP Note 2913617, normally in production. Run the data collection report RC_COLLECT_ANALYSIS_DATA, download the ZIP and run the custom code analysis separately in ATC or the Custom Code Migration app. Upload both into one analysis on the SAP Readiness Check page in SAP for Me.

What does the SAP Readiness Check not cover?

It does not decide whether your custom objects are still needed, whether your processes should be redesigned, what happens on the other end of your interfaces, or what the programme will cost. It analyses one system for technical compatibility. Those other questions belong to a full migration assessment.

How long does an S/4HANA migration assessment take?

It depends on the number of systems, the volume of custom code, the number of interfaces and entities, the state of your data and how much time process owners can give it.

Should I run the Readiness Check before choosing greenfield or brownfield?

Yes. It shows how much of your system collides with S/4HANA, which is one input to the path decision. The decision itself depends on whether your processes are defined and working, which the check does not measure.