Skip to Content
Technical Articles
Author's profile photo Jeetendra Kapase

SAP S/4HANA Extensibility Options For Clean Core Journey

Experts, before getting into the topic, let’s understand the motivation and purpose of the new modern extensibility options defined by the SAP for SAP S/4HANA Public, On-premise, and PCE editions.


A cloud-first approach is becoming the new normal powered by software-as-a-service (SaaS) applications with AI/ML, digital assistants, automating routine tasks, better user experience, flexible and agile operating model. SAP is bringing innovation into the core ERP business processes with frequent product release updates. SAP is also providing freedom to go beyond standard ABAP language with a BTP side-by-side extensibility approach using BTP ABAP Cloud, Java, node.js, BYOL, etc. to build full-stack applications which will run in parallel with ERP which is challenging with the classic extension options. The extensibility option is a key capability of an ERP application that enables customers to customize their business processes with a competitive advantage in the industry and allows partners to enrich ERP with tailor-made solutions. The importance of extensibility has been confirmed by the legacy ERP flagship product SAP ECC and will remain valid for the current and future cloud ERP transformation.

SAP S/4HANA is a front-runner product providing intelligent ERP in the cloud and on-premise. The goal is to shift from the classic ABAP extensibility model to an SAP S/4HANA modern extensibility model that allows customers to consume SAP innovations, building future-proof extensions that are ready for the cloud ERP. For all, it is important to understand and know how SAP is shifting away from a monolithic architecture (SAP ECC era) to a microservices architecture that is modular, flexible, continuous deployment, and agile (SAP S/4HANA era with BTP).

There is chaos in the developer’s community, how do we connect the dots for customers that are on traditional ABAP so they can take advantage of modern innovations? What is a new extension model? What is Embedded Steampunk, BTP ABAP environment? SAP CAP (Java, node.js)?  What is Side-by-side BTP Extension? How it is different from standard ABAP?  Where can we use SAP Build Apps with ERP?  And more questions.


  1. Current customer situation
  2. Challenges with the classic extensibility model
  3. What are the extensions?
  4. Why does SAP S/4HANA need extensibility?
  5. What and why about the clean core concept?
  6. What is the new extensibility model?
  7. SAP S/4HANA Extensibility Options
    1. Key User (In-app) Extensibility
    2. On-stack Developer Extensibility
    3. Side-by-side Extensibility
    4. Classic Extensibility
  8. 3-tier extensibility model for SAP S/4HANA On-premise and PCE editions
  9. How to handle Classic Custom Code Migration?
  10. Decision Matrix for Extensibility Options

Current customer situation

Our business is doing fine with the classic ABAP extensions. We have spent a huge amount of effort in building the custom processes as per the business demands. Our system has become complex over time due to customizations and enhancements. Classic extensibility is extremely powerful and flexible to meet every single requirement of the business and keep them happy regardless of the system that has become over time inefficacious and substandard performance. We are facing challenges in terms of high maintenance IT cost and lack of innovation. Our goal is to become Intelligent Enterprise with digital ERP transformation. Reduce the costs, modernize to keep up with the competition, and bring value from our operational data.

Challenges with the classic extensibility model

  1. High TCO for system maintenance and software upgrades.
    • Extensive planning and testing. Making sure the upgrade does not break the system.
    • Software changes lead to high adoption efforts.
    • SAP Standard code and Customization are not clearly separated, there is no interface.
    • Classic extensibility adds complexity to the SAP Core and averts from adoption of agile practices and standardized business processes.
    • Redundant data and unused custom code living within the core ERP system.
    • Example: You have used an SAP object that is not whitelisted by SAP in your extension. After an upgrade, the used SAP object has been changed or deleted. Now you will have to adjust the extension thus upgrade is delayed and the speed of innovation is decreased.
  2. The slow rate of innovation as the system was modified via standard and custom codes.
  3. Limitations and struggle to reach the fast-changing business needs to compete and lead.

What are the extensions?

  • Software engineering principle for enhancements without impairing existing system functions.
  • It can be the addition of new functionality or modification of existing functionality.
  • Measure the ability to extend and the effort required to implement an extension.

Why does SAP S/4HANA ERP need extensibility?

  • Extend business process for optimization, innovation, or automation
  • Extend the UX of existing processes and provide controlled access for external user groups
  • Extend data insights & analytics  by combining data in one central place
  • Extend the ecosystem with side-by-side Software as a Service (SaaS) apps


ERP Extensibility

What and why about the clean core concept?

Let’s understand the meaning behind the Clean + Core.

Clean… up-to-date, transparent, unmodified, consistent, efficient, and cloud compliant.
Core… the main aspects of an ERP system are extensibility, processes, data, and integration.

The clean core is an extension methodology concept with the basic goal i.e.  Extensions should not break an upgrade and upgrades should not break an extension. Follow the rules:

  1. Fit-to-Standard: Leverage SAP standard processes when possible.
  2. Apply a zero-modification policy from the project’s first day.
  3. Leverage the full potential of new extension options (In-App, Developer, or Side-by-Side ) which fit your needs best.​Use whitelisted and released APIs.​
  4. Eliminate enhancements that are redundant to standard code and functionality, as well as “clones” of standard code.​
  5. Think and act like moving SAP S/4HANA on-Premise to SAP S/4HANA Cloud by
    using capabilities of SAP BTP Extension & Integration Suites for application development and integration.

Some principles when building extensions to keep the core clean.


How to plan and adopt a clean core strategy for an SAP S/4HANA ERP transformation project?

  • Greenfield project: Start with the stay clean strategy to bring system the system closer to standard processes, and keep the system up-to-date, including modern extensibility and integration options as well as data governance.
  • Brownfield project: Start with the get and keep clean strategy to bring system the system closer to standard processes, including the transformation from traditional custom code to modern extensibility, integration capabilities, and duplicate data cleansing.

Understood! Tell me the benefits of it:

  1. Reduce TCO (Time, Effort & Cost)
    • Faster deployment and Ready for a smooth upgrade.
    • Reduce test efforts for business users and Adoption efforts for developers.​
    • IT service providers can offer upgrade projects at a fixed price.
    • No costly maintenance for unused artifacts and data.​
  2. Innovation at Market Speed.
    • Captivate innovation delivered by SAP.
    • React fast to changing business requirements.
  3. Data to value.
    • Consistent data allows for reliable forecasting and predictions for confident decisions.
  4. Become cloud-ready and Competitive at any point in time.
    • Moving SAP S/4HANA on-Premise to SAP S/4HANA Cloud.

Learn more, Get your organization in shape: Keep a Clean Core with SAP Business Technology Platform.

Now you have clarity clean core concept and benefits. Let’s get into the main topic.

What is the new extensibility model?

This new SAP S/4HANA Cloud extensibility model, first introduced in SAP S/4HANA Cloud public edition, is now available and recommended in all SAP S/4HANA editions, to achieve the following:

  • Smoother upgrades.
  • Little to no testing efforts.
  • Simplified adoption and LOBs drive innovation timelines.
  • Standardized and optimized business processes.
  • Pave the way to the cloud.

Let’s understand the various new options/tools available to create stable extensions in the SAP S/4HANA ERP system by following the clean core principle, even when the classic extensibility model is still available for the on-premise, private editions and recommendations are NOT to adopt it.

SAP S/4HANA Extensibility Model Options


SAP S/4HANA New Extensibility Model Options

The new extensibility model in SAP S/4HANA can be divided into three parts:

  1. Key User Extensibility in the SAP S/4HANA Core
  2. Developer Extensibility in the SAP S/4HANA Stack
  3. Side-By-Side Extensibility on the SAP Business Technology Platform

1. Key User (In-app) Extensibility

SAP Fiori extensibility apps(tools) help you to customize user interfaces, processes, email templates, or forms using a low-code/no-code(LCNC) paradigm. It empowers business experts or citizen developers (typically a user from the business department) to add extensions to SAP solutions without the need to dive deeply into the implementation details. They typically have deep knowledge of business processes and configuration with no or only limited coding or debugging skills. Some development skills are recommended for developing custom business objects and adding business logic using the cloud ABAP web editor.

Scenario Simple low-code/no-code tool features for the S/4HANA extension
  • UI adoption for screen layouts such as moving/hiding fields and field groups, changing labels, etc, custom forms, and templates
  • Custom CDS views and analytical apps.
  • Custom business objects with minimal coding effort.
  • Custom fields to standard business objects. The custom field is then available in the entire application stack (from the UI to the database tables or for developer extensibility).
  • Custom business logic using Cloud BADIs
  • Add custom fields to a process group (e.g., from sales quotation and sales order to delivery and invoice) to provide consistent end-to-end extensibility.
  • Copy and adapt print and email form templates.
  • The adaptations made by a key user are registered in transport requests for propagation into QA and PRD systems.
  • Fully managed and tightly integrated into the SAP S/4HANA stack.
  • No or only very basic development skills required
User Personas Business expert, implementation consultant, citizen developer, key user
Tools Extensibility Fiori Apps, ABAP web editor
Clean Core Index High
Learn More

The main argument for using key user extensibility is that simple extensions can be realized quicker than with developer extensibility because of the communication overhead between the business expert (responsible for the specification of the extension, and later for testing and approval) and the developer (responsible for development and developer test) is avoided.

Find other Key User Extensibility apps:

  1. Go to the SAP Fiori apps reference library
  2. Search for the title of the app you want to configure
  3. Choose your product (S/HANA Cloud or S/4HANA)
  4. Change to the tab Implementation


Key user Extensibility Pattern Architecture


Key User Extensibility Tools

2. On-stack Developer Extensibility

This option bridges the gap between the key user and side-by-side extensibility options. On-stack developer extensibility enables you to develop custom ABAP code, and partner extension developments requiring coupling with SAP S/4HANA data, transactions, or apps using a restricted ABAP version. The requirements of the extension project go beyond the scope of key user extensions.

Custom ABAP development projects that need tight coupling to SAP S/4HANA data, transactions, or apps that require full access to development capabilities like debugging, refactoring support, version control, etc.
  • ABAP-based custom apps and extensions that are developed with a new cloud-ready ABAP RAP model on released APIs.
  • Custom applications with SQL access to SAP S/4HANA data cannot be realized by side-by-side or data replication.
  • Custom extensions running in the same logical unit of work (LUW) as SAP applications
  • Custom remote APIs or services for side-by-side SAP BTP apps
  • SAPUI5 Adaptation Project to extend the SAP Fiori application
  • Full access to development capabilities inside the S/4HANA stack.
  • No remote access or data replication.
  • Use and extend released SAP S/4HANA objects.
User Personas ABAP developer, Fiori (UI5) developer
Tools Eclipse-based IDE (ABAP Development Tools)
SAP Business Application Studio (SAPUI5 Adaptation Project)
Clean Core Index High
Learn More
  • Eclipse-based IDE (ABAP Development Tools) with a debugger, troubleshooting, and testing tool support
  • A cloud-optimized subset of ABAP language i.e. ABAP Cloud syntax.
  • ABAP RESTful Application Programming model (RAP) to build upgrade-safe extensions inside your core ERP system.
  • Only use released APIs and the stricter syntax check of ABAP Cloud. (Note that to fully utilize this you need to be on a recent version of S/4HANA >= 2022 though it’s still possible to follow this system with older releases.)

In contrast to side-by-side extensions, on-stack developer, and key user extensions are developed and run on the same software stack as the underlying SAP S/4HANA system. This allows extensions to direct access SAP S/4HANA logic and data via SAP extension points(BAdis), local public CDS views, SAP-released APIs, or SQL queries.


Developer Extensibility Pattern Architecture

ABAP cloud development in the private cloud and on-premise editions of SAP S/4HANA​
  1. Switch from classic ABAP extensibility (standard ABAP) to ABAP for cloud development for a development object or package
  2. Inspect the “Release state” for used APIs and objects
  3. The ABAP cloud development model ensures that only released local APIs of the underlying ABAP Platform can be used.


ABAP for Cloud Development

Developer Adaptation Project

SAPUI5 Adaptation Project allows developers (typically a user from the IT department) to extend the SAP Fiori application in SAP Business Application Studio. Developer adaptations are modification-free, upgrade-safe, and can extend standard apps without needing pre-defined extension points.SAPUI5 Adaptation Project lets you create an app variant for an existing SAP Fiori elements-based application or freestyle application, on SAP S/4HANA on-premise ABAP system or the Cloud Foundry environment and provides extension capabilities for UI5 controls.
UI adaption requirements can be covered by either key user or developer project adaptation, it is up to you to decide. Using key user adaptation of course has the advantage that it is a no-code environment, easy to use for business experts and it comes without the need to set up an IT project in the BAS. Hence most customers choose to use key user adaptation as much as possible. Learn more about when to use adaptation projects and use cases.

Adaptation projects are currently only supported on the S/4 HANA on-premise ABAP system or the Cloud Foundry environment, for the S/4HANA cloud it may be supported in the future, refer to the product roadmap for more details. SAP S/4HANA cloud extensibility explorer.

3. Side-by-side Extensibility

Extensions running on the separated (side-by-side) SAP Business Technology Platform (SAP BTP) for all other loosely-coupled extension scenarios integrating with the extended SAP S/4HANA system. This model is the preferred option for developing loosely coupled but seamlessly integrated extensions to SAP S/4HANA data, transactions, or apps.

Loosely-coupled extensions, process automation, and applications, such as partner SaaS solutions or custom applications targeting a different end-user group.
  • Proxy applications for a separate target group (no ERP users)
  • Convenience application workload that shall run separated from ERP
  • A custom application that will run in parallel with ERP reducing the load on the operational system.
  • Custom applications needing proximity to intelligent SAP BTP services like machine learning, AI, etc.
  • Substitute apps integrating with several ERP and cloud services
  • Partners want to provide a SaaS solution and therefore need to operate their service independently of the SAP S/4HANA system.s
  • ABAP and non-ABAP (Java, Node.js, etc.) developments
  • Extend UI application using a no-code application like SAP Build Apps
  • ERP Workflow and business process automation
  • Pre/Post processing applications for S/4HANA system.
  • Analytical applications.
  • Decoupled extensions and developments which are independent of SAP S/4HANA operation and run independently.
  • Independent lifecycle management.
  • Choose to use ABAP or non-ABAP (Java, Node.js) development.
User Personas ABAP developer, BTP full-stack developer, Citizen developer
                   – Eclipse-based IDE (ABAP Development Tools)
                   – SAP Business Application Studio
                   -SAP Build Apps
                   -SAP Build Process Automation
                   -SAP Build Work Zone  
Clean Core Index Medium
Learn More

Develop custom code side-by-side extension and SaaS solutions using ABAP RESTful Application Programming Model (RAP) and SAP Cloud Application Programming Model using Java, or Node.js. Use no-code/low-code applications like SAP Build Apps, Process Automation, and Build Workzone to build custom applications, process automation, and workflow management. One main difference compared to the on-stack extensibility model is that accessing business objects of SAP S/4HANA Cloud is only possible using remote APIs which are published in the SAP API Hub.


Side-by-side Extensibility Pattern Architecture


ABAP RESTful Application Programming Model (RAP)

New ABAP programming model for efficiently building cloud-ready enterprise apps and upgrade-stable extensions on SAP BTP ABAP environment, SAP S/4HANA Cloud, SAP S/4HANA Cloud ABAP environment, and SAP S/4HANA 1909 and higher.

  • RAP is a powerful framework consisting of a set of concepts, tools, and languages.
  • A strategic long-term solution for the ABAP developments.
  • Help developers to build innovative, cloud-ready, enterprise applications of different domains, such as transactional and analytical applications.
  • RAP offers a standardized development flow based on Core Data Services (CDS), the ABAP language, and business services in the modern, Eclipse-based ABAP Development Tools (ADT).
  • RAP is available on
    • SAP BTP ABAP Environment (Steampunk), provides the ABAP platform as a service (PaaS) on SAP BTP. ABAP-minded customers and partners can reuse their ABAP skillset to build new cloud solutions, or to transform already existing on-premise ABAP assets to the cloud.
    • SAP S/4HANA ABAP Environment (Embedded Steampunk)


High-level RAP Programming Model

SAP Cloud Application Programming Model(CAP)

An open and opinionated framework of languages, libraries, and tools for building enterprise-grade services and applications. The CAP framework features a mix of broadly adopted open-source and SAP technologies

  • CDS is the backbone of the SAP Cloud Application Programming Model (CAP) to build data models, defining the UI layer with those definitions (annotations)  and service definitions on a conceptual level.
  • CAP-based projects benefit from a primary focus on the domain rather than delving into overly technical disciplines.
  • SAP programming model is compatible with any development environment, but recommend using the SAP Business Application Studio.


High-level CAP Programming Model

SAP CAP Vs RAP model, which one to choose? The choice of the programming language for your extension – ABAP, Java, or JavaScript is decisive.

Common ABAP RAP  Model SAP CAP Model
• RESTful OData services
• Core data services (CDS)
• Built-in extensibility capabilities, enabling users to extend both SAP Cloud Application Programming Model and ABAP RESTful application programming model in a similar way as with the
key user (in-app) extensibility of SAP S/4HANA
• ABAP programming language
• Git-enabled lifecycle management
• Offers a service consumption model for easy remote OData service calls
• Enables the possibility to reuse selected custom code in the cloud with SAP BTP, and ABAP environment, while rebuilding the UI and backend access
• Eclipse IDE
• Supports Java or JavaScript (node.js)
• Enables applications originally written as a single-tenant applications to be turned into multitenant ones through configuration
• Leverages event-based communication using the SAP Event Mesh capability
• Wraps the REST service calls to the underlying back-end system to Java or JavaScript functions using SAP Cloud SDK


SAP Build Apps

Evolution of SAP AppGyver is a professional application development solution designed for anyone to quickly create apps without code regardless of role or skill level.

  • Build Full-Stack Enterprise-Apps in Minutes – Absolutely Zero Coding Required
  • Drag-and-drop the user interface and Create any logic without code.
  • With SAP Build Apps everyone can become a full-stack cloud developer.
  • Easily add your own data integrations or get started with some of ours.
  • Users can design both mobile and web applications with a pixel-perfect design using the drag-and-drop functionality and a rich component library.

Note: SAP Build Apps is still evolving and due to limitations on the availability of different hyper scalers, other low code and pro code solutions become equally important.

SAP Build Process Automation

A citizen developer solution to automate workflow processes and tasks without writing code.
  • Users can create forms, manage decision logic, and build, adapt, and organize process flows with drag-and-drop simplicity.
  • Automate repetitive manual tasks – such as copy-and-paste operations, data extraction, data entry, and data creation – using no-code and low-code capabilities or the built-in automation recorder.
  • Built-in AI capabilities enable intelligent document processing –like extracting data from structured or unstructured documents to transfer it to your enterprise systems for processing – without needing data scientist support.
  • Simplifies process and task automation so business users can unleash their process expertise without writing code.
  • Adapt, improve, and innovate business processes with no-code workflow management and robotic process automation capabilities.

SAP Build Work Zone

Enables non-technical professionals to navigate complex enterprise technology systems, landscapes, and tools. With drag-and-drop and customization tools to create portals, intranets, and workspaces, you can bring together all types of content, UI tools, IT systems, content repositories, applications, and channels.
  • Users can create beautiful, custom business sites for themselves, colleagues, suppliers, customers, partners, etc., without writing any code.
  • Business sites created with SAP Build Work Zone provide central access to relevant applications, processes, and information.
  • Maximize productivity by enabling guided experiences and knowledge sharing.
​The three extensibility options are not isolated from each other. In many scenarios they are combined, for example, developing a side-by-side application in conjunction with a thin on-stack extensibility layer that offers more suitable remote APIs to access the SAP S/4HANA Cloud functionality.

4. Classic Extensibility (Not available in SAP S/4HANA public edition)

This is the traditional way of the SAP ECC or S/4HANA on-prem enhancement for RICEFW ABAP custom object development like user-exits, customer-exits, classic BAdis, implicit/explicit enhancements, BTE, module-pool, etc using transaction code SE38, SE80, SE11 (SAP GUI, Eclipse ADT).

Scenario Requirements that are critical for lifecycle management or business operations and NOT possible using 3 modern extensibility options(Key user, developer, or side-by-side)
  • Non-released BAdis, classic user exits business-critical logic.
  • Lastly, anything that is not possible to accomplish using modern extensibility options for must-have type business application requirements.
  • Extremely powerful and flexible.
  • No restriction on the extension model.
User Personas ABAP developer
Tools SAP GUI – Tcodes
Eclipse-based IDE (ABAP Development Tools)
Clean Core Index Low
Learn more

Basically using non-released objects from S/4HANA and an ABAP standard version (non-restricted). No restriction on the extension, it even allows you to modify the standard SAP code itself. Hence, upgrade effort increases and agility/innovation speed decreases.


Classic Extensibility Pattern Architecture


In S/4HANA On-Premise –The classical extensibility option is available but not recommended.

Available extensibility options for SAP S/4HANA editions

Key user, developer, and side-by-side extensibility are available for public and on-premise editions while the classic extensibility model is available only for an on-premise edition.



3-tier extensibility model for SAP S/4HANA On-premise and PCE editions



3-tier extensibility model

How to handle Classic Custom Code migration?

This is the most important step for customers who have been using classic extensibility with the standard ABAP. For them, it’s a two-fold process:
  1. Analyze the classic ABAP custom code with the Custom Code Migration App to estimate the impact. Custom Code Analysis for SAP S/4HANA with SAP Fiori App Custom Code Migration
  2. Detect and Retire unused classic ABAP custom code. In the analysis, it is found that roughly 60% (sometimes even more) of the code is not used productively in a typical ERP system. Removing obsolete code significantly reduces the effort for custom code adaptation. At the same time, this is certainly a first step toward a clean digital core.

Learn more: ABAP Testing and Analysis

ABAP Cloud Use Cases – Overview and Recommendations

Refer official guide: ABAP Cloud – Technical Use Cases and Recommended Technologies


Classic RICEFW Vs Modern Extensibility With BTP

Classic RICEFW Modern Technology/Extensibility
Reports •SAP Fiori Analytical Apps
•SAP Custom Fiori Apps
•Decoupled from the core on BTP using released APIs, Integration Suite
•SAP Analytics Cloud
Interfaces • Extension of standard OData services or creation of new ones based on custom core data services (CDS) views with SAP S/4HANA key user (in-app) extensibility
• SAP Integration Suite
SAP Application Interface Framework tool (part of SAP S/4HANA)
• Event brokering using SAP Event Mesh
Enhancements •Custom business logic with SAP S/4HANA in-app extensibility and Developer Extensibility
•BTP Cloud Foundry Runtime, Event Mesh – Business Events / Workflow
Custom Tables •Custom business objects with generated UI with SAP S/4HANA in-app extensibility and Embedded ABAP
Modifications •Key user (in-app) extensibility in SAP S/4HANA covers a wide range of business requirements for UI adaptation and business logic.
•On-stack Developer Extensibility
•Developer Adaptation Project
Conversions SAP S/4HANA migration cockpit to load data
Forms • SAP S/4HANA output management: custom forms with Adobe LiveCycle Designer with OData as a data source
Forms as Service on BTP
Workflows SAP S/4HANA flexible workflow
•SAP Build Apps.
User Interface •SAP Mobile Services, SAP Build Work zone.
•SAP Fiori, UI5
Data-Marts • Embedded BW with CDS views, Table Functions, and AMDP or SAP Datasphere, BW/4HANA, HANA cloud
Machine Learning •Embedded ML based on SAP Analytics cloud.
•Side-by-Side ML is used for Complex ML scenarios based on the SAP BTP (Data Intelligence, SAP HANA PAL, AI Business Services, AI Core).
Intelligent Scenario Lifecycle Management (ISLM) scenarios in SAP S/4HANA


Decision Matrix for Extensibility Options


Requirements Key User Extension On-Stack Extension Classic Extension Side-by-side Extension
Users & UX Involve consumers of the corporate products and services (B2C) (for example, service orders, master data self-services, catalogs, Webshops, mobile access)       X
Involve business partners (B2B) to enable direct collaboration (for example, order review and approval, service or good receipt, quality control, and delivery checkpoints). Purchase order approval workflow.
Involve employees (B2E) who otherwise have no access to the business solution (for example, outsourced workers, leased workers, mobile workers)       X
SaaS solution, that integrates it to SAP and third-party on-premise, cloud, and hybrid products based on standard and custom APIs.       X
Adapt existing UIs based on the SAP Fiori UX – Add, hide, move, or regroup fields on the screen, add custom fields, and change label texts.       X
Improve UX by redesigning the UI for existing applications (for example, simplifying data-entry screens, dropping screens that are not required, auto-filling fields, and enabling speech-to-text, translation, and localization functionality)       X
Open-source components and freestyle UI (non-SAPUI5/SAP Fiori)       X
Mobile native capabilities (for example, access to the microphone, camera, GEO location, and so on)       X
Data / Process An extension to a standard business process or an application with an
extensive use of data in SAP S/4HANA
      X       *X
Stand-alone application based on own data model with occasional
consumption of standard data in SAP S/4HANA
      X       X
Extensions that store custom data in the same logical unit of work as the extended SAP S/4HANA app       X
Analytical Key User Use Cases       X
Analytical application consuming standard and custom data residing in SAP S/4HANA       X
Analytical application consuming data distributed across multiple SAP and third-party systems (for example, data lake)       X
Transactional data consistency – Custom data changed in a single database transaction with core data in the back end       X       X       *X
Non-released BAdis, classic user exits business-critical logic or Anything that is not possible to accomplish using modern extensibility options for must-have type business application requirements in the ERP core.       *X
Features Agility and independence on the back-end lifecycle       X
Reactive (event-based) process extensions and custom workflows       X
Use of SAP and third-party cloud services (for example, machine learning solutions from SAP, SAP Localization Hub services, tax services, Google Maps, and so on)       X
Application with unpredictable or largely varying usage and resource consumption (scalability and elasticity)       X
*X – Not applicable for S/4HANA Public Cloud

The clean core is a journey to be agile, reliable, and more efficient. You can not just switch it on overnight. 😉

Questions?, Please use the blog comment feature or reach out to me on Linkedin.


  • SAP S/4HANA provides a new extensibility model that clearly separates standard and custom developments.
  • The classic extensibility option is not available for SAP S/4HANA public edition.
  • A clean core strategy is important for customers to consider while extending an ERP application and be ready to consume product updates and innovations.
  • Key-user extension is a great tool for business users without the need for IT support.
  • Side-by-Side is an extensibility model that provides freedom to choose ABAP, Java, Node.js, etc., and build a full-stack application that will run in parallel with core ERP processes.
  • An embedded ABAP environment offers values for both greenfield and brownfield projects.
  • Retire unused code, Custom code migration and developments with modern cloud ABAP is a go-forward strategy to become cloud competent, modularized, and agile for business needs.


  1. SAP Business Technology Platform ABAP Environment – Solution Overview
  2. Extend SAP S/4HANA in the cloud and on premise with ABAP based extensions
  3. Developing on ABAP Platform – Extensibility
  4. SAP Extensibility Explorer for SAP S/4HANA Cloud
  5. Custom Extensions in SAP S/4HANA Implementations – A Practical Guide for Senior IT Leadership


Credits: This blog has been put together by combining the incredible efforts, suggestions, and feedback from the ABAP platform PM team (Olga Dolinskaja), CoE expert (Subit Benny), and Solution advisory expert (Ruhi Naaz Quadari) when deciding on the extensibility of S/4HANA using the Clean Core concepts.



Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Former Member
      Former Member

      Great blog Jeetendra Kapase

      Author's profile photo Abraham MD
      Abraham MD

      Hi Jeetendra Kapase - It is excellent blog. I have some clarifications. Is the ABAP cloud programming in the on-stack approach and side by side same? You mentioned they are different. But what we know is there are two versions of ABAP. One is classical version and another ABAP cloud. Then how they differ? Another question is, the difference between on-stack and classical is that classical ABAP doesn't use RAP model. Is that true?

      Author's profile photo Jeetendra Kapase
      Jeetendra Kapase
      Blog Post Author

      Thank you Abraham. Please find the below response.

      Is the ABAP cloud programming in the on-stack approach and side by side same?

      Yes, it's an ABAP for cloud development,on-stack is ABAP Environment( embedded steampunk) while side-by-side is BTP ABAP environment (steampunk). Side-by-side developments can also be performed using non-ABAP languages or run-time, like JAVA, Node.js using the CAP programming model on BTP

      One is classical version and another ABAP cloud. Then how they differ?

      ABAP Cloud is a cloud-optimized language to build cloud-ready business apps, services, and extensions. The development environment is Eclipse with ADT (NO SAP GUIs, TCODEs). It does not allow SELECT on standard table e.g.  MARA, instead use CDS view I_Product, CALL FUNCTION is not allowed. only released public/local APIs. Modifications of SAP object not allowed e.g. Includes with USEREXIT* forms. Instead, use released BADIs and implement them. ABAP RAP programming model which is cloud-ready development syntax.

      While classic/Standard is the traditional way - SAP GUI with SE38, SE11, SE80, User exits, modifications...


      the difference between on-stack and classical is that classical ABAP doesn't use RAP model. Is that true?

      Yes, to use RAP with ABAP cloud switch ABAP language version as ABAP for Cloud Development in Eclipse ADT. Classical means standard ABAP syntax.

      Refer for more details on ABAP Cloud RAP:


      Author's profile photo andreas hartl
      andreas hartl

      Very nice Blog!

      Author's profile photo Iver van de Zand
      Iver van de Zand

      what a brilliant blog Jeetendra Kapase

      Author's profile photo Shantanu Sharma
      Shantanu Sharma

      Very comprehensive blog. Thank for taking the time and effort to write. I will be sharing it with my customers whenever I have an extensibility related conversation with them.

      Author's profile photo Chad He
      Chad He

      Really a nice summary blog about sap extension, thanks for your effort.

      Author's profile photo Tuncay Karaca
      Tuncay Karaca

      Jeetendra, great blog and summary from references for "SAP S/4HANA Extensibility Options for Clean Core", thank you!

      Author's profile photo Amey Suresh Mogare
      Amey Suresh Mogare

      Nice blog Jeetendra! 🙂

      I attended BTP Customer Success Day in Prague last week. One of my favorite SAP senior expert "Juergen Mahler", after his fantastic break out session "keep the core clean", mentioned that there will be an official statement/blog/clarity from SAP directly, soon, as this statement is often (mis)/(partially)interpreted by most of the teams.

      Your blog also helps in this direction!

      Author's profile photo Marco Beier
      Marco Beier

      Woah! What an awesome blog post. Use cases, decision matrix, detailed information and all! Very well written (+formatted :P) and highly appreciated! 🙂

      Author's profile photo Melissa Itoh
      Melissa Itoh

      Thank you, Jeetendra!!  I've been looking for a summary of this information and found bits and pieces all over, but this is the most comprehensive write-up and reference I've seen in one place.  Very much appreciate the time and effort it took to do this.

      Author's profile photo Maximilien Fourmy
      Maximilien Fourmy

      Thank you for this highly comprehensive and detailed blog post, it's very helpful !

      In the context of Clean Core, I was wondering if there is a recommendation for custom maintenance views?
      (SM30, BRF+, Custom business objects with generated UI?)
      Author's profile photo Jeetendra Kapase
      Jeetendra Kapase
      Blog Post Author
      Two options are available for business configuration (BC) or Maintenance views apps
      1. SAP GUI-based Tcodes - SM30, SE54, etc.
      2. SAP Fiori/RAP model-based apps with Wizard option
      Now in BTP ABAP, S/4HANA public edition you only have option 2 as SAP GUI is not supported. While for the on-prem/private edition, customers can take a call and decide.

      For further details please refer to section 4.5 Business Configuration (BC)

      Author's profile photo Muskan Saksena
      Muskan Saksena

      Really nice blog!

      Author's profile photo Alfonso Millán
      Alfonso Millán

      That's very nice blog! 🙂

      Author's profile photo Juwin Pallipat Thomas
      Juwin Pallipat Thomas

      When I started my ABAP career, there were just couple of options to enhance standard SAP logic: User-Exits and BADIs. One of the first rules that I learnt in my career was not to copy/clone/edit standard code.

      User-Exits/BADIs and Standard Code modifications were 2 very distinct types of development and hence, I couldn't understand why you have clubbed them both under the "Classic Extensibility" umbrella.

      Standard code modifications and cloning have been considered a bad practices at every client I had worked with and is not a new knowledge.

      After a few years in my career, SAP introduced the concept of Enhancement-Points and Enhancement-Sections. Enhancement-Points allowed to add new custom logic, without modifying the standard code and Enhancement-Sections allowed to replace some of the standard logic. Again, Enhancement-Sections were considered a bad practice since it replaced standard logic. Enhancement-Points also were scrutinized during code-review since it could alter the flow of the standard logic. Implicit Enhancement-Points were scrutinized even-more further during the review sessions.

      All this while, there was a concept of registering the standard SAP program to receive a license key, to allow the customers to modify the standard code. There were limited team members in the organization who had access to register the object and receive the keys. Hence, there was some control/approval on modifying standard objects. When S/4HANA came along, SAP removed the need for registering the objects. This gave developers even more power to alter standard code. I have seen customers, who didn't even bother to do the most simple tasks from then on. [e.g. modify standard VOFM routines, instead of creating a new one]

      Now, reading on the blogs about clean-core, SAP seems to be saying customers have messed up their SAP systems with many customizations, that an upgrade can break them all. Hence, upgrades are now costly.

      No doubt about it. But, I feel, SAP should take a little bit of blame in this situation too.

      Author's profile photo Jeetendra Kapase
      Jeetendra Kapase
      Blog Post Author

      Classic extensibility includes everything we do with SAP GUI, Tcodes - SE80, SE24, SE38, SE11, etc - User exits, BAdis, VOFM routines, Modifications, etc.

      The new extensibility model also includes BAdis however those are released and upgrade stable. If the customer finds a BAdi which is not been released, it is still a good choice to use and in the future replace it with the released one.

      With Predefined User-exits code hooks are stable and usually do not lead to issues during upgrades. In the future, as per the current plan, this will get replaced with BAdi.

      With a clean core, SAP is setting up a clear path and how to standardize the ERP extension process and how to extend ERP with a clear separation between standard code and custom code using modern extensibility options. This is beneficial for the customer if they adopt in the right manner to get SAP innovation at speed and lower TCO.

      In the cloud era change is constant and SAP wants customers to get the advantage with the release updates - process simplification, optimization, and better user experience. with new extensibility, SAP is providing freedom to go beyond ABAP with side-by-side extensibility using Java, node.js, etc. to build full-stack applications which will run in parallel with ERP which was challenging with the classic extension options.

      I can assure you that we (SAP) are always available to be with the customer and make them successful.

      Author's profile photo Pascal Renet
      Pascal Renet

      This is an awesome summary. Thank you Jeetendra Kapase .

      Author's profile photo Linda Peruzzi
      Linda Peruzzi

      Excellent Blog and Guidance

      Author's profile photo Stefan Ressing
      Stefan Ressing

      Great blog and I will use it with my customers. Thank you Jeetendra Kapase

      Author's profile photo A. Kulkarni
      A. Kulkarni

      Brilliant blog! I respect the time spent to make all of this information available in one place. Even for big corporations, achieving just this can be daunting as the relevant information is not necessarily available in one place, despite having large teams with skilled people. This blog is extremely helpful even if the organization has already built a strategy around Extensibility and wants to be sure that it is correct as well as current. Thanks a lot, Jeetendra Kapase.

      Author's profile photo Navneet Ahlawat
      Navneet Ahlawat

      Hi Jeetendra,

      Thanks for this wonderful blog and guidance. It is very helpful as it gives Complete information in one blog with all the required links.

      One question though where clarification is needed -

      It is understood that Developer extensibility is only available in a 3-system S/4 Public landscape.

      So in 2 Tier S/4 public Landscape, Side by Side extensibility will still work and it will provide us Eclipse-based IDE (ABAP Development Tools) and SAP Business Application Studio tools?


      Author's profile photo Jeetendra Kapase
      Jeetendra Kapase
      Blog Post Author

      Yes, Navneet.

      3-tier or 2-tier landscape: Side-by-side extensibility can be achieved with BTP ABAP environment (Eclipse IDE), Node.js, and Java(SAP Business Application Studio IDE ).

      Author's profile photo Julian Phillips
      Julian Phillips

      I can only echo others and say - Great blog!

      Extensibility and moving towards a clean core is really THE KEY CHALLENGE for every SAP customer that has developed custom code. This blog goes a long way into explaining the best practice and when to use them - so top marks for that.

      I think what we are missing now is really some good guides on how to clean up the classical situations. I plan to blog around this myself.

      Thanks for a really interesting read.


      Author's profile photo Jeetendra Kapase
      Jeetendra Kapase
      Blog Post Author

      That's a great idea. I also recommend reviewing the official technical document, this covers a topic based on the usecase

      Author's profile photo Pierre COL
      Pierre COL

      This is a very good guide on APAB Cloud extensibility, indeed.

      I am part of a team working on a new and broader  SAP BTP Extensibility Guide for S/4HANA that will be published later this year, covering all of the topics mentioned in this excellent blog post.

      Author's profile photo Julian Phillips
      Julian Phillips

      Thanks Jeetendra for the link, I shall put some study time into that!

      Author's profile photo David Lees
      David Lees

      Great blog - thanks Jeetendra. I have one question though. Why do you rate Side-by-Side extensibility only "Medium" from a Clean core perspective compared to On-Stack as "High"?

      Author's profile photo Jeetendra Kapase
      Jeetendra Kapase
      Blog Post Author

      Hi David,

      Great question. Even I put my thought process and experience before the clean core rating as Medium (Side-by-side extensibility) vs High(On-stack extensibility).

      On-stack is rated High as extension capability is available on the same system/stack using locally released objects (CDS views, BAdis, etc.) There is no dependency on the side-by-side system integration or testing check post-core system update (one system upgrade).

      While Side-by-side is rated Medium as the extension is not implemented on the same stack/system, however, you still need to make sure only released APIs are consumed to build custom apps on the side-by-side system ( BTP ABAP, BAS with HANA Cloud, etc.). There is dependency on the side-by-side system integration or testing check post-core system update (possible two system upgrades - Core and Side-by-side separately). It's recommended to have core process extensions on the same stack while applications for external SaaS access, BTP services integration, Advance analytics, etc. with a side-by-side approach. Again there is a very thin line in the ratings however there is communication between two separate systems (S4 + side-by-side) and an upgrade can be done for either system.




      Author's profile photo Pierre COL
      Pierre COL

      Great blog post, very well done Jeetendra Kapase! 👍🏻

      I'm working in the SAP Build product team, and I am involved in a project with many stakeholders to publish an SAP BTP Extensibility Guide for S/4HANA. We are covering all of the topics you mentioned here, also in relation with SAP internal Golden Path.

      To give examples on how SAP BTP is complementing SAP S/4HANA, we have summarized a few use cases with SAP Build Process Automation extending S/4HANA in Finance that you can discover in this ebook: "Automate Finance Processes to Optimize Organizational Workflows and Increase Business Efficiency".

      Readers will learn how SAP Build Process Automation empowers finance professionals to automate repetitive manual tasks within SAP S/4HANA and discover how to jumpstart their automation journey with our pre-built content and connectors.

      Author's profile photo Jeetendra Kapase
      Jeetendra Kapase
      Blog Post Author

      Thank you Pierre COL for commenting and sharing the article links in the SAP Build area. Much appreciated!

      Author's profile photo Jelena Perfiljeva
      Jelena Perfiljeva

      Hi Pierre! Just following up on this comment since it's been a few months. Have the document you mentioned been published? Or did it become the development guide that was shared at TechEd?

      Thank you!

      Author's profile photo Pierre COL
      Pierre COL

      Hi Jelena, we are currently merging the work done by several teams on S/4HANA extensibility and clean core best practices, final document should be available beginning of 2024.

      Author's profile photo Satish Kumar Gunda
      Satish Kumar Gunda

      Brilliant blog Jeetendra!!, Very clear & comprehensive!!

      Author's profile photo Sunil GUPTA
      Sunil GUPTA

      Great Blog Jeetendra. Truly Awesome work!!

      I just wanted to know your views on creating independent custom programs (Z programs) e.g. we write some custom programs to update a transaction in a batch every night. What do you suggest for those cases? Do we write these batch job programs in BTP or continue in S/4?




      Author's profile photo Jeetendra Kapase
      Jeetendra Kapase
      Blog Post Author

      Hi Sunil,

      With the new extensibility model, the classical way of creating jobs using SM36 or ABAP program is kind of a retired way.

      A customer can create RAP based program using released objects to update the transaction. To schedule it as a batch job, there are ways:

      1. Application jobs fiori app
      2. Using API provided by ABAP platform.
      3. Using BTP ABAP platform.

      Which one to choose? goes by requirement. If there are multiple instances of S/4HANA, then side by side provides central place to manage them. however, if the requirement is for specific ERP system then options of the Fiori app or ABAP API to schedule/monitor the jobs can be utilized.

      Author's profile photo Sunil GUPTA
      Sunil GUPTA

      Thanks Jeetendra.


      Another question I wanted to ask you was about using BAPIs / IDOCs / etc. Are these obsolete or can still be used?

      Also, if we are allowed to use them, then how about extending them? Can we extend BAPIs / IDOCs / SOAPs etc?


      Sunil Gupta

      Author's profile photo Jeetendra Kapase
      Jeetendra Kapase
      Blog Post Author

      Please refer to the official guide: ABAP Cloud - Technical Use Cases and Recommended Technologies

      If still have questions, feel free to comment.



      Author's profile photo Sunil GUPTA
      Sunil GUPTA

      Hello Jeetendra,


      I looked into above document. This document doesnt talk about IDOCs. Are IDOCs obsolete? Is SAP moving away from IDOCs and how long SAP will support IDOC if they are moving away from IDOCs.

      another question is about extending SAP standard SOAP services / ODATA APIs. Is there SAP preferred way of extending them? e.g. adding missing attributes. Is this part of developer extension?



      Sunil Gupta

      Author's profile photo Jeetendra Kapase
      Jeetendra Kapase
      Blog Post Author

      In the cloud world, IDoc is deprecated integration technology can no longer be used. Only released frameworks are available for cloud development.

      Example: OData, Business Events, HTTP services, RFC via cloud-enabled WebSocket RFC, SOAP, SQL service, and  SAP information access (InA) for analytical clients

      Please refer to section 4.4.4 Connectivity


      Hope this helps.


      Author's profile photo Sunil GUPTA
      Sunil GUPTA

      Thanks Jeetendra.


      For SAP S/4 HANA on premise, can we use standard IDOCs and still be clean core? I know it would not be cloud ready as IDOCs are deprecated in cloud.

      Also I looked at the documents but there are no clear guideline on how to extend standard ODATA / SOAP services.


      Is there any document which we can go through?



      Sunil Gupta


      Author's profile photo Archana Polakhare
      Archana Polakhare

      Great Blog Jeetendra!!Very well explained.

      We are moving from ECC to S4 .I want to understand the extension models in S4 HANA for

      1.Customised tables,

      2.Condition table(TVARVC)  or BRF+??

      3.Maintenance views with SM30

      4.ALV reports with se38

      Please guide on extensibility model in S4HANA .

      Thanks ,


      Author's profile photo Jeetendra Kapase
      Jeetendra Kapase
      Blog Post Author

      Hi Archana,

      Please refer to the official guide: ABAP Cloud - Technical Use Cases and Recommended Technologies

      If still have questions, feel free to comment.




      Author's profile photo Frank Li
      Frank Li

      Great blog, very useful for SAP Customers and SAP ABAP Consultants. Lots of use links and documentation. Looking forward to your future blogs.

      Author's profile photo Sarthak Gupta
      Sarthak Gupta

      Hello Jeetendra Kapase ,

      Hope you are doing well!
      My question is related to the fact that with the SAP S/4HANA 2022 release Embedded Steampunk (and hence on-stack extensibility) is available in SAP S/4HANA Cloud, private edition and on-premise.

      I am currently working in S/4HANA PCE 2021 version. If I am developing a Web API by following ABAP RAP model, using only APIs with the state ‘USE_IN_CLOUD_DEVELOPMENT’ and restricted language version 'ABAP FOR CLOUD DEVELOPMENT', then what difference will be when the system is upgraded to 2022 or higher version? Will same existing code be termed under Developer Extensibility or some adaptation will be required to term it under Developer Extensibility?

      Sarthak Gupta

      Author's profile photo Jeetendra Kapase
      Jeetendra Kapase
      Blog Post Author

      If you have followed the RAP approach and used released APIs, then your code is ready for future enhancement/change compatibility and required system identification during the upgrades. It will be considered as Developer (on-stack) extensibility.


      thank you,


      Author's profile photo Saptarshi Sen
      Saptarshi Sen

      Hi Jeetendra Kapase


      Excellent Blog.

      I am seeking some guidance regarding transformation of legacy enhancements in the context of clean core realization.

      When it comes to Enhancement objects, SAP offers a set of Released BADIs that can be implemented through both Key-User as well as Developer Extensibility. However, it would be very helpful to have clarity on the following queries:

      1. SAP does provide some classic (unreleased) to released/whitelisted BADI replacement or 'successor' recommendations, primarily via system table 'ARS_API_SUCCSSR'. As of latest S/4HANA 2022 Release (and also the new Cloudification Repository) - we see 49 Released BADI replacements/successors that map back to just 15 unique classic unreleased BADIs. However, upon checking the released API source table 'ARS_W_API_STATE' - we find over 1200 BADIs that are C1 Released (Key-user + ABAP Cloud). So we'd like to understand the factors for the missing mapping (to classic/unreleased ones) of remaining 1100+ Released BADIs. Does SAP have any plans to offer mapping of all these released BADIs as successors to classic unreleased Enhancements/BADIs (through ARS_API_SUCCSSR table entries or any other utility)?

      2. From a Brownfield customer's point of view, it would be very helpful to identify the exact unreleased classic enhancement objects - that can be replaced with the 1200+ SAP Released BADIs. Is there any guidance/recommendation from SAP around this mapping approach? Can we leverage contents from SCFD_REGISTRY in this regard?

      3. As we know, classic enhancements are of various types that include - BADIs, Exits, Source code Explicit/Implicit Enhancements, VOFM Routines, BTEs. However, for enhancement implementations using clean core concepts - the recommendation is to use only Released BADIs. Are Released BADIs expected to replace all types of classic enhancements mentioned above? We have seen examples of classic BADIs or User exits being transformed to Released BADI implementations (Example: SD User exit MV45AFZZ logic implemented via Key-user Released BADIs under ENHS - ES_SD_SLS_EXTEND). How about the other classic enhancement types that are also commonly used in ERP systems, like Source code Explicit/Implicit Enhancements, BTEs and Form routines?

      Would be eager to have response around the points above, as they would be instrumental in supporting customer's S/4HANA clean-core journey. Thanks in advance!


      Best Regards,

      S Sen

      Author's profile photo Adrian Dengusiak
      Adrian Dengusiak

      Hi Jeetendra Kapase

      Thanks for submitting this helpful blog.

      I have a couple of questions related to SAP Fiori and how to keep the core of UI5 clean in BTP + S/4HANA architecture.

      1. Let's say we have Launchpad in BTP, connecting to multiple on-premise S/4HANA systems (hybrid architecture). In one of S/4 systems we have a standard Fiori Timesheet application. A requirement is to perform some modifications, which can be achieved by extension project only (no option to adapt the UI as a key user). Where should an extension app be built? Should it be deployed to BTP (to decouple from the backend) or sit together with an original app on-premise (and then be exposed in BTP)? Is there any general rule for adaptation/extension projects?
      2. Similar case, but with a completely custom Fiori app. Let's say we have installed a new role in S/4HANA, enabling Users to consume standard set of applications in HR area. Then we realize we need some new app that consumes data from the same S/4 system. Should new freestyle UI5/Fiori Elements app sit in BTP or on-premise?
      3. What in case the same standard Fiori app can be launched in BTP or S/4HANA on-premise? Should BTP have a priority over on-premise?
      4. Are there any documents related to keeping the core clean for Fiori apps (related to frontend stack)?



      Author's profile photo Prasenjit Bist
      Prasenjit Bist

      Let's make it simple. I am using S/4 Public Cloud I play by the rule of everything you say. Now how much of it even makes a sense for the on-premise customer?


      Let's see the kind of development we do for our on premise customers

      1. IDOC Interfaces - Extend a standard IDOC - I will go with Customer Exits or new types and Function Modules
      2. SOAP/ REST services cool use the API hub no problem but that ain't clean core fundamental right?
      3. Extend business functionality example SD/ Billing- where would I write code? Some User Exit or equivalent BADI. And this is where clean core comes into picture right? BADI, Customer Exits, User Exits, SPAU, SPDD. What is the option for these customers? Let's be honest. I need to change incoterms what would I do- write a side by side or do key user or implement the exit?
      4. If the user switches on the Fiori app then I can use key user UI adaptation blah blah else I will do that normal screen enhancement I have been doing since 2007.
      5. Workflows ok go for flexible if it exists and fits the demand else go custom
      6. New custom reports etc. well you can go RAP or go classical. Again depends RF scanner I guess I won't go for a Fiori app or most customers find it expensive to hire another UI team if the requirement does not fits with RAP UI annotations and I have seen many cases. One customer asked me to allow them to download to excel this and that but the standard Fiori Elements can not handle so develop a custom extractor and that means a UI5 guy. They dropped the idea and moved back to their ABAP SE80 Report.
      7. Mobile apps I have seen most customers in my experience of 6 s4 Implementations use open source technologies they just say give me the ODATA service and then get out. Use SEGW or use CDS based RAP model and I would recommend ABAP RAP no problem.

      I can add more and more but this is what we do for our core on premise implementation customers, now tell me where the bells and whistles of clean core, side by side and all good to read , use as jargon to impress comes into real life. Unfortunately real life and reel life are different. And so are S4 Cloud and On premise worlds. And all these are actually noises that leads to wasteful meetings and workshops and then you are back to the same point where you started.




      Author's profile photo Frank Li
      Frank Li

      Thanks for sharing your S/4HANA On-Premises project implementation experience. From my understanding that kind of customers have no plan to use S/4 cloud public edition and keep using On-Premises, right? If switch to use public cloud, all those custom development are lost and has no value afterwards.

      Author's profile photo Prasenjit Bist
      Prasenjit Bist

      Hey buddy,

      Guess what there are large number of such customers who foot big bills to us and pay huge licensees to SAP. And not everyone in the world is dreaming to be on the clouds. SAP is still selling boat loads of on premise licenses and these customers are making investments for decades.

      So, in short no they won't move their ERP solutions to cloud they love to be in control of their assets. And they will loose you are right. Yeah they will but if they move. In reality these deep pocket customers buy standalone cloud licenses of Ariba or Salesforce or other stuffs but keep the core ERP at home.


      Any ways my point was to highlight this clean core marketing does not fits with in the on-premise world but may be still the marketing loves to tell them something that would be  ridiculous to do though you still get to bill them for the discussions of something you yourself would absolutely never do. right?




      Author's profile photo Frank Li
      Frank Li

      Hi Prasenjit,

      Thanks a lot for sharing, large SAP ERP customers might prefer to stay on SAP ECC/SAP S4HANA On-Premise/SAP S4HANA cloud private edition, right? For SAP S4HANA On-Premise/SAP S4HANA cloud private edition customers, when doing extension for customers if not follow the clean core concept and do the same as before following the classic approach, then might face big problems when doing the upgrade for S4HANA On-Premise/SAP S4HANA cloud private edition, such as an upgrade from SAP S4HANA cloud private edition 2021 to 2023, right? I have no upgrade experience, just my assumption.

      Author's profile photo Prasenjit Bist
      Prasenjit Bist

      Hello Frank,


      The on-premise world still does not have a lot of cloud like extensibilities available and given these customers would go for a big customization and SAP has not kept up there are still many BADIs that are not API released or you would still use a lot of customer exits, VOFM and what not. Of you check the SAP documentation or the kind of PDFs they publish these are all still accepted and rather recommended ways. We all know modifications are bad even in ECC and we never do right. Only point is in S/4 SAP will still allow you a lot of enhancement points. So, the summary is SAP itself is part of the problem at most places and may be deliberately doing that to push more people to cloud but at the end of the day those who use such heavily modified ERP will see the real value in on-premise version.

      Just imagine the charges for BTP ABAP or other stuffs so, who would like to put an extension there and not directly on the S/4 stack itself?

      My point is the so much hyped clean core and side by side or key users are valid only in the cloud world and not on the on-premise given how each customer has different implementations and choices. And the usual problems that you rightly mentioned will be there as expected.

      Read this portion from one of their documents for instance ->

      Classic business logic extensions should follow the below recommendations below:
      • BAdIs: even if a BAdI is not released for usage in cloud development it is a good choice for customers to extend the application. Most likely the BAdI will be released with an upcoming release or will be replaced with a released BAdI as successor.
      • User exits, like VOFM, SAPMV45A: user exits are coding parts pre-defined by SAP (form routines, includes) in an SAP namespace where the customer can implement custom code to extend the SAP business process. The predefined coding parts from SAP are stable and typically do not lead to issues after an upgrade. Technically the custom code here is treated as a modification. It is planned that BAdIs will replace these extensions over time.
      • Customer exits (SMOD/CMOD): customer exits are the predecessor technology to BAdIs and will be replaced. Anyhow you can still use them in exceptional cases where no BAdIs exist yet in the application. Most likely they will be replaced completely with upcoming releases.
      • Explicit enhancement spots: these are extension points that were mainly created by SAP to enable industry-specific adaptations to the core ERP applications. We recommend using them only in exceptional cases to include custom-defined BAdIs into the SAP core. You should not directly include extension code in the enhancement spot.
      • Implicit enhancement spots: this extension technique is very similar to modifications and should therefore not be used to extend the core applications.


      Author's profile photo Frank Li
      Frank Li

      Hi Prasenjit,

      Thanks a lot for sharing and interesting discussion.

      Yes, classic extension still valid for long time as lots of customers might keep on on-premise world.
      But I also believe more and more will choose public cloud, a cloud-first approach is becoming the new normal powered by software-as-a-service (SaaS) applications with AI/ML, digital assistants such as SAP announced SAP Joule. I believe more and more businesses process will be enabled with Generative AI capabilities.

      As ABAP consultants working on ABAP for many years, in the new world faces lots of challenges and lots of new thing need to explore and practice such as you mentioned BTP ABAP cloud, SAP UI5, Fiori and etc. And if want to be good architects not pure ABAP consultant,and can give suitable solutions such as when to use what on cloud world(SAP BTP CAP , SAP BTP ABAP cloud, BTP integration) , need to learn a lot. We have a long journey for SAP Public cloud world, eventhoug currently not many customers choose PUBLIC CLOUD, but I believe public cloud is the future.

      Author's profile photo Prasenjit Bist
      Prasenjit Bist

      I agree with you and we keep learning that is not and should not be our problem as we work for System Integrators and we deliver whatever comes to us. If in 2023 someone asks me to write a Web Dynpro ABAP app I will have to do that and if some one says maintain my smart form I will do that. So, in a year I work on multiple projects with RAP or ALV or Module Pool or WDA and everything good or bad. My point is we learn and we deliver the things on Public Cloud as well. Even for one of my customer we did clean core because they wanted it that way. They dropped where it was not possible but wanted clean core. Now what about the majority, so it will be the tool as  and when required. Right?

      My only objection is always the way SAP sources hype things. Clean Core and Cloud Extensibility is not possible always 100% in on-premise but the way people try to ring them is like this is the new religion you have to follow else you are done. I just care about those boundaries and demarcations and that is what this led to my comments. How many do care about Joule or their IoT and so many things. How many use event mesh? There will always be some takers and some will only use the core ERP processes on SAP and not do everything. Again the point is extending on-prem core applications.

      Generative AI I believe will come to on-premise also or as a BTP service that is okay, we are talking about the core business applications. I am not sure how cloud journey will go for all customers but there are 2 camps and let's respect it. Let's not make it like the cold war or assume it's a unipolar world. It's actually multi polar as you not only have cloud, private etc. but many are still on ECC and will continue for a decade or so more to come and they have their own wisdom and reasons we can not force them to come ride with us the S/4 or the S/5 wave if any at all after 2040.

      Author's profile photo Frank Li
      Frank Li

      Hi Prasenjit,

      Totally agreed with what you mentioned, also learned a lot from your comments. Our customers always come first. We delivere what our customers want and what’s the best for our customers. Yes, ECC, S4 OP, S4 Public Cloud, S4 Private Cloud, SAP BTP, and etc and etc, definitely coexists for long and long time. Hope SAP ecosystem becomes more and more successful, and all of us working in SAP ecosystem have bright future.