Understanding S/4HANA costs — the cost logic behind SAP's flagship ERP.
Few ERP systems resist blanket pricing statements as much as SAP S/4HANA: costs depend on the deployment option, the programme scope, and your starting position. This page explains the underlying structure — which commercial models exist, what drives implementation effort, and how a multi-year total cost view should be built.
How the licence and subscription model works.
The commercial logic of SAP S/4HANA differs fundamentally by deployment option: the public cloud variant is licensed via subscription, whose scope depends on user profiles and activated functional scope. The private cloud variant combines a subscription with dedicated operations and more room for adaptation. With on-premises deployment, classic licence and maintenance models apply, supplemented by your own or hosted infrastructure. In addition, industry solutions and the question of existing SAP agreements (for example when converting from a legacy system) significantly shape the contract.
For budget planning this means the deployment decision comes before any cost consideration, because it determines not only the payment structure (ongoing subscription versus upfront investment plus maintenance) but also the later effort for adaptation and operations. In our experience it pays to compare the options against an identical requirements scope and to bring existing SAP contract relationships into the negotiation early.
What drives implementation effort.
S/4HANA implementations are, as a rule, multi-year programmes. Typical effort drivers are the transition approach (greenfield, system conversion, or selective migration), the number of countries and entities, the replacement of historically grown custom developments, integration into the existing system landscape, industry requirements, and the degree of process harmonisation the company aims for. The chosen deployment option also affects project effort: the public cloud enforces closeness to the standard, while private cloud and on-premises open up more freedom with correspondingly higher effort.
In terms of project size, S/4HANA programmes typically sit at the upper end of the ERP market — comparable to large Finance & Operations programmes and well above suite implementations such as NetSuite or Business Central. The timeline depends on the transition approach, the rollout strategy across countries and entities, and the availability of experienced consultants and internal key people.
The ongoing cost logic.
The ongoing cost logic follows the deployment option: in the cloud variants the subscription dominates, complemented by a partner's application management services and support for the regular release cycles; with on-premises, maintenance fees, infrastructure or hosting costs, and self-managed upgrade projects take their place. Across all variants, maintaining custom developments, interfaces, and authorisation concepts requires a permanent internal or external support organisation, which in practice accounts for a substantial share of ongoing costs.
What a five-year view should cover.
- Compare deployment options across the full period: subscription models and licence-plus-maintenance models distribute the same substance differently over the years — what matters is the overall view, not the first year.
- Price in the transition approach: system conversion and greenfield differ not only in the project itself but also in follow-on costs for legacy remnants and technical debt.
- Budget upgrade and release effort per option — from centrally applied cloud releases to self-managed upgrade projects in on-premises operations.
- Account for the internal SAP competence organisation (basis, development, authorisations, key users) as a permanent cost block whose size varies with the chosen option.
When it typically gets more expensive
- Extensive historically grown custom developments from a legacy system that must be analysed, replaced, or rebuilt.
- Many countries and entities with industry requirements beyond the standard, each requiring their own localisation and testing cycles.
- Parallel operation of legacy and new systems over long rollout periods, with duplicated operations and interface costs.
When the project typically stays lean
- A firm decision for the public cloud variant with disciplined avoidance of modifications and use of the SAP standard.
- A clearly cut initial scope — for example one core entity with core processes — and a template-based rollout in stages.
- Early cleansing of data and custom developments before the programme starts, instead of carrying legacy baggage into the new system.
Alternatives typically evaluated in this constellation.
Dynamics 365 Finance & Operations
Typically evaluated in parallel when an enterprise programme is due and the organisation is strongly anchored in the Microsoft ecosystem.
Oracle NetSuite
Considered when international structures need to be covered but a leaner cloud suite with a smaller programme footprint suffices.
Dynamics 365 Business Central
Evaluated when the requirements analysis shows that a mid-market system covers the need without enterprise programme structures.
Neutral editorial assessment of the cost structure — deliberately without price figures, as conditions are negotiated individually and change continuously. No paid placements; our approach is documented in the methodology.
What would a suitable ERP mean in your constellation?
Our structured selection advisory captures your situation systematically and shows which systems realistically belong on your shortlist.