In-app or side-by-side: where should an S/4HANA extension live?
A placement decision, not a tooling preference: three questions that route each extension to the right layer.
The short answer
Use in-app (on-stack) extensibility when the change is small, tightly bound to one S/4HANA business object, and needs to run inside the same transaction, such as a custom field, a validation, or a released BAdI. Use side-by-side extensions on SAP BTP when the logic is larger, spans several systems, has its own lifecycle or user interface, or should not be able to slow down the ERP core. The deciding questions are transaction coupling, data gravity, and who owns the lifecycle. In both cases the clean core rule is the same: build only on released, upgrade-safe interfaces, and retire the custom code that merely duplicates standard before choosing where the rest should live.
What is the difference between in-app and side-by-side extensibility?
In-app (on-stack) extensibility changes or extends S/4HANA from inside the system, using key-user tools and ABAP Cloud-style development against released objects. The extension runs in the same stack and the same transaction as the standard process.
Side-by-side extensibility runs outside the core, typically on SAP BTP, and talks to S/4HANA through released APIs and events. Think of it as the difference between adding a shelf inside a load-bearing wall and building an annex next to the house. The shelf is quick and convenient, but it shares the wall. The annex has its own foundations and its own rules, and it connects through a door.
Which three questions decide where an extension belongs?
We use the same three questions on every candidate. They are a heuristic, not an SAP mandate, and edge cases exist, but they sort most of an estate quickly.
- Transaction coupling: must the logic run inside the same database transaction and be able to block or change the posting? If yes, it generally belongs in-app via a released extension point.
- Data gravity: does it mostly read and write one business object, or does it combine data from several systems? Multi-system logic belongs side-by-side.
- Lifecycle ownership: does it need its own release cadence, user interface, or team? If it changes faster or more slowly than the ERP, keep it out of the core.
When is in-app the better choice?
In-app fits small, synchronous, object-level changes: an added field on a sales document, a validation before save, a derivation of a value at posting time. Because it executes with the standard process, there is no network hop, no second authorization model, and no extra system to monitor.
The discipline is staying on released objects. An in-app extension that reaches into unreleased internals is simply a modification with better branding, and it will cost you at the next upgrade.
When is side-by-side the better choice?
Side-by-side fits logic that is asynchronous, cross-system, analytics-heavy, or customer- or partner-facing: an approval app that spans ERP and a ticketing tool, a pricing simulation that should not consume ERP dialog resources, or an AI agent that reads business data and proposes actions. It also isolates risk, because a failing extension cannot take down a posting run.
The trade-off is operational weight. You take on another runtime, another set of credentials, event handling, and monitoring. For a ten-line validation that is poor value; for a process with its own users and release cycle it is the right home.
What should you do before choosing a layer?
Decide whether the code should exist at all. In a reference estate analysed from a live ECC system, a large share of custom objects were never executed or duplicated standard capability; a customer's numbers come from their own system, not from ours. Only the remainder needs a placement decision.
That ordering matters: retire first, then place. Moving an unused or redundant custom program onto BTP just relocates the maintenance burden. Fit-to-standard analysis and usage evidence from your own system tell you which extensions earn a layer. This is an ownership choice about where you want to carry complexity, and SAP supports both patterns as part of its clean core guidance.
Frequently asked
Is side-by-side extensibility always the clean core answer?
No. Clean core means extending through released, upgrade-safe interfaces, and in-app extensions built on released objects qualify. Side-by-side is the better fit for cross-system or independently released logic, but it adds an operational footprint that small, tightly coupled changes do not justify.
Can an extension start in-app and move side-by-side later?
Yes, if you keep the business logic separate from the integration points and rely only on released APIs. Extensions written against unreleased internals are the ones that are expensive to move, which is another reason to enforce released-object discipline from day one.
How do AI agents fit into this model?
Agents that read business data and propose actions generally sit side-by-side, calling released APIs. In our approach, any configuration an agent proposes is drafted as a governed customizing transport that the customer's change board decides on, in development systems only, and never touches production on its own. SAP has described agent-led capabilities at Sapphire 2026; those claims are SAP's.
See your own Clean Core Score.
Run the free S/4 readiness scan in under a minute — no system access required.
Keep reading