SAP BUYER GUIDE
S/4HANA migration readiness: what to establish before requesting a proposal
Prepare a decision-ready migration brief covering the current landscape, business change, custom code, data, interfaces and cutover.
By Nexus8 Tech Labs · Published 15 October 2026 · Project planning guidance
Start with a readiness decision, not a promised date
Before requesting an SAP S/4HANA migration proposal, establish what your business runs today, what it wants to change and which constraints cannot be ignored. A migration estimate is only meaningful when bidders are working from comparable assumptions. A useful first deliverable is a readiness brief with open questions, evidence owners and decisions required before the plan can be baselined.
Record the landscape you actually operate
List the current SAP product and release, environments, business entities, important modules, third-party add-ons, interfaces and operating dependencies. Include scheduled jobs and manual exchanges that keep business processes moving. Name the owner of each item. Missing documentation is itself a planning issue: record the gap and decide how it will be resolved before accepting an estimate that assumes the information is complete.
Separate technical transition from business redesign
Clarify whether the business wants to preserve most processes, redesign them, introduce a new template or consolidate landscapes. A new implementation and a system conversion have different starting points. The target deployment and product prerequisites also matter. Compare approaches against actual requirements and current SAP guidance; do not select a route solely because a proposal describes it as faster or simpler.
| Decision | Evidence owner |
|---|---|
| Transition approach | Business sponsor and SAP technical lead |
| Custom code and interfaces | Application and integration owners |
| Data and go-live acceptance | Process owners and cutover authority |
Use technical checks as evidence
SAP describes Readiness Check as an input to preparation and provides tools for analysing custom code. Ask the technical team to explain the findings, scope and limitations of the checks relevant to your system. A tool output should feed an owned action list. It is not a substitute for process decisions, integration validation or a business-approved test plan.
Give custom code and interfaces accountable owners
Inventory the reports, enhancements and interfaces that the business still uses. Identify which objects can be retired and which require analysis or adaptation. For each important interface, document who owns the connected application, how data is reconciled and what happens when transmission fails. Avoid accepting an estimate that counts only SAP-side work while leaving the other application team’s effort and availability undefined.
Define what correct data will look like
Agree the scope of data work, the owners of cleansing decisions and the evidence needed for reconciliation. Use representative cases that include exceptions, not only straightforward transactions. Ask how test results will be compared with the agreed source and how unexplained differences will be resolved. Business owners should understand what they are approving rather than relying on a technical transfer-success message.
Make cutover and recovery explicit
Document the business window, sequence of activities, prerequisites, reconciliation checks and go/no-go authority. Ask for a rehearsal approach and a defined recovery decision process. The appropriate options depend on the landscape and transition method; they should not be assumed from a generic checklist. Include post-launch support, issue prioritisation and responsibility for communicating with users.
Request a proposal that shows its assumptions
Send suppliers the same brief and ask them to separate discovery, preparation, delivery, testing, cutover and stabilisation. Compare customer effort as well as supplier effort. For an SAP migration project, specify the locations that require workshops and the activities that may be remote. Nexus8 can discuss your readiness questions and help define a scoped next step before a delivery commitment is made.
Product references
Discuss your SAP requirement
Tell us your company location, SAP landscape, business issue and preferred timing. The next step is a discussion of scope and delivery responsibilities.