RISE, GROW, private or public cloud: reading SAP’s offerings like a buyer.

A quick reminder of what we are talking about. GROW with SAP designates the path to S/4HANA Cloud, public edition: shared software, identical for every customer, operated and updated by SAP at the pace SAP decides. RISE with SAP mainly covers the private edition: an instance dedicated to you, operated by the vendor on cloud infrastructure, where genuine latitude remains for configuration and for conversion from your existing system. On-premise, finally, has not disappeared: you own the system, you host it where you wish, you answer for it entirely. Three models, then, which the brochures present as three stages of a single journey. They are better understood as three different distributions of power and responsibility between you and your vendor.

What each model gives, and what it takes away

The structural difference can be said in few words. The public edition imposes the standard. Your processes align with the software’s, your extensions live outside the core, and upgrades arrive when the vendor releases them, whether that suits you or not. In exchange for this loss of control, you receive something precious and rarely named: a discipline. No one in your company can dig into the core of the system anymore. Custom-code drift, the drift that left so many ECC systems impossible to move forward, becomes structurally impossible.

The private edition offers the reverse. It accommodates your existing system, its custom code to a large extent, its history, its habits. The continuity is real, and so is the room for maneuver. But the discipline no longer comes with the subscription: it is yours to build, through explicit architecture governance, failing which you will reconstitute within a few years, in the cloud, the very legacy you were leaving behind. We devoted a full article to this clean core question; it arises here with particular sharpness.

On-premise neither gives nor takes away. Total freedom of architecture, calendar and hosting; total responsibility for operations, security, upgrades and keeping the system healthy over time. Some contexts fully justify it. Provided, that is, that the freedom is exercised and the responsibility carried by teams sized for it.

A cloud offering is not read in its brochure. It is read in what it leaves you the right to do, and in what it obliges you to become.

The five questions that strip an offering bare

Faced with a proposal, whatever its label, we recommend running it through five questions. None is technical in the narrow sense; all are contractual and operational.

• Who operates what? Behind the word "managed" lie widely varying scopes. Who applies the patches, who monitors, who restores, who answers at night when production breaks? Demand the responsibility matrix line by line, not the summary diagram.
• What is reversible? If in five years you wanted to change model, host or provider, what would you get back, in what form, in how much time? Reversibility that is not written into the contract does not exist.
• What happens to your custom code? Which developments carry over, which must be rewritten as extensions, which disappear? The answer drives the program’s real cost far more than the subscription price does.
• How does the cost move when your volumes move? Upward, but downward too: a divested business, a shrinking market. Billing metrics deserve to be simulated on your scenarios, not only on the growth one.
• What freedom of architecture do you give up, and in exchange for what? Each model trades latitude for speed or peace of mind. The trade can be excellent. It simply has to be conscious, and accepted by those who will live with it.

The right choice is an attribute of your existing landscape

We are often asked which of these offerings is the best. We invariably answer that the question is badly put. A company whose processes are close to the standard, or that wants to hold itself to it, will find an accelerator in the public edition; the same offering would be a poor choice for a group whose custom code carries a real competitive advantage. A landscape heavy with history argues for the private edition, provided architecture governance keeps pace. The choice is an attribute of your situation: state of processes, weight of custom code, maturity of governance, internal skills. These are the very dimensions we detailed in connection with the 2027 deadline, because the two decisions are one: the operating model is chosen together with the trajectory, not after it.

That is exactly what our 2027 Assessment delivers: a baseline review of your existing landscape, scenarios compared in full costs, and an operating-model recommendation argued on your data. The integration landscape, often overlooked in these comparisons even though every model redraws it, is the subject of our cloud and integration practice.

One last word, which matters in this particular debate: at KOORTIS, advice comes before everything else. When we recommend a model to you, it is because it follows from your existing landscape and your trajectory; we put it in writing, and we stand by it in front of you. That is the whole value of an opinion that seeks to convince by its arguments alone.