How should organisations plan an SAP S/4HANA migration when the deadline is approaching but the target state is still undecided?

How to plan the migration when the target state is not yet fixed

The practical move is to separate decision-making from execution, then keep both moving in parallel. Lock down the facts that will shape the programme, current customisations, integrations, reporting dependencies, data quality, and release constraints, while a small set of stakeholders evaluates the migration options. That avoids wasting time on a premature design, but it also prevents deadline pressure from turning into avoidable rework later.

A useful way to think about the work is as option narrowing. Greenfield, brownfield, and hybrid approaches each carry different trade-offs for standardisation, technical debt, test effort, and business disruption, so the aim is not to guess the winner early. It is to define the criteria that will decide it, then use them to compare the options against the actual operating model the business needs.

For SAP programmes, this usually means creating a decision backlog rather than a single binary decision gate. You need enough architectural and process detail to understand what must be preserved, what can be simplified, and what can be redesigned, while also keeping the schedule visible so the unresolved target state does not drift into a last-minute crisis. The migration plan should therefore include option-dependent workstreams, with clear points where the team can commit or pivot.

What the evaluation work should cover before the path is chosen

The evaluation should focus on process fit, data migration complexity, and the operational consequences of each route. If the organisation has many unique processes, heavy custom development, or fragile downstream integrations, the cost of a full reimplementation will be different from an incremental conversion. If the business wants to standardise and simplify, a greenfield-style reset may be attractive even if it requires more process change management.

Dependency mapping matters because the technical path is only part of the real risk. Finance, procurement, supply chain, and reporting often depend on adjacent systems, user roles, interfaces, and cutover windows that are easy to underestimate. A migration strategy is stronger when it shows which dependencies are fixed, which can be retired, and which require temporary coexistence while the target design is still being finalised.

The other key issue is timing discipline. When deadlines approach, organisations often over-commit to implementation activity before they have decided what should be carried forward. That can lock in technical debt, make testing less meaningful, and raise the chance of expensive redesign late in the programme. Early discovery work should therefore be treated as a risk-reduction phase, not as delay.

Risk and Threat Considerations

The main risk is not choosing the wrong migration style in the abstract, it is entering build and cutover planning before the target state is clear. That creates rework, increases the chance of overlooked dependencies, and can leave business-critical processes trapped in a half-designed transition state.

Failure mechanism: When scope, process ownership, or conversion criteria remain undecided, teams usually make assumptions to keep the project moving. Those assumptions can hard-code unnecessary customisation, weaken testing coverage, and expose cutover to surprise breakpoints in integrations, controls, or reporting.

Impact: The programme can slip, costs can rise, and the business may end up accepting a migration shape that is technically workable but operationally awkward for years. In the worst case, compressed decision-making forces a path that increases disruption at go-live and reduces confidence in the new platform.

Practitioner Guidance

What to prioritise: Build a decision framework around business outcomes, process criticality, and dependency risk before finalising the migration path. The first question is not which conversion method is easiest to start, but which option best preserves control over the processes that matter most.

What to verify: Confirm that every major integration, report, and custom process has an owner, a migration disposition, and a test implication. If those three things are missing, the programme is not yet ready to lock the target state, even if the deadline is close.

Practitioner takeaway: The safest path is usually the one that makes the decision late enough to be informed, but early enough to preserve implementation quality and cutover control.

Related resources from NHI Mgmt Group

• How should security teams plan an SAP ECC to S/4HANA migration without disrupting business operations?
• When should organisations choose Greenfield over Brownfield for SAP S/4HANA migration?
• How should organisations plan an SAP ECC migration when support is ending and integrations are tied to core business processes?
• How should organisations govern access to SAP workloads in RISE with SAP S/4HANA Cloud without weakening identity controls during migration?