Lesson 1 of 5
Choosing where an extension lives
11 min
Listen to this lesson
Contoso Motor Co. is converting SAP ECC 6.0 EHP 8 to SAP S/4HANA Private Edition under RISE with SAP. The conversion carries a lot of custom code across, and the program has made a rule for everything new: keep the core clean. That does not mean "no extensions". It means every new requirement is placed deliberately, using SAP's extension options in a way that survives upgrades. This lesson is about that placement decision, because it drives cost, upgrade effort and how the extension will be tested for years.
The extension options
SAP groups SAP S/4HANA extensibility into on-stack options, which run inside the SAP S/4HANA system, and side-by-side options, which run on SAP Business Technology Platform (SAP BTP, which SAP began rebranding as SAP Business AI Platform in 2026) and talk to SAP S/4HANA remotely. On-stack has two clean tiers. Key user extensibility uses browser-based apps such as Custom Fields, Custom Logic and Custom CDS Views, plus UI adaptation, so business experts and consultants can adapt the system without writing classic ABAP. Developer extensibility uses ABAP Cloud: the ABAP RESTful Application Programming Model (RAP), CDS and released extension points, built in ABAP Development Tools. Private Edition and on-premise systems also still allow classic extensibility (user exits, BAdIs without release contracts, direct table access, modifications), which SAP does not count as clean core.
| Key user (on-stack) | Developer extensibility (on-stack) | Side-by-side (SAP BTP) | Classic (Private Edition / on-premise) | |
|---|---|---|---|---|
| Who builds it | Key users and consultants | ABAP developers | Pro-code or low-code developers | ABAP developers |
| Runs in | SAP S/4HANA | SAP S/4HANA | SAP BTP (Cloud Foundry, Kyma or ABAP environment) | SAP S/4HANA |
| Talks to SAP objects through | Released extension points | Released local APIs and extension points | Released remote APIs and events | Anything, including unreleased objects |
| Coupling to SAP S/4HANA | Tight | Tight | Loose | Tight and fragile |
| Clean core | Yes | Yes | Yes | No |
SAP's clean core guidance, updated in 2025, grades extensions on a scale from level A (built only on released, stable APIs and extension points) down to level D (techniques SAP does not recommend, such as modifications, direct writes to SAP tables, implicit enhancements and objects SAP explicitly marks as not recommended). In between, level B also uses classic SAP APIs that are documented and generally upgrade-stable, such as many BAPIs, and level C accesses SAP internal objects that are neither released nor classic APIs, which carries upgrade risk. The practical message is that the further you move from released interfaces, the more each upgrade costs you.
Questions that decide the location
- Must it run inside the SAP transaction? Logic that has to validate or change a document while it is being saved, in the same logical unit of work, belongs on-stack.
- Who uses it? Users outside the company, such as Great Lakes Fleet Services staff, should not need SAP S/4HANA user accounts. A side-by-side app with its own identity setup fits better.
- How independent is its lifecycle? If it changes weekly while SAP S/4HANA changes in planned releases, side-by-side keeps the two apart.
- Does it combine data from several systems? Mashing up SAP and non-SAP data is a natural side-by-side job.
- Does a released API or event exist? Side-by-side depends on remote APIs and events. If none exists for the data you need, you may have to build a custom API on-stack first.
- What skills and runtime costs apply? BTP services are licensed and metered; ABAP Cloud skills differ from CAP or low-code skills.
- Can a key user tool meet the need (field, simple logic, layout)?Yes → key user extensibility · No → continue
- Must the logic run inside the SAP transaction or need local data with low latency?Yes → developer extensibility with ABAP Cloud · No → continue
- Is it a new app, external user group, cross-system process or independent lifecycle?Yes → side-by-side on SAP BTP · No → continue
- Is a released API or event available for the data it needs?Yes → build side-by-side · No → expose a custom API on-stack first, or ask SAP for a release
SAP formalizes this in the SAP Application Extension Methodology: assess the extension use case in its business and system context, assess which extension styles and technologies apply to each task, and then define the target solution. Contoso's architects use it lightly, as a checklist, and record the decision and the reason in the program's requirement in SAP Cloud ALM, so testers know which pattern they are testing.
| Contoso requirement | Placement | Why |
|---|---|---|
| Fleet contract number on the sales order header | Key user: custom field | Simple field, needed in SAP screens, output and APIs |
| Block saving a fleet order whose contract has expired | Developer extensibility: released BAdI or RAP extension | Must run inside the save, in the same transaction |
| Great Lakes Fleet Services checks order and delivery status online | Side-by-side: CAP app on SAP BTP | External users, independent release cycle, read-only via released API |
| Notify the fleet desk when a fleet order changes | Side-by-side: event-driven | Reacts after the fact; no need to slow down the save |
| Margin analysis across ERP and warranty data | Side-by-side: data extension | Combines several sources for analytics |
How Contoso placed its first five extension requirements.
What would you do?
Kenji, Contoso's ABAP lead, proposes building the fleet order status portal for Great Lakes Fleet Services as a classic Web Dynpro application inside SAP S/4HANA, "because the data is all there". Grace asks the architects to decide. What should they recommend?
- On-stack: key user extensibility and developer extensibility with ABAP Cloud; side-by-side: apps and services on SAP BTP.
- Classic extensibility exists only in Private Edition and on-premise, and it is not clean core.
- Logic that must run inside the SAP transaction goes on-stack; external users, new apps and independent lifecycles point side-by-side.
- Side-by-side depends on released remote APIs and events; check they exist before you commit.
- Record the placement decision and its reason so testers know which pattern they are testing.
Check your understanding · not graded
Lesson check
1. Which requirement most clearly belongs on-stack?
2. Which extension option is available only in Private Edition and on-premise, and is not considered clean core?
3. What must exist before a side-by-side extension can read SAP S/4HANA data cleanly?
4. Why should external users favor a side-by-side design?