Direct answer: Choose an SAP extension approach by examining the business requirement, supported extension points, transaction coupling, data needs, and operating ownership. Key user tools can address supported smaller changes; developer extensibility can address suitable work within the SAP stack; side-by-side development on SAP BTP can suit loosely coupled applications. Clean core depends on supported boundaries and maintainability, not simply on moving code outside ERP.

A manufacturer has a pricing rule that differentiates its service. A distributor has a customer commitment process that standard software does not fully represent. A life sciences company has a specialized approval requirement. In each case, the business may have a legitimate reason to extend SAP. The implementation decision is how to preserve that requirement without creating avoidable difficulty for the next release.

For US technology leaders, clean core should be a way to make those decisions more consistently. It should help teams explain why an extension exists, which supported interfaces it uses, and who will maintain it. This guide translates that principle into a practical choice among key user extensibility, ABAP Cloud, and side-by-side development on SAP Business Technology Platform.

Define clean core through the next change

A useful test of an extension is whether the organization can understand and change it when SAP or the business evolves. That requires a documented purpose, a supported technical boundary, appropriate tests, and an owner. The physical location of the code is only one part of the answer.

An application on BTP can still depend on an unstable interface or reproduce business rules that drift away from ERP. An extension inside the SAP stack can be maintainable when it uses the supported development model and released objects appropriate to the edition and release. Avoid deciding cleanliness through a simple inside-versus-outside rule.

SAP's extensibility documentation distinguishes key user, developer, and side-by-side options for S/4HANA Cloud Public Edition. Product and release support must be checked before applying a pattern to another environment. The categories are a useful starting point, but the actual requirement and supported capabilities determine the design. [1]

Establish whether the requirement still needs custom work

Before selecting a development environment, describe the business behavior in plain language. Identify who needs it, when it occurs, and what result is required. Separate the current implementation from the underlying need. A request to preserve a particular program may conceal a process that standard capabilities can now support.

Ask the process owner to evaluate the available standard behavior with realistic examples. Record the difference that remains and its consequence. “Users prefer the old screen” and “the process cannot represent a required contractual condition” deserve different decisions. Neither should be dismissed automatically, but the justification should be explicit.

Use this review to retire unnecessary work. Some extensions exist because of an old organizational structure, a discontinued product, or a temporary integration. Removing them can be more valuable than rewriting them elegantly. Obtain business acceptance of retirement rather than assuming that a low transaction count proves an extension has no purpose.

When key user extensibility is worth considering

For supported changes such as certain fields, forms, layouts, or analytics, built-in key user tools may offer a suitable path. The exact capabilities and extension points vary by solution. Check whether the required behavior fits within the supported mechanism before commissioning an application that recreates a small change at greater operating cost.

The decision still needs design discipline. A new field requires a definition, data owner, intended use, and treatment across interfaces and reports. A small change to the interface can have a larger effect if people interpret the field differently or expect it to appear in downstream systems automatically.

Test the entire process affected by the change. Confirm role access, display behavior, reporting, and integration where relevant. Keep documentation proportional, but do not equate low-code configuration with an absence of lifecycle responsibility. The next person changing the process needs to understand why the extension exists.

What ABAP Cloud changes in the discussion

SAP describes ABAP Cloud as a cloud-ready development model, with availability across supported S/4HANA environments as well as SAP BTP ABAP environment. It is not synonymous with moving every ABAP program to BTP. The supported model, released APIs, and available objects should guide design in the chosen environment. [2]

For work that is closely connected to an ERP transaction, developer extensibility may be appropriate when supported capabilities meet the requirement. Evaluate whether the logic needs immediate access to transaction context, how it participates in the process, and which lifecycle constraints apply. Avoid assuming an external call is preferable merely because it creates architectural distance.

An illustrative example is a validation closely tied to saving a business document. The team should investigate the supported extension mechanism for that document and the applicable release. If an appropriate mechanism exists, it may provide a clearer boundary than a separate application attempting to observe and repair the transaction afterward. This is a design question, not a universal pattern prescription.

When side by side development on BTP makes sense

A loosely coupled application may serve users across several systems, need its own user experience, or follow a different release cycle. Those characteristics can support a side-by-side design. The application should connect through supported interfaces and have an explicit contract with ERP about data, actions, and failure behavior.

Consider an illustrative customer-facing service that combines order information from ERP with information from another application. A separate experience could be reasonable if supported APIs expose the necessary business capabilities. The architecture still needs to define who owns each fact and which system is authoritative for each transaction.

SAP's learning guidance also notes that side-by-side development does not create additional extension points inside a standard application. [3] If a business requirement depends on changing behavior at a point that the standard application does not expose, moving code to BTP does not make that limitation disappear. Resolve the supported design before promising delivery.

Compare coupling rather than programming preferences

Teams often begin with the language they know best. Skills matter, but they should follow the design decision. Examine whether the extension must participate synchronously in a transaction, tolerate delayed information, combine multiple sources, or operate independently during an ERP outage.

Define the consistency requirement precisely. Does the user need an immediate accepted transaction, or can the system acknowledge a request and complete it later? What happens if ERP is available but a dependent service is not? The answers affect the architecture, user experience, and support procedures more than a broad preference for internal or external development.

Also identify where business rules will live. Duplicating the same rule across an ERP extension and a separate application creates a maintenance problem unless the relationship is intentional and controlled. Agree who changes the rule, how versions align, and how consumers know which behavior applies.

Where an extension depends on several applications, include an SAP integration review in the design scope. This helps identify interface ownership and recovery work before development is estimated.

Evaluate the extension as a service to operate

A side-by-side application needs monitoring, identity configuration, support, cost ownership, and a release process. An in-stack extension also needs tests, documentation, and change review. Include these responsibilities in the comparison so the team does not select a design based only on build effort.

Record expected demand and dependency behavior. A rarely used internal function and a customer-facing application with variable traffic can have different operating needs. Test realistic response times, failure paths, and access boundaries. Confirm that support staff can connect an application issue to the relevant business transaction without searching several unrelated logs manually.

SAP's October 2026 migration update describes custom-code assistance as part of its modernization portfolio. This creates an opportunity to investigate tooling for analysis and remediation, with the early adopter availability described in that update. Generated recommendations still require validation against the supported target design and business behavior. [4]

Use a decision record for every meaningful extension

A concise decision record should state the business purpose, available standard option, remaining gap, chosen extension pattern, supported interfaces, dependencies, owner, tests, and review conditions. Keep alternatives short but explain why the chosen approach fits. This makes future maintenance less dependent on remembering a workshop conversation.

Add an exception process for legacy constraints. Some work may require a transitional arrangement while a suitable supported path is investigated. Record the reason, consequence, approval, and expected review point. An undocumented exception tends to survive indefinitely because nobody knows whether changing it is safe.

Review the portfolio periodically. A standard feature may later meet the requirement. A business process may disappear. An interface may have a supported replacement. Clean core is sustained through these decisions over time, rather than achieved once by moving a collection of programs during a migration project.

Test for upgrade resilience with business evidence

An extension should be tested against its intended behavior and the boundaries it depends on. Include input validation, role access, failure handling, and relevant end-to-end process scenarios. If a released interface changes within its documented lifecycle, the team needs a way to identify affected consumers and verify the result.

NIST's Secure Software Development Framework provides general practices for organizing secure development work; it is not an SAP clean-core certification. Teams can use it as supporting guidance while applying SAP's product-specific development rules and their own lifecycle requirements. [5]

For the business owner, the evidence should remain understandable. Show that the differentiated behavior still works, that standard processing remains intact, and that known limitations are documented. An extension is easier to sustain when both technical and business reviewers can explain what would make the next release unacceptable.

Frequently asked questions

Does clean core mean no custom code

No. The aim is to preserve necessary business differentiation through supported, maintainable approaches. Evaluate whether standard capabilities meet the need, then choose an appropriate extension pattern and document its boundaries, tests, and ownership.

Is ABAP Cloud available only on SAP BTP

No. SAP documents ABAP Cloud across supported S/4HANA environments as well as SAP BTP ABAP environment. Availability and permitted capabilities depend on the product and release. Confirm those facts before selecting the target design.

Is every BTP extension automatically clean core

No. A BTP application can still create fragile dependencies, duplicate rules, or use unsuitable interfaces. The design needs supported integration, clear data ownership, operational responsibility, and a lifecycle approach appropriate to the business process.

Preserve differentiation with a design people can maintain

The right extension is the one that meets the justified requirement through an appropriate supported boundary. Start with the process, examine coupling, and account for the next change. That approach gives developers room to solve real problems while making the resulting landscape easier to operate.

GBSI's SAP BTP ABAP environment services can support custom-code review and extension development. Bring one important extension, its business purpose, and the target SAP release to begin a focused design discussion.