SAP editions

• S/4HANA (on-premise): you run and manage everything; maximum control and customisation, full responsibility for infrastructure and upgrades.
• S/4HANA Cloud, private edition: a single-tenant cloud system managed by SAP (often via RISE), close to on-premise capability with cloud operations.
• S/4HANA Cloud, public edition: multi-tenant SaaS with standardised processes, quarterly innovation, and limited (extension-based) customisation.

Before the differences, it is worth knowing what somebody means when they say the words. Deployment answers where the system runs and who operates it, which is a hosting question. Edition answers what the software allows you to do, which is a licensing and architecture question. The two are related and they are not the same, and a conversation that mixes them tends to conclude that cloud is cheaper without establishing what is being given up. Keep them apart and each has a clear answer.

The marketing descriptions are similar enough to be unhelpful. The differences that change a project are these.

Who controls the upgrade date. In the public cloud SAP upgrades on its schedule and you test to it. On-premise you choose, and you also carry the work. This is the single biggest difference in how a support team operates.

What you can change. Public cloud exposes a defined set of extension points. Private cloud and on-premise allow the classic development approaches, including ones that make future upgrades harder.

Which processes are available. Public cloud ships a fitted scope. If a process you need is not in it, that is not a configuration exercise, it is a reason the edition does not fit.

How you get data in and out. Public cloud is API-first, with no database access. Integrations written against tables do not travel.

Restating it as one question: on public cloud you adapt the business to the system, and elsewhere you can adapt the system to the business. Everything else follows from that.

On-premise and private cloud give you deep customisation but more responsibility; public cloud gives you a standardised, always-current system with far less to manage, at the cost of flexibility. The right choice depends on how unique your processes truly are.

The cost that is real and rarely modelled is the upgrade you do not control. On public cloud, updates arrive on a published schedule and your team tests against them in a fixed window, several times a year, forever. That is a standing commitment of people's time. It is usually smaller than the cost of running your own upgrades, and it is not zero, and a business plan that assumes it is zero will be wrong in the first year.

Version note: the naming has changed more than once, and older material uses names SAP has since retired. Read any comparison for what it says about upgrade control, extensibility and data access rather than for the labels, because those three questions have stayed stable while the marketing terms have not.

An hour, and it is the assessment a consultant is actually asked for.

1. Take one requirement the business genuinely has: a pricing rule, an approval step, a statutory report.
2. Ask whether standard covers it. If yes, every edition works.
3. If not, ask what kind of change it needs: configuration, an extension field, custom logic on a standard object, or a new object.
4. Check whether public cloud offers an extension point for that kind.
5. If it does not, the requirement either changes or the edition does.
6. Repeat for the five or six requirements that are genuinely distinctive.

Six requirements answered this way settle the edition question far better than a feature comparison, because they are the requirements the comparison never mentions.

It is easy to read a comparison and conclude the editions are different products. For the work a functional consultant does, most of it is the same everywhere, and being clear about that is useful when a client asks whether their team's skills transfer.

The data model is the same. A sales order is a sales order, with the same header and item structure and the same document flow, whether it was created in a public cloud tenant or an on-premise system.

The organisational structure is the same. Company code, plant, sales area, purchasing organisation and their assignments behave identically, and designing them is the same exercise.

The business processes are the same. Order to cash, procure to pay and record to report run through the same documents and the same postings.

The Fiori applications are largely the same, which is why the user facing training overlaps almost completely.

What differs is how you change it and who controls the release. That is a genuinely large difference and it is a narrower one than the comparison tables suggest. A consultant who knows the process on-premise is a competent public cloud consultant after learning the configuration tooling and the extension model, which is weeks rather than years.

Across all editions SAP pushes a "clean core" model: keep the standard system unmodified and build extensions on BTP or via approved in-app extensibility. This keeps upgrades smooth and is essential in the cloud editions where you cannot freely modify the core.

The reason it is worth taking seriously even on-premise: every modification is something a future upgrade has to reconcile, and SPAU worklists are the bill. Clean core is not a cloud rule that leaked outwards. It is the practice that keeps upgrades cheap anywhere. See what SAP is for where this sits.

In practice the question to ask about any proposed extension is where it would live. Something that changes how a standard object behaves, built inside that object, is a modification and will be met again at every upgrade. The same requirement expressed through a released extension point, or built as a separate application that talks to the system through APIs, costs about the same to build and nothing to carry forward. That difference compounds over a decade, which is roughly how long these systems run.

• Choosing public cloud for highly bespoke processes that need heavy customisation.
• Assuming cloud means no work, configuration and change management still apply.
• Ignoring clean core, over-customising complicates every future upgrade.

• Choosing on price. The edition decides how the business operates.
• Assuming a table-based integration travels. Public cloud has no database access.
• Treating "cloud" as one thing. See S/4HANA versus ECC, SAP versus Workday and SAP versus Oracle ERP.

Two further ones worth naming. Deciding the edition before the requirements are known. The decision depends on a handful of distinctive requirements, and if nobody has written them down there is nothing to decide against. Assuming the edition can change later. Moving between them is a project, not a switch, because the extensions and integrations were built against a specific model.

The honest summary for a first conversation with a client: public cloud is cheaper to run and constrains what you can build, on-premise is the reverse, and private cloud sits between them by giving you the classic system with somebody else operating it. Which is right depends on how unusual the business genuinely is, and most businesses believe they are more unusual than they are.

Naming the editions takes ten minutes, and arguing one against a real requirement list is the part you do in the course.