A field guide for the CIO, CFO, or EVP-IT weighing an SAP S/4HANA Cloud Public Edition program — written for the people who own the budget, not the configurators.
The views below are my own, drawn from work across SAP, Oracle, and JD Edwards estates. SAP would frame parts of this differently, and I welcome that conversation.
The mental model that quietly wrecks public-cloud projects
If you have sponsored an ERP implementation in the last twenty years, you carry an instinct: gather requirements, blueprint a solution that mirrors how your business already runs, customize the software to fit, go live, and absorb an expensive upgrade every few years. That instinct produced systems perfectly shaped to the organization — and impossibly costly to change afterward.
Bring that instinct to S/4HANA Cloud Public Edition and the program will struggle. The public cloud is not a hosting decision; it is a different consumption model. The leadership task is less about choosing features and more about unlearning habits that the on-premise era rewarded. What follows is an executive read on the SAP Activate methodology for a greenfield public-cloud rollout — what happens at each stage, and where the money and the risk actually sit.
Clean Core is the constraint, not a slogan
The older model treated ERP like a custom-built house: if you wanted to move a wall, you altered the code; if you wanted another room, you bolted on a custom process. The house fit you exactly and cost a fortune to renovate.
Public cloud is closer to leasing a floor in a high-spec building. The furniture and the layout are yours; the structural steel is not. In SAP terms, the structural steel is the standard source code, and the rule is simple: you do not modify it. That is the Clean Core principle.
The payoff for accepting it is mechanical. Because the foundation is untouched, SAP can push semi-annual releases — for example a February release followed by an August release — without breaking operations, which means new features, security patches, and embedded AI arrive on a predictable cadence rather than through a project. The cost is discipline: genuinely distinctive processes have to live outside the core through SAP's extensibility model, so the upgrade path stays clean. For an economic buyer, Clean Core is the lever that turns the historical upgrade event into routine, lower-cost maintenance.
SAP Activate replaces the waterfall you remember
The old ASAP method was a waterfall — blueprint, build, test, in sequence. SAP Activate is an iterative framework deliberately engineered to push standardization and speed. The phases matter less as a process diagram than as a sequence of decisions where leadership either protects the business case or quietly forfeits it.
Discover: the fail-fast gate before you sign
The single most expensive mistake is buying the wrong edition. Before a contract, the Digital Discovery Assessment maps your requirements against what the Public Edition actually does out of the box. Treat it as a scoping instrument, not a sales ritual. If the standard covers materially less than the bulk of your critical processes — or if anyone on your side is talking about changing how the system's kernel behaves — that is the signal to look at Private Cloud instead. The honest answer at this gate saves far more than it costs.
Prepare: landscape and governance
Two early decisions set the tone. First, insist on a three-system landscape — Development, Test, and Production — rather than the leaner two-system setup early cloud projects used; the dedicated development environment lets teams build extensions in modern ABAP Cloud without putting production at risk. Second, the project runs on SAP Cloud ALM, included in the subscription, which replaces heavier on-premise tooling and serves as the system of record for every requirement and test case. Neither is glamorous; both determine whether the program is auditable later.
Explore: where the program is actually won or lost
This phase is a culture test disguised as a workshop. Instead of asking users what they want, consultants run the live best-practice process in a starter system and ask whether the business can operate that way. Fit-to-Standard.
Predictably, users will say no — and almost always they mean "this is unfamiliar," not "this is impossible." This is the moment that needs the sponsor, not the project manager. The leadership mandate is to make standard the default and to require a written business case for any deviation. Every "delta" that slips through because it was easier to say yes is legacy inefficiency re-imported at full price, and it is paid for twice: once to build it and again at every upgrade.
Realize: configuration, then the data reality
Construction happens largely through SAP Central Business Configuration, which sits outside the ERP and deploys settings such as organizational structures and tax rules into the system. Data migration runs through the Migration Cockpit, which loads through strict APIs and will reject dirty legacy data outright.
State this plainly to the steering committee: data cleansing always takes longer than the plan assumes, and if the legacy data is poor, the Migration Cockpit becomes the critical-path bottleneck. Fund the cleanup early or pay for the delay later.
Deploy: the blackout you do not control
In the public cloud, you do not own the upgrade calendar. SAP upgrades the Test system roughly two weeks ahead of Production, and during that window the two systems run different versions and transports are blocked. The practical constraint for leadership: a go-live cannot be scheduled into an upgrade window — typically February and August — so the rollout roadmap has to respect SAP's release calendar rather than the other way around.
The payoff worth the discipline
The discipline buys three things an on-premise estate cannot easily get.
First, AI readiness. SAP's copilot capabilities and embedded AI rely on standard data structures; customize the core and that surface degrades. A Clean Core can simplify integration for AI use cases; readiness still depends on data quality, approved access, testing and accountable business ownership.
Second, data unification. SAP's Business Data Cloud is positioned to connect data across the enterprise without large ETL programs — but the connective tissue assumes the standards are intact.
Third, agility. SAP cites a large industrial-technology customer that, on moving to a standardized public-cloud model, reduced custom add-ons from thousands to hundreds. Treat the magnitude as a vendor reference point until your own estate proves it; the direction — fewer bespoke objects, lower change cost, faster business pivots — is the part that holds.
The trade, stated for the people who fund it
S/4HANA Cloud Public Edition is a trade. You give up the freedom to bend the software into the exact shape of yesterday's processes, and in return you get a standardized platform that improves itself on a schedule. The leadership posture that makes the trade pay off is consistent: do not let teams design from a blank sheet, and do enforce Fit-to-Standard; do not treat the upgrade cycle as an interruption, and do treat it as a twice-yearly injection of capability you have already paid for. Done well, repeat work becomes easier to automate — because the standardization that the method forces is the same thing that lets repeat work shrink.
Analysis by Ravi Madhavan. Originally published on LinkedIn. Allari runs the ERP support layer for JDE, SAP, Oracle Fusion, and NetSuite estates — absorbing the semi-annual regression cycle and the repeatable operational work this method creates, and finding where that work can be automated.
