It comes down to how much your processes need to deviate from standard and how much custom code you carry. Public Cloud is a standardised, multi-tenant SaaS ERP: you adopt SAP's best-practice processes, extensions are limited to approved clean-core methods, and you take mandatory quarterly updates. That makes it the fastest and lowest-TCO route — ideal for greenfield situations, mid-market companies, and subsidiaries in a two-tier model. Private Edition (also delivered through RISE) is a single-tenant cloud environment that behaves much more like traditional S/4HANA: far more configuration freedom, the ability to carry custom code and modifications, and more control over when you take upgrades. It suits organisations with genuinely differentiated or complex processes moving off a heavily tailored legacy system. The honest answer for many is that the right choice is decided process by process during an assessment — which is exactly what our readiness and fit-to-standard review is for, so you commit to the edition that fits rather than discovering the mismatch mid-project.

Fit-to-standard is an implementation approach: instead of gathering requirements and then building the system to match them, you start from SAP's pre-configured best-practice processes and adapt your ways of working to them, only addressing genuine gaps. In workshops, you review each standard process and decide "adopt as-is", "configure within standard", or "genuine gap needing an extension" — and the discipline is being honest that many "requirements" are simply how the old system happened to work. Clean core is the related principle on the technical side: keep the standard core software unmodified, and put any custom logic, fields or apps outside it — side-by-side on SAP BTP — using only released extension points and public APIs. The reason both matter is the same: they are what allow SAP to push quarterly updates to your system without breaking it. A customised core and a bespoke build are what make upgrades painful; a standard core with clean extensions is what makes evergreen actually work.

Public Cloud is evergreen: SAP delivers regular updates on a fixed schedule, and taking them is part of the model rather than optional. Updates land first in a test environment ahead of production, which gives you a window to validate. The reason this is manageable rather than alarming is the clean core: because you have not modified standard, updates to standard cannot silently break your configuration, and your extensions sit on stable released interfaces. The right operating rhythm — which we build into managed services — is to run regression testing on your key business processes and your extensions and integrations against each release in the test window, review what new capabilities are worth adopting, and confirm nothing you depend on has changed behaviour, before it reaches production. Handled that way, the quarterly cycle becomes a steady stream of innovation you absorb in a predictable cadence, not a periodic emergency. The organisations that struggle with it are almost always the ones that compromised the clean core.

You can extend Public Cloud — the constraint is how, not whether. There are two broad routes. In-app extensibility covers lighter needs within the system's guardrails: custom fields, custom logic at released extension points, adapted forms and simple custom apps, all built by configuration and key-user tools without touching the core. Side-by-side extensibility handles anything more substantial: a genuinely custom application or complex logic is built on SAP BTP as a separate app that talks to S/4HANA through released public APIs and events. What you cannot do — and this is deliberate — is modify the standard core the way traditional on-premise SAP allowed. In practice this changes the design conversation: the question becomes "does standard cover this, can in-app extensibility handle it, or does it warrant a side-by-side app on BTP?" We make that call for each genuine gap, so you get the differentiation you need without accumulating the technical debt that breaks upgrades.

Far shorter than a traditional on-premise SAP programme, precisely because you are adopting standard rather than building from scratch. Delivery follows SAP Activate — Discover, Prepare, Explore, Realize, Deploy, Run — with fit-to-standard workshops in the Explore phase and configuration delivered in time-boxed sprints. For a focused scope on standard processes, a greenfield Public Cloud implementation is often measured in a handful of months rather than the year-plus that heavily customised projects take. The variables that move the timeline are the number of legal entities and countries, the volume and cleanliness of data to migrate, the number of genuine extensions and integrations, and — most of all — organisational readiness to adopt standard ways of working. That last factor is the one most within your control and the one that most often determines whether the project runs fast: the more the organisation embraces fit-to-standard, the quicker and cheaper it goes. We size the realistic timeline during the assessment rather than quoting a generic number.