S/4HANA Readiness Assessment: A Step-by-Step Guide

Readiness Is Not a Single Score

Here is the uncomfortable truth about most S/4HANA readiness assessments: they measure one thing — usually technical compatibility — and call it readiness. Someone runs the SAP Readiness Check, gets a report full of simplification items and add-on statuses, and declares the organization "ready" or "not ready" based on how that report looks.

That is not readiness. That is a technical inventory.

Real readiness has four dimensions: technical, functional, organizational, and commercial. A migration that scores perfectly on the technical axis but has no executive sponsorship will stall in governance. A project with full board backing but no budget will never leave the planning phase. An organization with funding and technical clarity but zero change management capability will deliver a system that nobody uses.

The assessments that actually predict migration success evaluate all four dimensions, weight them against each other, and produce a realistic picture of where the gaps are. Not a single score. Not a traffic light. A map of what needs to happen before you can migrate with confidence.

If your organization has already identified signs that migration cannot wait, this guide gives you the structured methodology to figure out exactly how prepared you are — and where the work still needs to happen.

Dimension 1 — Technical Readiness

Technical readiness is where most organizations start, and for good reason. The technical dimension is the most concrete, the most measurable, and the one SAP provides the most tooling for. The mistake is not starting here — it is stopping here.

SAP Readiness Check

The SAP Readiness Check is SAP's official assessment tool, available through the SAP for Me portal. It connects to your system data (via SAP EarlyWatch Alert snapshots or direct connection) and produces a report covering:

• Simplification items — changes between ECC and S/4HANA that affect your specific configuration. These range from informational notices to mandatory data model changes.
• Add-on compatibility — whether your installed add-ons have S/4HANA-compatible versions, are being discontinued, or require replacement.
• Sizing recommendations — estimated HANA database size based on your current data volumes, which drives hardware and licensing decisions.
• Business function analysis — which activated business functions map to S/4HANA functionality and which require attention.

What the Readiness Check does not tell you is equally important. It does not assess your custom code. It does not map your integration landscape. It does not evaluate whether your custom frameworks — those bespoke ABAP utilities that your development team built over 15 years — will survive the transition. And it says nothing about the performance implications of moving specific workloads to HANA.

Think of the Readiness Check as a necessary starting point, not a comprehensive answer. Run it early and revisit it periodically as your system changes.

Custom Code Analysis

Custom code is where technical assessments either get serious or stay superficial. We have seen organizations with 30,000+ custom objects where the Readiness Check came back looking manageable, only to discover during sandbox conversion that hundreds of critical programs broke in ways that static analysis never predicted.

There are two levels of custom code analysis, and you need both:

Static analysis uses tools like SCMON (Custom Code Migration Analysis) and ATC cloud-readiness checks (ABAP Test Cockpit with the S/4HANA readiness check variant) to scan your custom code against a catalog of known incompatibilities. This identifies deprecated function module calls, references to removed tables (like BSEG as a transparent table), and syntax that will not compile in the S/4HANA ABAP environment. SAP also provides the Fiori apps for custom code migration that give you a visual dashboard of your remediation backlog.

Static analysis catches the obvious problems. What it misses are the runtime behaviors — custom programs that technically compile but produce wrong results because the underlying data model changed. The classic example: a custom report that reads from BSID/BSAD (open/cleared customer line items) will compile in S/4HANA, but those tables are now compatibility views on ACDOCA, and the performance characteristics are completely different.

Sandbox conversion findings come from actually converting a copy of your system and running your critical processes. This is the only way to find the problems that static analysis cannot predict. Budget time for it. If you want to understand how clean core architecture principles affect this process, the remediation patterns align closely with what a clean core strategy demands.

Database and OS Compatibility

S/4HANA runs exclusively on SAP HANA. That means your current database — whether Oracle, DB2, SQL Server, or MaxDB — is being replaced. But database migration is not just a technical swap. You need to verify:

• Unicode compliance — S/4HANA requires Unicode. If your ECC system is still running non-Unicode (increasingly rare but still out there), you need a Unicode conversion before or during the migration.
• HANA-compatible operating system — SAP HANA has a specific list of supported OS versions. SUSE Linux Enterprise Server and Red Hat Enterprise Linux are the primary options. If your current infrastructure runs on AIX, HP-UX, or Windows, your migration includes a platform change.
• 64-bit requirements — HANA is 64-bit only. Any 32-bit components in your landscape need to be addressed.
• Virtualization and cloud readiness — if you are targeting a hyperscaler deployment or RISE with SAP, your infrastructure requirements change fundamentally. The RISE migration path has its own set of infrastructure prerequisites.

Integration Landscape Inventory

This is the step that most assessments underestimate, and it is the one that causes the most surprises during migration. Every connection to and from your SAP system needs to be cataloged:

• RFC connections — point-to-point connections to other SAP systems, third-party systems, or middleware. How many are active? Which ones are still used?
• IDoc interfaces — EDI partners, logistics integrations, intercompany postings. Each IDoc type needs to be validated against S/4HANA message types.
• Web services and APIs — SOAP, REST, OData. Which are exposed, which are consumed, and which rely on structures that change in S/4HANA?
• Flat file interfaces — batch jobs that produce or consume files. These are often the most poorly documented and the most likely to break silently.
• Middleware connections — SAP PI/PO, SAP Integration Suite, MuleSoft, Dell Boomi, or other integration platforms. If you are running PI/PO, consider whether migrating to Integration Suite should happen before, during, or after your S/4HANA migration.

For each connection, document the system on the other end, the data exchanged, the frequency, the business criticality, and the technical owner. You will need this inventory for cutover planning later, and building it during the assessment saves significant time downstream.

Dimension 2 — Functional Readiness

Technical readiness tells you whether your system can be converted. Functional readiness tells you whether your business processes will survive the conversion intact.

Simplification Item Impact Analysis

S/4HANA is not just ECC on a new database. SAP made significant architectural changes that affect how core business processes work. The most impactful changes for most organizations:

• Business Partner — in S/4HANA, the separate customer master (KNA1) and vendor master (LFA1) concepts are replaced by the Business Partner model. Every customer and vendor record needs to be migrated to a Business Partner. If you have custom logic that distinguishes between customers and vendors at the data model level, it needs to be reworked.
• New Asset Accounting — the classic asset accounting approach (separate depreciation areas stored in different tables) is replaced by New Asset Accounting, where all values are stored in the Universal Journal. If you are already on New Asset Accounting in ECC, you are ahead. If not, this is a significant functional workstream.
• Universal Journal (ACDOCA) — the single source of truth for financial postings. Separate tables for CO line items, ML documents, and profit center accounting are consolidated into one table. This simplifies reporting but changes every custom financial report you have ever built.
• MRP Live — the classic MRP run is replaced by MRP Live, which leverages HANA's in-memory capabilities for dramatically faster planning runs. Your planning processes, exception handling, and custom MRP enhancements need to be evaluated against the new framework.

For each simplification item that the Readiness Check identifies, someone with deep functional knowledge needs to assess the business impact. Technical consultants can tell you that a table is deprecated. Only a functional consultant can tell you what that means for your month-end close.

Business Process Coverage Gaps

Not everything that ECC does maps one-to-one to S/4HANA. Some capabilities have been moved to SAP BTP (Business Technology Platform), some require new Fiori applications, and some have been reimagined entirely.

Common areas where gaps emerge:

• Output management — classic SAPscript and Smart Forms output determination works differently. Many organizations need to re-evaluate their forms strategy.
• Workflow — SAP Business Workflow still exists, but SAP is pushing toward SAP Build Process Automation for new workflows. Your existing workflows will run, but extending them means learning a new tool.
• Analytics and reporting — embedded analytics in S/4HANA replace many classic ECC reports, but custom Z-reports built on classic tables need to be rewritten against the new data model. BTP offers additional analytics capabilities that may fill gaps. Our SAP BTP architecture guide covers how BTP fits into the broader S/4HANA landscape.
• Industry-specific functions — if you are running IS-Oil, IS-Retail, IS-Utilities, or other industry solutions, the S/4HANA equivalents may have different functional scope. Validate carefully.

Fiori UX Readiness

S/4HANA ships with SAP Fiori as the primary user interface. SAP GUI still works for most transactions, but the strategic direction is clear, and many new S/4HANA features are Fiori-only.

Assess your Fiori readiness by answering these questions:

• Role mapping — for each SAP GUI transaction that your users access today, is there a Fiori app equivalent? SAP publishes the Fiori apps library with a mapping from classic transactions to Fiori apps. Not every transaction has a Fiori equivalent yet.
• User adoption appetite — have your end users been through significant UI changes before? Organizations with strong change management history handle the Fiori transition better.
• Infrastructure for Fiori — Fiori requires a front-end server (embedded or standalone), a gateway, and potentially a launchpad configuration. If you are going RISE, much of this is handled, but on-premise deployments need to plan the infrastructure.
• Custom Fiori development — for custom transactions that have no standard Fiori equivalent, who will build the Fiori replacements? Do you have SAPUI5 developers, or do you need to upskill or hire?

Do not assume that users will happily adopt Fiori without preparation. The interface change from SAP GUI to Fiori is one of the most visible changes in the entire migration, and user resistance can undermine the business case for the whole project.

Dimension 3 — Organizational Readiness

This is the dimension that technology-led assessments skip entirely. It is also the dimension that determines whether a technically successful migration translates into actual business value.

Executive Sponsorship and Governance

An S/4HANA migration is not an IT project. It is a business transformation that happens to involve technology. That distinction matters because it determines who sponsors it, who governs it, and who is accountable for outcomes.

Assess whether your organization has:

• A funded executive mandate — not just verbal support, but a formal decision with budget allocation and timeline commitment. "We should do this" is not sponsorship. A signed project charter with a named executive sponsor is.
• Board-level visibility — does the board understand the risk of not migrating? Do they understand the investment required? Board awareness prevents the budget surprises that kill projects mid-flight.
• A governance structure — who makes decisions when the project hits trade-offs between scope, timeline, and budget? A steering committee with decision authority, meeting cadence, and escalation paths needs to exist before the project starts.
• Cross-functional representation — Finance, Supply Chain, HR, IT, and any other major SAP-consuming function needs a seat at the table. Migrations that are governed exclusively by IT deliver technically correct systems that the business rejects.

Change Management Maturity

Organizational change management (OCM) is not a nice-to-have. It is a predictor of adoption. Assess your organization's OCM maturity:

• Has the organization successfully executed large-scale change before? — companies that have been through ERP implementations, major system upgrades, or organizational restructurings have muscle memory for change. Those that have not will struggle.
• Is there a dedicated OCM function or will it be outsourced? — having internal change management capability accelerates the process. Building it from scratch during the project adds time and risk.
• Communication infrastructure — do you have channels and cadences for reaching every impacted user? Town halls, newsletters, training portals, floor champions — the mechanisms matter.
• Training capacity — can you train hundreds or thousands of users on new processes and a new interface within your go-live timeline? What format — classroom, e-learning, embedded help?

Team Skill Gaps

S/4HANA introduces technology stacks that your current team may not know:

• ABAP Cloud — the new development model for S/4HANA extensions. Classic ABAP still runs, but new development should follow the ABAP Cloud (formerly ABAP RESTful Application Programming Model) approach. How many of your developers know it?
• Fiori / SAPUI5 — building and extending Fiori applications requires JavaScript/TypeScript skills that traditional ABAP teams often lack.
• SAP BTP — if your architecture includes BTP components (and increasingly it will), you need skills in Integration Suite, SAP Build, and BTP platform administration. The brownfield vs. greenfield decision directly affects how much BTP skill you will need.
• HANA administration — your Basis team needs HANA DBA skills. HANA administration is fundamentally different from Oracle or SQL Server administration. Backup strategies, memory management, system replication, and performance tuning all work differently.

For each skill gap, decide whether to train, hire, or partner. Training takes 3-6 months to be effective. Hiring in the current SAP talent market takes 2-4 months. Partnering can start immediately but creates dependency. Most organizations use a blend of all three.

Dimension 4 — Commercial Readiness

The commercial dimension is where strategy meets budget. You can be technically ready, functionally prepared, and organizationally aligned, but if the commercial terms do not work, the project does not move.

License Position and Contract Analysis

Your current SAP license position significantly affects your migration options and costs:

• Current license type — are you on a traditional on-premise license, an enterprise agreement, or something else? Your existing license may or may not carry forward to S/4HANA.
• RISE eligibility — SAP's RISE with SAP offering bundles S/4HANA Cloud with infrastructure, tools, and services. Depending on your current contract, SAP may offer conversion credits or favorable commercial terms to move to RISE. Understand what is on the table before negotiating.
• Named user vs. digital access licenses — S/4HANA licensing includes categories like digital access (for indirect/digital use) that did not exist when many ECC contracts were signed. A license true-up may be needed.
• Third-party license implications — your migration may affect licenses for connected systems. Database licenses change (you are moving to HANA). OS licenses may change. Middleware licenses may need updating.

Get your SAP account executive involved early. The commercial conversation is often more complex than the technical one.

Budget Availability and Approval

There is a critical difference between budget intent and funded budget:

• Intent means leadership agrees that S/4HANA migration is necessary and expects to fund it at some point. This is where most organizations sit. Intent does not pay for consultants.
• Funded budget means the money is allocated, approved through the capital expenditure process, and available to spend. This is where the project actually starts.

Assess where you are on this spectrum. If you are at intent, identify what it takes to get to funded: a business case, a cost estimate, a risk analysis, executive presentations. These are deliverables of the assessment itself — the assessment should produce the ammunition needed to secure funding.

Typical S/4HANA migration budgets range from $2M to $50M+ depending on complexity, scope, and approach. If your organization has never approved a technology investment at that scale, the approval process itself becomes a critical path item.

SI/Partner Selection Status

Very few organizations execute S/4HANA migrations entirely with internal resources. Assess your partner readiness:

• Have you evaluated system integrators? — if not, start now. Good SIs are booked 6-12 months out, and the closer you get to the 2027 deadline, the worse availability gets.
• Have you signed an advisory engagement? — an advisory or assessment engagement with an SI helps you validate your internal findings and gets the partner up to speed on your landscape before the main project starts.
• Do you have a partner selection process? — RFPs take 2-3 months. Evaluation and negotiation take another 1-2 months. Factor this into your timeline.

The Assessment Timeline

A thorough readiness assessment across all four dimensions takes 6-8 weeks. Rushing it produces incomplete findings. Stretching it beyond 8 weeks usually means the team is losing focus or waiting for stakeholders who are not engaged.

Here is a proven weekly cadence:

Each week should include a working session with the assessment team and a stakeholder checkpoint to validate findings and gather input. The final deliverable is not just a report — it is a decision package that tells leadership exactly what needs to happen, in what order, and at what cost, before the migration can begin.

Common Assessment Pitfalls

After conducting dozens of readiness assessments, we see the same mistakes repeated. Avoid these:

1. Running the Readiness Check without custom code analysis. The Readiness Check is necessary but not sufficient. It assesses standard SAP configuration, not your custom landscape. Organizations that treat the Readiness Check as the entire technical assessment are consistently surprised during the actual migration. Always pair it with SCMON analysis and, ideally, a sandbox conversion.

2. Skipping the organizational dimension. Technical and functional readiness are comfortable because they are measurable. Organizational readiness requires asking uncomfortable questions about leadership commitment, team capability, and change appetite. Skipping it does not make those problems go away — it just delays the discovery until the project is already underway and the cost of addressing them is higher.

3. Treating the assessment as a one-time event. Readiness is not static. Your system changes. Your organization changes. Your commercial situation changes. The initial assessment establishes a baseline, but it should be revisited quarterly as you move toward migration. What was a green item six months ago may have turned yellow because a key team member left or a budget cycle shifted priorities.

4. Using the assessment as a delay tactic. We have seen organizations run three consecutive readiness assessments over two years, each producing the same findings, because the assessment itself becomes a substitute for action. If the assessment reveals that you are not ready, the correct response is to start addressing the gaps — not to reassess.

5. Not involving business process owners. Technical teams can assess technical readiness. But functional readiness, organizational readiness, and the business case for commercial readiness all require input from the people who actually run the business processes. Finance controllers, supply chain planners, HR administrators — these are the people who know where the real complexities live. Exclude them and your assessment will miss the problems that matter most.

Start Your Assessment Now

If your organization is still running ECC and has not completed a structured readiness assessment across all four dimensions, the time to start is now — not next quarter, not next fiscal year. The 2027 deadline is closer than it appears on the calendar, and every month spent without a clear readiness picture is a month of compressed execution later.

We help organizations execute structured S/4HANA readiness assessments that go beyond the technical checkbox. Whether you are evaluating a brownfield system conversion or a greenfield reimplementation, the assessment methodology is the same — understand all four dimensions before committing to an approach.

Ready to assess your readiness? Explore our S/4HANA migration services for a full migration partnership, or our RISE with SAP migration offering if you are evaluating SAP's cloud-first path. Either way, start with the assessment. Everything else follows from there.