Private cloud is just hosted S/4HANA.
For about a decade that was accurate, and it was useful. It meant the deployment decision was an operating-model decision — who runs the infrastructure, who patches, who holds the SLA — and not a capability decision. The software was the software. Where it ran was a separate question with separate economics.
That sentence expired in October 2025, and I don’t think enough people noticed.
Shared foundation, separate scope
The 2025 release shipped on 8 October 2025. Same ABAP Platform underneath both editions. Same release date. Same seven-year maintenance window running to December 2032.
Shared foundation, in other words. But not shared scope.
SAP’s own release documentation states the position plainly: AI capabilities and intelligent agents are available exclusively in SAP S/4HANA Cloud Private Edition — now branded SAP Cloud ERP Private — while on-premise SAP S/4HANA 2025 receives core functional enhancements.[1]
One more scope note, because leaving it out would be its own kind of misleading. There’s a third deployment model — public edition, now branded SAP Cloud ERP — and it isn’t part of this comparison at all. It runs on a separate, multi-tenant codebase with its own continuous release cadence, outside the numbered 2025/2027 releases this piece is about. It’s also not behind: public edition has had Joule since November 2024, nearly a year ahead of private edition’s embedded layer, and continues to pick up new agents on its own schedule. If you’re on public edition, this specific split isn’t your split — but the pattern underneath it is the same one: deployment model, not capability demand, decides when and whether you get the agent layer.
The on-premise edition is not being abandoned. It gets real improvements — finance, asset management, service, sales, the ABAP development experience. These aren’t consolation prizes. If your 2027 target state is a well-run, current, functionally complete ERP, on-premise 2025 delivers it.
What it does not get, as part of the release, is the agent layer.
What the line actually separates
Both editions can reach AI. That’s the part people get wrong in the other direction — they hear “no AI on premise,” and that isn’t true either.
The supported on-premise pattern is real and it works. S/4HANA exposes OData. A BTP application reads it with principal propagation, calls the orchestration service, and returns a result. For plenty of use cases that is entirely sufficient.
But look at what you have once it’s built. A capability sitting next to the system. Someone has to leave the transaction, ask it a question, read the answer, come back, and act. Three steps where the process had one — and a decision point that lives outside the audit trail of the thing it changed.
On the other side of the line, the agent isn’t a separate application you built. It’s licensed as part of the product and embedded in the same screen — the user never leaves the transaction to consult it.
That is the difference, and it is not a feature-count difference.
One edition lets you build AI your people can consult. The other licenses AI that’s already embedded where the work happens.
Anyone who’s run a rollout has watched this pattern before, wearing different clothes. Enable Now content is supposed to track the system as it changes. Six months after go-live, how much of what shifted during hypercare actually made it back into the training material? Test automation is supposed to keep testing the system — how many of those scripts still run, and how many died the slow death updating them always does once something else is on fire? Neither tool failed. Staying current was a separate decision every time, and separate decisions are the first thing hypercare kills.
That’s the general shape of it: adoption is a function of how many decisions a capability costs, not of the capability itself. Put an agent beside the transaction and it costs one every time — open it, ask it, act on the answer, same as opening Enable Now instead of just working. Put it inside the transaction and it costs nothing. There’s no separate decision to lose to hypercare, because there’s nothing to open.
The price isn’t money
Every capability gap in SAP’s history has had a price on it. License the add-on. Buy the module. Build it on the platform. Pay a partner to close it. That is what a gap normally is — a purchase you haven’t made yet.
This one has a price too. It just isn’t denominated in money.
At Sapphire in May 2026, SAP reversed a years-long position and announced that Joule assistants and agents would be extended to ECC and on-premise S/4HANA. That was real news, and anyone still describing the boundary as absolute is working from a 2025 picture.
Then read the conditions. Access requires beginning the migration through RISE with SAP and committing the majority of the landscape to SAP Cloud ERP. SAP’s own product documentation for ABAP AI on on-premise releases — 2025, 2023, 2022 and 2021 — says availability is subject to the special RISE contract conditions announced at Sapphire, and tells you to verify entitlement and contract status with your account executive before planning adoption.[2] SAP’s leadership has framed the whole arrangement as an interim bridge rather than a long-term commitment to on-premise AI.
So it is purchasable. There’s still no SKU. What there is instead is a qualification.
That distinction matters more than it sounds. A SKU can be scoped. You can pilot it on one plant, buy a limited quantity, expand if it works, walk away if it doesn’t. A qualification can’t be scoped, because the thing being priced isn’t the capability — it’s your estate. There is no line item for AI on three plants. There is a commitment about where the majority of your systems will live, and the capability arrives as a consequence of it.
The only currency that buys the agent layer is deployment model. That was true as an architecture observation in October 2025. Since Sapphire it’s true as a contract term.
That is an unusual sentence to be writing about an ERP in 2026, and it is why the pre-2025 sentence has to come out of your architecture document. It didn’t merely become inaccurate. It became a sentence that hides a decision.
The honest counter-argument
The strongest objection to all of this is that the boundary is already moving. Sapphire proved the line isn’t fixed. Cloud-first is what every vendor does with AI — the infrastructure, the metering and the model access all live there — and it doesn’t follow that on-premise is being deliberately starved. If SAP extended AI to on-premise once, under pressure from an installed base that isn’t migrating fast enough, it can extend it again on better terms.
That’s a fair reading and I’d hold it loosely rather than dismiss it.
But notice what actually moved. The capability crossed the line; the dependency didn’t. The extension is conditioned on landscape commitment, delivered side by side rather than inside the transaction, and described by SAP as a bridge. The boundary didn’t dissolve. It got a toll booth, and the toll is denominated in exactly the currency this piece is about.
That’s a weaker form of “the gap is closing” than it first appears. Plan for the dependency holding. Be pleased if it loosens.
What this changes
Deployment model now determines feature availability, not just operating responsibility. That’s a different conversation with a different set of people in the room.
For an architect, any decision that rested on the old sentence needs re-examining. Not necessarily reversing — re-examining.
For a CFO, the comparison is no longer hosting cost against hosting cost. It’s hosting cost against hosting cost plus a capability set available on one side only, on terms that price your estate rather than the feature — and whose 2027 pricing isn’t published on either side yet, which makes the comparison harder rather than easier.
For a program, the deployment decision may already be made. If any capability in your 2027 target architecture depends on the agent being inside the transaction, you don’t have a deployment choice. You have a deployment consequence to accept.
Here’s how you find out which one you are. List the AI-dependent capabilities in your 2027 target architecture. For each one, ask a single question: does the value depend on the AI being in the transaction — or only on it being available to the person doing the transaction?
If everything on your list is the second kind, you have no problem here. Build it on BTP, keep the deployment decision where it belongs — sovereignty, control, cost structure — and ignore the rest of this. That’s a legitimate outcome, and more organizations should reach it deliberately rather than by default.
If anything on your list is the first kind, the decision is already made. What remains is when you say so out loud.
Twenty minutes. A list and one column. Better you run it than a steering committee — because the version that surfaces in a steering committee arrives as a budget request, and this was never a budget question.
Search your architecture documents for the sentence, or any variant of it. If it’s in there, it’s describing a product that stopped existing in October 2025. The point isn’t to make you move. It’s that where you run should be a decision you made, rather than an assumption you inherited from a document written in 2023.