Executive Clarity · Decision 6 of 8

SAP BTP & Extensibility

Clean Core does not mean no differentiation. It means making a deliberate decision about where custom logic lives, how tightly it couples to the core and who owns its lifecycle.

The question

Which requirements belong in standard SAP, which should be handled through on-stack extensibility, and which deserve an independently managed side-by-side application on SAP Business Technology Platform?

Decision factors

The documented facts

  • SAP distinguishes key-user extensibility, developer extensibility and side-by-side extensibility.
  • Key-user and developer extensions can run on-stack in SAP S/4HANA Cloud; side-by-side extensions run decoupled on SAP BTP with a separate runtime and lifecycle.
  • ABAP Cloud uses released APIs, extension points and a cloud-safe language model to support upgrade-stable development.
  • Private-cloud and on-premise customers can continue using classic ABAP, but SAP's guidance states that classic ABAP is not Clean Core by default and is not recommended for new extensions.
  • SAP BTP supports low-code and pro-code options, including SAP Build, CAP and the SAP BTP ABAP environment.

Inference

  • Side-by-side is not automatically better. It adds integration, security, observability, data-consistency and operational responsibilities that must be justified.
  • The right location is determined by coupling: how close the extension must be to the transaction, data model, latency, release cycle and authorisation context.
  • Moving code out of the core without reducing complexity merely relocates technical debt.
  • A BTP platform team is an operating capability, not a licence entitlement. Without standards, product ownership and runtime governance, the platform becomes a second custom-code estate.

Point of view

“Put it on BTP” is not an architecture decision. It is the beginning of one. Every extension needs a reason, a product owner, an approved pattern, an API contract, a support model and a retirement path.

Conditional, not ideological — the recommendation grid

Use standard

When the process is not differentiating

Adopt the standard process and remove the requirement from the backlog. Configuration is not failure; unnecessary customisation is.

Use key-user extensibility

For small, local adaptations

Fields, forms, UI adaptations and limited custom logic close to the standard process, using released extension mechanisms.

Use developer extensibility

For tightly coupled domain logic

Use ABAP Cloud and released APIs when the extension must share the S/4HANA transaction, data or lifecycle context.

Use side-by-side

For independent capabilities

Choose BTP when the solution benefits from a separate lifecycle, combines multiple systems, serves a different audience or needs independent scaling.

The extension decision record

For every proposed extension, record:

  • business outcome and named owner;
  • why standard SAP is insufficient;
  • required coupling, latency and data access;
  • chosen extensibility pattern and released APIs;
  • security, testing, observability and support ownership;
  • upgrade and retirement strategy;
  • estimated build and five-year run cost.

Monday-morning questions

  • Which existing custom objects are actually used, and which can be retired?
  • Which new requirements need transactional proximity rather than simply access to SAP data?
  • Who operates, monitors and secures side-by-side applications after the programme leaves?
  • Are the required APIs released and lifecycle-stable?
  • What prevents the extension portfolio from becoming the next legacy estate?

Where this sits in the decision chain

This is decision 6 of 8 in the Executive Clarity decision library. It follows the Business Case and TCO decision and leads to Data and Business AI, where architecture must provide trusted context for decisions and agents.

Sources

Editorial standard: documented platform options, inference and point of view are kept separate above. Published 2026-08-03 · By Andreas BORN.