The SAP Decision That Will Shape Your Next Decade
The question leadership teams ask us is simple: Public Cloud or Private?
The question we usually find ourselves answering is something else entirely.
Across more than two decades of SAP work, we have learned that the cloud decision is almost never really about cloud. It is about how much complexity an organisation is willing to keep, how much standardisation it can absorb, and how confidently it can change. Most leadership teams come into the conversation thinking they need a recommendation. What they actually need is a clearer view of themselves.
This article is the version of that conversation we cannot have on a single call — what is really driving the decision, where most organisations get it wrong, and how to choose with conviction rather than hope.
Why this decision is no longer optional
For many SAP customers, the question is no longer “Should we move to Public or Private Cloud?” It is “We have to choose soon — or we risk operational disruption, rising cost, and falling behind.”
The pressure is structural. On-premises hardware is reaching end of life. Basis support costs keep climbing. Specialist talent is harder to find and more expensive to retain. Meanwhile, SAP’s innovation cadence has accelerated to the point where deferring decisions means deferring competitive advantage.
Picture the situation many CIOs face today: ECC platforms approaching renewal, integrations becoming harder to maintain, and a business demanding analytics, automation, and AI capabilities the current landscape simply cannot deliver. The cloud decision is no longer just another item on the roadmap. It is the gateway to everything else.
What typically forces the decision
Most SAP customers reach this inflection point because several triggers hit at once:
- End-of-life infrastructure or datacentre renewals forcing a move-or-invest decision
- Rising operational strain on Basis, patching, and monitoring
- Business demand for analytics, automation, and AI that ECC or heavily customised systems cannot support
- Upcoming S/4HANA milestones — greenfield, brownfield, or selective transformation
- Audit, compliance, or data residency pressures that change where workloads are allowed to run
- Growth, restructuring, or M&A activity that legacy architectures cannot scale to meet
When two or three of these converge, the choice becomes unavoidable — and time-sensitive.
The two models, defined
SAP S/4HANA Cloud, Public Edition
SAP operates and manages the service. The infrastructure runs on hyperscalers — Microsoft Azure, AWS, or Google Cloud — but provisioning, capacity, resilience, and platform updates remain SAP’s responsibility. You consume standardised services on demand under a subscription model, with global scalability and rapid provisioning out of the box.
SAP S/4HANA Cloud, Private Edition
Within a RISE with SAP engagement, infrastructure is dedicated to your organisation to deliver high performance and data isolation. The environment typically runs on a hyperscaler but is managed end-to-end by SAP under a single SLA. You retain greater control over configurations, custom code, integration patterns, and upgrade timing — at the cost of higher complexity and a heavier resource footprint.
The role of SAP BTP
SAP Business Technology Platform is the innovation layer that protects a “clean core” across both models. By moving customisations and integrations onto BTP, you avoid modifying the underlying ERP — keeping it agile and upgradeable.
For Public Edition, BTP is the primary vehicle for side-by-side extensibility and advanced analytics. For Private Edition, it provides the structured path to decouple legacy enhancements and modernise the architecture for AI, automation, and third-party connectivity.
A real-world contrast
Theory only takes you so far. Two recent cases sit at opposite ends of the spectrum.
A large manufacturing organisation chose Private Cloud. On the surface the trigger was data sovereignty. Underneath, it was something more concrete: tens of years of operational logic embedded in workflows, billing exceptions, and integrations that the business simply could not afford to renegotiate inside an 18-month transformation. Private Edition gave them functional control, flexible upgrade cycles, residency alignment, and infrastructure isolation. The trade-offs were also clear: higher TCO, slower innovation cadence, greater technical-debt risk, and a heavier internal IT burden. They knew what they were buying — and what they were postponing.
A fast-growing digital business made the opposite choice. With no legacy ERP estate to defend, S/4HANA Public Edition delivered go-live in weeks rather than months, an OPEX model that eliminated upfront hardware investment, immediate access to SAP’s latest innovations including Gen-AI capabilities, and best-practice processes that supported global scaling without a large IT team. The trade-offs: stricter standardisation, less control over release timing, and tighter constraints on configuration and the data model. They moved fast precisely because they had nothing to protect.
Both decisions were correct — because both were grounded in business reality, not in industry fashion or vendor pitch.
How the models compare
Cost structure. Public Cloud is OPEX-driven, with lower upfront investment, reduced infrastructure overhead, and updates included in the subscription. Private Cloud carries higher subscription costs and often dedicated support, but those costs map cleanly to the customisation and control you actually need.
Customisation and flexibility. Public encourages best-practice adoption and limits core modification — ideal for greenfield. Private supports deep customisation, legacy processes, and complex integrations — better suited to brownfield or selective transformation.
Security and compliance. Public offers provider-managed security and a broad certification footprint, though multi-tenant operation can be a concern in heavily regulated sectors. Private offers enhanced residency control, dedicated isolation, and easier alignment to bespoke governance or audit demands.
Performance and scalability. Public delivers elastic scalability and globally optimised performance — strong for variable or seasonal workloads. Private offers predictable performance with planned scaling — strong for stable, well-understood workloads.
Innovation cadence. Public gives faster access to new features through automatic upgrades but demands strong change-management discipline. Private offers more control over upgrade timing within vendor windows, with more room to test integrations and custom code.
Implementation speed. Public deploys faster on the back of preconfigured best-practice content, but requires the business to align to standard processes. Private allows more flexibility but extends timelines as legacy processes, custom objects, and non-standard integrations are rebuilt or adapted.
Where most organisations get this wrong
If the decision were purely analytical, few teams would struggle with it. The patterns that derail otherwise capable organisations are not technical. They are behavioural.
They treat it as an IT decision. The cloud model dictates how the business operates — how quickly processes can change, how often the system shifts under users, how customisation is governed. Letting IT decide alone is how you arrive at a platform the business cannot live with.
They choose Public because it sounds modern. The pull of “cloud-native, standardised, AI-ready” is strong. But Public Cloud is unforgiving of organisations that have not yet committed to standardisation. Going Public without process discipline is the fastest way to a stalled transformation.
They choose Private because it feels safer. Private Cloud preserves optionality, which can be the right call — but it can also be a way of postponing hard conversations about legacy processes, custom code, and operating-model debt. Safety is not the same as the right answer.
They underestimate custom code. Almost every transformation underestimates the volume and the dependency footprint of existing customisation. This single factor moves more decisions than any other once a serious assessment is done.
They confuse the SAP decision with the partner decision. SAP’s commercial model defines the platform. Your implementation partner defines whether you get value out of it. These are different choices, and conflating them is how organisations end up with a technically successful project and a business that hasn’t changed.
If any of these feel familiar, you are not alone. They show up in roughly two out of three programs we are asked to review.
Surviving release upgrades — the integration question
Frequent upgrades, especially in Public Cloud, raise legitimate concerns about integration stability. The pattern that protects either model is the same:
- Use API-first integration patterns — released APIs, events, and CDS views designed for version stability
- Avoid direct database access and classic exits — they are first to break under upgrades
- Decouple through middleware — SAP Integration Suite, Azure Integration Services, or equivalents absorb change so endpoints don’t have to
- Adopt event-driven integration for versioned, durable communication
- Treat regression testing as a discipline, aligned to SAP’s release cycle — automated for Public, gated for Private
In Public Cloud, upgrade risk drops sharply when integrations live on released APIs and BTP side-by-side extensions, backed by automated regression testing. In Private Cloud, flexibility survives when custom logic is wrapped, documented, and decoupled — and when testing is non-negotiable before upgrade windows.
How the IT operating model changes
This is the shift leaders most often underestimate.
Public Cloud asks the business to absorb more change-management effort and IT to absorb less technical effort. Internal teams move away from hands-on Basis and infrastructure work and focus instead on process ownership, data quality, and continuous adoption of new features.
Private Cloud reverses the balance. The business faces less process compromise, but IT, architects, and operations retain more technical responsibility — governance, change control, upgrade planning, and custom-code management. Long-term disruption may be lower, but project overhead is higher.
Either path is a transformation of the operating model, not just the platform. Underestimating that is the most expensive mistake on this list.
A practical decision framework
Six questions cut through most of the noise:
- How standardised are your processes? Fit-to-standard points to Public. Highly tailored, mission-critical processes point to Private.
- What is your appetite for continuous innovation? Agile and fast-moving suits Public. Controlled cycles favour Private.
- What are your regulatory and data-protection requirements? Heavily regulated sectors — banking, pharmaceuticals, public sector — typically land on Private. Strong residency or sovereignty demands push the same way.
- Are you modernising or replicating? Modernisation favours Public. Replication of existing processes favours Private.
- What internal IT capability will you maintain? Reducing the infrastructure and Basis footprint favours Public. Retaining strong technical oversight favours Private.
- What is your growth profile? Variable or rapid scaling favours Public. Stable, predictable demand favours Private.
No single answer decides the case. But a clear pattern across these six almost always does. If your answers contradict each other — for instance, you want continuous innovation but cannot let go of bespoke processes — you have a strategy problem to resolve before you have a cloud decision to make.
The hybrid middle ground
Many organisations do not choose one or the other. They combine them.
Run S/4HANA in Private Cloud while consuming analytics and AI services from Public Cloud. Keep regulated data private and place innovation workloads in Public. Use Public Cloud for burst capacity and disaster recovery. Hybrid is no longer a compromise — for many enterprises across gaming, energy, manufacturing, and financial services, it is the architecture.
What we see in real S/4HANA programs
The patterns repeat:
- Projects begin with a technical mindset and evolve into business transformations — almost always
- Custom-code volume is consistently underestimated, and it shapes the cloud choice more than any other factor
- Stakeholders try to recreate legacy processes, slowing decisions and inflating scope
- Integrations and data — not configuration — become the true critical path
- The business wants innovation faster than IT can deliver, which biases preference toward Public
- Continuous-delivery readiness is low across most organisations, demanding new governance and testing models regardless of the cloud path chosen
These are not edge cases. They are the default. Plan for them, and you remove most of the risk before the first system is provisioned.
The bottom line
Choosing between Public and Private Cloud is a strategic decision, not a technical one.
Public Cloud excels at speed, standardisation, and continuous innovation. Private Cloud excels where flexibility, customisation, and strict control matter most. The right choice aligns to your operating priorities, compliance posture, and change-management maturity — not to personal preference, vendor pressure, or industry fashion.
The best decision is the one grounded in operational readiness, risk tolerance, appetite for innovation, and a clear view of how your organisation needs to evolve over the next three to five years.
That is the conversation worth having now. Most organisations realise — somewhere between month four and month eight of their program — that they should have had it earlier.
A practical next step
If you are inside this decision today, the most useful thing you can do is pressure-test your own thinking against the six questions above before the platform discussion begins.
At StepOne, we run a structured Cloud Readiness Assessment for SAP customers across Greece, Cyprus, the Balkans, and the Middle East. It is a focused engagement designed to surface the answers that matter — process standardisation, custom-code reality, integration risk, operating-model fit, and the commercial model that genuinely serves your roadmap. No platform pitch, no preordained answer.
If your organisation is heading toward this decision in the next 6–18 months, we would welcome the conversation. The earlier we have it, the more options you keep on the table.
— StepOne Enterprise Solutions
