Before an S/4HANA program begins, there is a quieter phase that determines whether the program will be remembered as a success or a saga: readiness. This is the moment to surface dependencies, quantify technical debt, and decide what the transformation will actually involve. This checklist condenses the readiness evaluation into 25 practical checks across the areas that most often decide an outcome—landscape, custom code, data, integration, infrastructure, testing, cutover, and operations. It is designed to be worked through with a steering committee, not by the IT team in isolation.
- System sizing and historical data archiving pre-requisites
- Business Partner (CVI) conversion prerequisite readiness
- Custom code simplification item mapping in ABAP Test Cockpit
- End-to-end integration inventory and testing scope definition
Start With the Business, Not the System
Readiness is not a technical gate. It begins with alignment on what the transformation is for: which business outcomes matter, which migration approach fits, and what the desired target state looks like.
If leadership cannot describe what success looks like beyond “run on S/4HANA,” that ambiguity will surface later as scope drift, contested decisions, and a harder business case to defend.
The first checks are therefore about intent and governance as much as architecture.
- Define the business outcomes the transformation must deliver
- Agree the preferred migration approach before deep-diving into detail
- Describe the target state in terms the business recognizes
Landscape and Custom Code
The landscape check is a fact-finding exercise: which SAP systems exist, what versions and modules are in use, and which systems are business-critical. Without this baseline, every downstream decision is guesswork.
Custom code is where the deepest uncertainty usually sits. The check here is to quantify how much custom code exists, which developments are business-critical, and which should be remediated, replaced, or retired. A decision framework of retained, remediated, redesigned, replaced, or retired keeps this objective.
The goal is to avoid carrying unnecessary complexity into a new environment simply because it already exists.
- Inventory SAP systems, versions, modules, and criticality
- Quantify custom code and classify each development
- Decide what is retained, remediated, redesigned, replaced, or retired
Do not automatically take yesterday’s code into tomorrow’s environment.
Data, Integration, and Infrastructure
Data readiness answers four questions: what must move, what historical data is required, what cleansing is needed, and how migrated data will be validated. Data is where business confidence is won or lost after go-live, so these checks deserve real scrutiny.
Integration readiness maps every system that connects to SAP—interfaces, APIs, middleware, EDI, and connected applications—and identifies which are business-critical. Integration dependencies are a classic source of critical-path surprises.
Infrastructure readiness confirms where S/4HANA will run, the availability and performance requirements, and the security and disaster-recovery considerations that apply.
- Define data scope, cleansing, and validation expectations
- Map the integration ecosystem and flag business-critical interfaces
- Confirm the target infrastructure and its availability, security, and DR requirements
Testing, Cutover, and Operations
Testing readiness is about timing as much as scope. What processes must be validated, which integrations require end-to-end testing, and when will testing begin? Testing that starts late compresses the go-live window and converts risk into crisis.
Cutover readiness defines the migration sequence, the expected downtime, how business validation will occur, and the contingency plan. The final migration window should not be the first time the plan is tested.
Operations readiness answers who supports the system after go-live, how performance will be monitored, and what hypercare looks like. The migration is not finished when production is running.
- Schedule testing early and scope it end-to-end, including integrations
- Plan cutover sequence, downtime, validation, and rollback in advance
- Define post-go-live support, monitoring, and hypercare before cutover
The final migration window should not be the first time the plan is tested.
Readiness is not a delay before the real work begins—it is the first and most valuable phase of the work. The enterprises that invest here spend less later, because they surface dependencies and risks while the cost of changing course is still low. Work through these checks with your leadership team, be honest about what you do not yet know, and let the findings shape the plan. A transformation that starts from a clear understanding of the current landscape is a transformation that has a realistic chance of meeting its promises.