An S/4HANA decision can begin with timing already under discussion. Timing is one input, but it should be considered alongside business, process, data and architecture evidence.

These decisions shape programme scope whether they are addressed explicitly or allowed to emerge during planning. Examine them before selecting a transition path.

What a transition-path decision is made of Four inputs feed one decision: business and process intent, data condition, architecture constraints, and timing. They converge on a single transition-path decision between a new implementation, a system conversion and a selective transition. The inputs are drawn as equals on one spine, with no weighting or ordering. Four inputs, no ranking A Business intent B Data condition C Architecture constraints D Timing Transition path New implementation System conversion Selective transition What a transition-path decision is made of Four inputs feed one decision: business and process intent, data condition, architecture constraints, and timing. They converge on a single transition-path decision between a new implementation, a system conversion and a selective transition. The inputs are drawn as equals on one spine, with no weighting or ordering. Four inputs, no ranking A Business intent B Data condition C Architecture constraints D Timing Transition path New implementation System conversion Selective transition
The four inputs are argued together, and the route follows from them. The current-estate answer may not fit the target state.

1. How much of your current solution has earned the right to survive?

SAP describes three established transition paths to SAP S/4HANA. A new implementation builds processes on a fresh system and migrates the data you choose to bring. A system conversion moves your existing system in place, carrying configuration and history with it. A selective data transition sits between them — SAP's own material describes shell-conversion and mix-and-match variants, where a target system is built and chosen configuration, repository objects and data are brought across according to defined rules.

Selecting a transition approach combines business, process, data, architecture, regulatory, operational, and technical considerations. The business question — how much of your current process estate genuinely earns its keep — is easily left until last, and it deserves to be answered early alongside the others.

Assess each customization by the business consequence of removing it: for each significant process, ask what would break if it were replaced by SAP standard. Not "who would complain" — what would break. Some answers are an inconvenience for a quarter. Others are a contractual exposure, such as partner billing that a joint-venture partner would dispute.

Use the business consequences to distinguish essential scope from candidates for simplification. Document the reasoning so that path selection is based on evidence rather than preference.

2. What will your data actually support?

Data quality is discussed as a migration workstream. It is better understood as a constraint on scope.

Master data that has drifted over many years does not become correct because it lands in a new system. If your vendor master has duplicates, your cost centre hierarchy has been extended sideways to represent something it was never meant to represent, and your chart of accounts encodes three abandoned reporting structures, then process redesign that depends on clean dimensions may remain constrained until the underlying data is remediated — not because the technology can't do it, but because the data can't feed it.

Run the profiling before the design workshops, not after. Early evidence can change what is worth designing, and may avoid later rework.

3. Where does finance want to end up?

For finance-led organizations this is the decision that shapes the others, and it is easily treated as a detail.

The chart of accounts, the profitability-analysis approach, the legal-entity structure, and whether Central Finance is a staging strategy or a permanent architecture — these determine what the transition can deliver.

Where finance-structure changes are already planned, evaluate them as part of transition design. Changes deferred until after go-live require their own planning, governance and testing.

4. When can the business absorb the change?

The business calendar can constrain when change is absorbable. Relevant considerations may include year-end, regulatory filing windows, acquisitions, turnaround activity or operational seasons.

Some constraints are visible early enough to inform sequencing. Treat subject-matter-expert availability as a planning input rather than discovering it only during cutover preparation.

What about deployment?

Deployment matters — SAP's private cloud ERP offering, currently named SAP Cloud ERP Private and still widely referred to as SAP S/4HANA Cloud Private Edition; SAP's SAP S/4HANA Cloud Public Edition, a foundational application of SAP Cloud ERP; continuing on-premise deployment; and the RISE with SAP programme. Each carries real consequences for how much of your current configuration carries forward. The current commercial and operating specifics are worth confirming with SAP directly rather than taking from an article.

But deployment follows from the four decisions above rather than replacing them. When retention decisions are documented, the deployment discussion can focus on the fit among available options rather than reopening earlier scope questions.

A defensible order of decisions

Decide what deserves to survive. Establish what the data supports. Settle where finance is going. Sequence against the calendar. Then choose a transition path and a deployment model, and let the timeline be an output rather than an input.

This sequence places evidence before path selection. It gives decision-makers an explicit basis for reviewing scope, assumptions and later change requests.

Scope of this note

This describes the decisions and the evidence behind them. SAP maintenance dates, commercial terms and deployment specifics are for SAP to state directly.

S/4HANA transformation