What SAP Won’t Tell You About Their Cloud Push — 30 Years In, Here Is My Honest Read

RISE with SAP: a commercial move dressed as a technology move

Let me be direct. RISE with SAP is primarily a commercial repackaging. It is not a technology breakthrough.

SAP bundled S/4HANA Private Cloud Edition, some BTP credits, Business Network access and a migration wrapper into a single subscription — then called it your cloud journey. The framing is smart. It makes staying off RISE feel like standing still.

What RISE genuinely delivers: one contract, one SLA owner, a managed upgrade cadence.

What it actually does commercially: it converts your perpetual licence economics into a subscription model where SAP captures more revenue from you over time. SAP continues to sell perpetual licences for S/4HANA, but the commercial incentives — discounting, support terms, SAP employee bonus, roadmap access — increasingly favour subscription. SAP’s own investor presentations celebrate this transition as their primary financial story. That is fine — it is a legitimate business strategy. But you should know that is what is happening when you sign.

The commercial pressure away from certified independent hosting partners was not a quality decision. It was a margin decision. Many of those environments were more stable and better governed than what SAP’s managed offering delivers today — and if you need something done urgently, you will quickly discover that SAP is slower and significantly more costly than your previous AMS or hosting partner.

For RISE with SAP, SAP primarily resells AWS, Azure and GCP compute — then charges for the management layer on top. Your previous hosting partner was often doing exactly the same thing, with more direct accountability and less cost.

Clean Core: right architecture, wrong justification

The Clean Core principle is correct. I have lived through what reckless ABAP modification did to ERP landscapes. Core namespace modifications, implicit enhancements touching standard objects, Z-code bypassing API contracts — these created the upgrade nightmares that have defined SAP projects for twenty years. Moving toward extension-via-API, BTP-based side-by-side extensibility, and the ABAP Cloud development model is the right direction. I believe this technically.

What I do not accept is the conflation SAP is selling: that Clean Core architecture requires SAP to host your core system. These are two separate questions.

You can build a perfectly clean, upgrade-stable, API-compliant S/4HANA system on your own infrastructure or a trusted partner’s environment. SAP has deliberately blurred this line because the architectural argument is more powerful than the commercial one. If your CTO believes that staying off RISE is technically irresponsible, the commercial negotiation is already over before it starts.

And one more thing on custom code. If your enhancements were done correctly — proper BAdI implementations, clean naming conventions, standard API usage — they are not your problem. Bad governance created technical debt. Good governance did not. The narrative that all custom code is technical debt is a sales argument. Not a technical truth.

The Salesforce question SAP cannot fully answer

Why can Salesforce offer a cloud CRM platform that is more natively configurable — and SAP cannot?

Because Salesforce built a cloud-native, metadata-driven platform from scratch in 1999. When they say no core modifications, the architecture actually supports that constraint. It was designed that way from day one.

SAP is attempting to retrofit a system with roots in the 1970s into a cloud platform model. S/4HANA is not cloud-native. It is S/4 — designed to run on HANA — with cloud deployment options added on top. Clean Core is SAP trying to approximate what Salesforce built, decades later, on a codebase that was never designed for it.

SAP’s strength is the sheer depth and breadth of its functional coverage — finance, logistics, manufacturing, procurement. That complexity is inseparable from its constraints. SAP is asking customers to accept a less configurable system in exchange for upgrade simplicity. For some organisations that trade makes sense. For most complex industrial, pharma or energy companies — it does not.

HANA: a pre-cloud technology carrying a cloud price tag

HANA was genuinely revolutionary in 2011. In-memory columnar processing eliminated batch cycles, collapsed the OLTP and OLAP divide, and delivered real-time reporting on large datasets that simply was not possible on traditional relational databases. On dedicated bare-metal appliances — purpose-built DELL, IBM, HPE, Lenovo hardware — the performance case for HANA is real.

Now consider what happens when you migrate to S/4HANA Cloud Private Edition on a hyperscaler.

You are running HANA on virtualised compute. The bare-metal advantage disappears. Your storage is network-attached. And here is the deeper architectural mismatch: HANA is a scale-up database — add RAM, faster CPUs, larger single nodes, that is how it was designed to grow. Hyperscalers are scale-out environments. These are opposing architectural philosophies. You are running a scale-up database on infrastructure built for scale-out workloads. Neither performs at its best.

SAP’s cloud migration path moves customers from the environment where HANA performs best — dedicated on-premise bare metal — to the environment where it performs worst — virtualised hyperscaler infrastructure. At higher combined cost. A customer who migrated from a well-governed certified HANA appliance to S/4HANA Cloud Private Edition on Azure has in many cases paid more, accepted worse database performance, and gained less than they left behind.

Meanwhile, Aurora, AlloyDB, and Azure SQL Hyperscale — cloud-native databases designed for enterprise transactional workloads — were built from scratch for the hyperscaler model. For analytical workloads, Snowflake, BigQuery, and Databricks outperform HANA at scale on cost-per-query by a wide margin.

ECC ran on Oracle, SQL Server, IBM DB2 and MaxDB for decades. Database choice was standard — even when Oracle was a direct competitor. S/4HANA was deliberately designed with HANA-native features embedded deep in the application layer. This was an architectural decision made at design time. It was not a technical inevitability. HANA licensing and HANA Cloud subscriptions represent billions in SAP revenue. Giving that to AWS or Microsoft was never going to happen.

Separating what is real from what is commercial

After thirty years, here is how I frame this for customers.

• SAP’s architectural direction is broadly correct. API-first extensibility, cleaner upgrade paths, BTP as an integration and extension platform — these are the right moves for enterprise ERP at this scale.
• SAP’s commercial execution is aggressive and not always aligned with customer interest. Subscription conversion, hosting consolidation, HANA lock-in, RISE bundling — these deserve independent scrutiny, separate from the technical narrative.
• Your existing customisations are not automatically your problem. If they were built correctly using standard extension mechanisms, they are not blocking your future. The opposite narrative serves one purpose: moving you faster toward a new contract.
• Clean Core is best practice. It is not a hosting mandate. You can run a clean, upgrade-safe S/4HANA on your own infrastructure.
• HANA’s competitive value has eroded at the analytical layer. Cloud-native alternatives are mature, performant and significantly cheaper for analytics workloads.
• RISE may be right for your organisation. It depends on your infrastructure maturity, your licence estate, your hyperscaler agreements and your in-house capability. It is never universally right.

What we tell our clients

At S5 we have built our practice on one principle. Your business interests are the anchor — not SAP’s commercial roadmap.

That means we tell clients when RISE makes sense and when it adds cost without adding capability. It means we separate clean architecture from forced migration. It means we ask the HANA question directly, even when it makes people uncomfortable in the room.

The SAP partner ecosystem is full of organisations whose revenue aligns with SAP’s commercial agenda. That is not a criticism — it is a structural reality. It means the advice you receive is often biased toward the narrative that moves the most licence and subscription revenue.

The companies that navigate the next five years of SAP’s transformation well will be the ones with genuine technical clarity — understanding what is real innovation and what is commercial lock-in engineered to look like progress. I have been in this industry long enough to tell the difference.

Frequently asked questions