Building Lifecycle-Stable Extensions in SAP S/4HANA Cloud
Extensibility covers many topics that enable customers and partners to adapt standard business software to their business requirements. This includes changes to software behavior that go beyond the capabilities of business configuration, data model extensions, data exposure, layout changes to user interfaces (UIs) or forms and reports, and creation of new UIs or your own applications.

The architecture of SAP S/4HANA Cloud ensures that extensions made using the built-in capabilities are separated from the core business software layer, meaning that SAP can push upgrades out to all customer systems without affecting any customer-specific extensions that have been defined. Any extensions that can't be performed in the core SAP S/4HANA Cloud system using the in-app capabilities should be decoupled, or separated into a different software platform to ensure the core stays lifecycle stable. SAP Business Technology Platform (BTP) enables these de-coupled extensions because it has a huge range of capabilities for building and hosting applications and integrations.
Extensibility Technologies
Extensibility in SAP S/4HANA Cloud Private Edition can be divided into two primary categories: in-app extensibility and side-by-side extensibility.

In-App Extensibility, where customizations are made within the core application (SAP S/4HANA) in the front-end or back-end. This is further divided into two types:
- Key User Extensibility is done in the customizing tenant of the development system through SAP Fiori apps designed to facilitate someone making small changes to apps, reports, and email and form templates without any coding experience.
- Developer extensibility enables developers to create custom ABAP code and partner extensions in an upgrade-stable, cloud-ready programming model. Only released SAP objects are available to customize, which ensures your extensions will be stable through future release upgrades.
Note
Classic extensibility, where ABAP developers can make changes to any SAP objects, is still available in the development tenant of the development system. However, when developing in the Eclipse environment, there is an option to choose to develop in "ABAP for Cloud Development" (as opposed to "Standard ABAP") which enables the syntax checks that make sure a developer's code follows the rules designed to ensure the code will be stable, and if not, alternatives are recommended. Additional information will be covered in the lesson on Developer Extensibility.
Side-by-Side Extensibility, where customizations are made in a separate platform and integrated with the target application (SAP S/4HANA Cloud). Side-by-side extensibility ensures lifecycle stability of the extensions through future release upgrades because any customization you develop fundamentally lives in a different platform and simply communicates with the target application through integration(s). SAP's development platform is the SAP Business Technology Platform, and we have both low/no-code development solutions and code-based development solutions, including our two primary solutions:
- SAP Build, which customers have access to through their GROW with SAP enablement package, is low/no-code and includes Build Apps, Build Process Automation, and Build Work Zone.
- SAP Business Application Studio, which enables developers to use common languages like Java, Javascript, and Python to build and run SAP business applications using the Cloud Application Programming (CAP) model. Software Developer Kits (SDKs) are released for different use cases (e.g. Java SDK, iOS mobile SDK, android mobile SDK) to make it easier for developers to get up and running in the development landscape as quickly as possible with the latest features. An additional license is required for SAP Business Application Studio.
- Other services that support side-by-side extensibility are documented in the SAP Discovery Center.
Extensibility Decision Tree
Based on the type of extension that needs to be made, use the decision tree below to choose the correct technology.

Three-Tier Extensibility Model for Custom Developments
For system conversions, it's important to update extensions built using classical ABAP to align with today's Clean Core standards. These classical ABAP extensions are referred to as Tier 3 extensions. They do not follow the syntax rules applied to the SAP S/4HANA ABAP Cloud environment (developer extensibility), and can make a customer's system unstable and more difficult to upgrade in the future. Even though the SAP Readiness Check would have identified problematic custom code that either had to be removed or updated before the system conversion would be possible, there are still improvements that should be made to modernize the custom code after conversion. The goal is to make the customer's system as stable as possible, and to make future upgrades run smoothly.

For a customer's system, the goal is to have only Tier 1 extensions. Tier 1 refers to making in-app extensions through either the SAP Fiori apps (key user extensibility), or the ABAP Cloud development environment (developer extensibility) to build cloud-ready and upgrade-stable applications and extensions. This uses the same model as SAP S/4HANA Cloud Public Edition. Extensions built in Tier 1 will make customer systems stable and easy to upgrade, and should always be the default model for new extensions, whether in a converted SAP S/4HANA system or in a clean system for a new implementation.
Because there isn't always an exact Tier 1 extension that can replace a Tier 3 extension, there are Tier 2 extensions to bridge the gap. Tier 2 extensions enable developers to build custom wrapper objects for SAP objects that may not be released and therefore aren't available to customize with Tier 1 extensions. Once the SAP API is available for a released object in Tier 1, developers should replace the custom wrapper that was developed (Tier 2) with the newly available Tier 1 extension. Using Tier 1 or Tier 2 extensions keeps the customer's core system "clean", which enables them to more easily upgrade it in the future.
Note
- Learn more about how Clean Core applies to extensibility in this SAP Blog: SAP S/4HANA Extensibility Options for Clean Core Journey.
- Make sure to share the Extensibility Guide with developers working on the implementation project for additional information.
- Learn how to update a customer's Tier 3 extensions to Tier 1 and Tier 2 in this SAP Blog: The new ABAP Cloud API enablement guide.
SAP Extensibility Explorer
The SAP Extensibility Explorer website is a great resource to find sample scenarios and use cases, and where to find learning resources when trying to implement different extensibility scenarios.

SAP Business Accelerator Hub
After creating an extension, you'll need to integrate it into your SAP S/4HANA Cloud Private Edition target system. Find the library of prepackaged integrations, APIs, events, connectors, CDS views, workflow scenarios, SAP Build templates, and more in the SAP Business Accelerator Hub.

If you select the dedicated SAP S/4HANA Cloud Private Edition tile, you'll see only the content relevant for the solution, including extensions to be used in the ABAP Cloud landscape that supports developer extensibility. If a developer can't find the content they need, submit a request using the Feedback tab on the right side of the screen, then choose the relevant Customer Influence campaign to describe the content request.