Lesson 5 of 5
Edition constraints
9 min
The same gap can have different answers depending on which SAP S/4HANA edition you run. Contoso is moving to SAP S/4HANA Cloud Private Edition under RISE with SAP, but its process owners need to understand Public Edition too: some subsidiaries may use it, and SAP's direction for all editions is the same clean core model.
Public Edition: the rules are enforced
In SAP S/4HANA Cloud Public Edition, SAP runs a shared, standardized system and upgrades it on its own schedule. Extensions are limited to what keeps that possible: key user extensibility, developer extensibility with ABAP Cloud using released objects, and side-by-side extensions on SAP BTP through released APIs and events. Modifications to SAP code and classic enhancement techniques are not available. In clean core terms, Public Edition extensions are Level A by design.
That constraint is also a protection. Because every extension uses released interfaces, SAP's semiannual upgrades rarely break them, and the regression scope is predictable. The trade-off is that some gaps simply cannot be closed in the core; you adopt, change the business, or build side-by-side.
Private Edition and on-premise: more freedom, more cost
SAP S/4HANA Cloud Private Edition and on-premise give you your own system and the full ABAP platform. Everything available in Public Edition is available here, plus classic extensibility: user exits, classic BAdIs, custom tables and reports, and modifications. The freedom is real, and so is the cost. Each classic extension lands at clean core Level B, C or D, and each is your responsibility to check and retest at every upgrade.
| Topic | Public Edition | Private Edition / on-premise |
|---|---|---|
| Upgrade timing | SAP schedules it, twice a year | Customer plans releases and feature packs |
| Key user extensibility | Yes | Yes |
| ABAP Cloud (released objects only) | Yes | Yes |
| Side-by-side on SAP BTP | Yes | Yes |
| Classic exits, BAdIs, custom tables | No | Yes |
| Modifications to SAP code | No | Possible, strongly discouraged |
| Clean core enforcement | By the platform | By your governance (decision log, code checks) |
When the gap cannot be closed in the core
Sometimes a gap is real, required and impossible to close inside a Public Edition system. The process owner then has three honest options. Change the business process so the standard fits, if the requirement turns out to be habit rather than need. Build the capability side-by-side on SAP BTP, reading and writing through released APIs, and accept that it is a separate application with its own testing and support. Or, if the gap is large and central, revisit the edition choice itself, which is a program decision for the steering committee, not a workshop decision.
What the process owner should not accept is a workaround that moves the requirement into an uncontrolled spreadsheet or e-mail process and calls the gap closed. That hides cost and risk outside the system, where nobody tests it.
Governance when the system does not enforce it
In Private Edition, the clean core depends on your discipline. Practical controls a process owner can insist on:
- A design authority that reviews every extension request against the decision framework.
- A rule that new extensions use key user, ABAP Cloud or side-by-side styles unless an exception is approved and logged.
- Code checks: SAP's ABAP Test Cockpit (ATC) can check custom code against clean core rules; ask the architect to report results by clean core level.
- A target for reducing legacy extensions carried over from ECC, reviewed each release.
- ExploreGap decisionsEvery delta decided with the framework and logged
- RealizeBuild and testExtensions built to the agreed level; linked tests executed
- Before go-liveExtension inventoryCount by clean core level reviewed by the process owner
- Each upgradeRegression and retirementRetest extensions; retire any that standard now covers
What would you do?
Contoso is considering Public Edition for a small new sales subsidiary. Its sales team wants the same custom pricing routine that Detroit has in ECC, which reads SAP internal tables. What should the process owner expect?
- Public Edition allows key user, ABAP Cloud and side-by-side extensions only; no modifications.
- Private Edition and on-premise also allow classic extensibility, with higher lifecycle cost.
- Where the platform does not enforce clean core, governance must: design authority, rules, ATC checks.
- Review the extension inventory by clean core level before signing the design.
Check your understanding · not graded
Lesson check
1. Which extension technique is NOT available in SAP S/4HANA Cloud Public Edition?
2. In Private Edition, who enforces clean core?
3. Which SAP tool can check custom ABAP code against clean core rules?
4. What should a process owner see before signing the design?