SAP S/4HANA deployment options explained: on-premise, private and public cloud
A practical comparison of S/4HANA on-premise, RISE private cloud and public cloud editions — upgrade cadence, extensibility limits, cost drivers and how to pick one.
Almost every SAP conversation in 2026 starts with the same question: which S/4HANA edition should we run? The three options look similar on a slide, but they differ enormously in how much you can change, how often you are upgraded, and who carries the operational risk.
The three editions at a glance
| Dimension | On-premise | Private cloud (RISE) | Public cloud |
|---|---|---|---|
| Upgrade cadence | You decide (annual release) | Annual, scheduled with SAP | Two mandatory upgrades per year |
| Custom ABAP | Unrestricted | Allowed, ABAP Cloud encouraged | Side-by-side on BTP only |
| Infrastructure | Yours | SAP-managed hyperscaler tenant | Fully SAP-managed, multi-tenant |
| Best for | Heavily customised brownfield | Brownfield moving to cloud ops | Greenfield, standard processes |
Brownfield, greenfield or selective
Brownfield (system conversion) keeps your existing ECC data and configuration and converts it in place. It is the fastest route when your processes work and your custom code is manageable. Run the Readiness Check and the Simplification Item Check early: they surface incompatible add-ons, industry solutions and custom code that will block the conversion.
Greenfield rebuilds on standard best-practice content. It costs more in change management but leaves you clean-core and cheap to upgrade. Selective data transition sits in between — new system, carried-over master data and selected history.
Clean core is the real design constraint
Whatever edition you choose, the modern rule is: do not modify the core. Extensions belong in one of three layers:
- Key user extensibility — custom fields, logic and adaptations made in-app, upgrade-safe by design.
- Developer extensibility (ABAP Cloud) — released APIs only, no direct table access, no modification of SAP objects.
- Side-by-side on SAP BTP — CAP or Node/Java services consuming released OData and event APIs, with their own lifecycle.
Teams that keep to this model report upgrade windows measured in hours rather than weeks, because there is no regression surface inside the core.
Costs people forget
- Custom code remediation — usually the largest single line item in a brownfield project. Use the ATC checks with the S/4HANA readiness variant to size it before you commit.
- Integration rebuild — PI/PO reaching end of maintenance pushes most estates onto Integration Suite; budget for redeveloping interfaces, not just migrating them.
- Testing — two mandatory public-cloud upgrades per year means automated regression testing is not optional.
- Fiori enablement — every classic transaction you keep is UX debt; plan the app inventory per role.
A pragmatic decision path
- Count your Z-objects and classify them: reusable, replaceable by standard, or dead. Dead code is often 30–40% of the total.
- If more than a handful of custom objects touch core tables directly, public cloud is out for this wave.
- If your finance and logistics processes already track standard, greenfield public cloud gives the lowest long-run TCO.
- If you need industry-specific functionality or third-party add-ons, private cloud under RISE is usually the pragmatic middle.
Before you sign
Ask for the exact upgrade notification window, the RTO/RPO commitment, who holds OS/DB administration rights, and how sandbox refreshes are handled. Those four answers determine what day-two operations actually feel like far more than the licence model does.
Related reading: our guides on SAP BTP extensions and the clean core and the SAP vendor resource page.