SAP In-App vs Side-by-Side Extensibility isn’t a coin flip it’s a filter you should be applying to every customization request the moment it lands on your backlog. Get the split wrong, and you end up in one of two bad places: fragile custom code bolted onto the S/4HANA core that turns your next upgrade into a testing marathon, or a two-day requirement routed through a six-week BTP build cycle it never needed.
Both paths are common, and both are avoidable. The real question isn’t “which extensibility model is better” it’s which one fits this specific request, based on how deeply it needs to touch the S/4HANA core, whether it depends on data or logic outside SAP, and how much upgrade risk your organization is willing to carry?”
This guide breaks down exactly how to make that call with a side-by-side comparison, a scenario-based decision checklist, and the governance habit that keeps the decision from becoming a recurring architecture debate.
SAP In-App vs Side-by-Side is a critical decision for your S/4HANA system. This guide offers a side-by-side comparison, as well as advice and best practices in choosing the correct extension strategy for your S/4HANA system.
Why Extensibility Matters in S/4HANA
Extensibility is having the flexibility to customize or extend SAP systems for new business content without compromising standard core functionality. It guarantees that SAP will scale with your company and the upgrades will be robust.
Without a clear extensibility strategy:
- Add-ons can introduce tech debt, making future upgrades more complex.
- Stiff systems can impede progress even when innovations come along.
- Integration challenges rise when it comes to SAP modules and non-SAP systems.
SAP Side-by-Side Extensibility:
In practice, side-by-side extensions are built using the SAP BTP ABAP Environment (formerly Steampunk) for ABAP-skilled teams working with RAP (RESTful Application Programming Model) or with the Cloud Application Programming Model (CAP) in Node.js/Java for teams building on Cloud Foundry.
Communication back to S/4HANA typically runs through OData/REST APIs published via the SAP API Business Hub, or asynchronously through SAP Event Mesh for event-driven patterns (e.g., a goods-receipt event triggering a BTP-hosted quality check). Integration Suite (formerly Cloud Platform Integration) is commonly layered in when the side-by-side app needs to talk to non-SAP systems as well.
Parallel extensibility builds its extensions on S/4HANA on the SAP Business Technology Platform (BTP) in most cases. These extensions then interface to S/4HANA through APIs, events, or services, resulting in more complex and innovative cross-system applications.
Advantages of Side-by-Side Extensibility
- Upgrade Safe – You never touch the core system.
- Flexibility & Innovation – Great for third-party systems, AI apps, or industry vertical solutions.
- Scalability: Future business needs are catered to by third-party add-ons while retaining the S/4HANA core.
Limitations of Side-by-Side Extensibility
Longer Dev Cycle – Longer at planning, integration, and testing.
Complex Integration – Needs APIs, middleware, and monitoring to seamlessly communicate.
More Expensive Up Front – Investment in SAP BTP, dev resources, and governance needed.
Example Use Case:
Global manufacturer develops predictive maintenance app on SAP BTP. The app collects IoT data, predicts machinery breakdowns, and triggers S/4HANA processes without changing the core. For more insights read our Blog on SAP BTP Extension Suite
In-App vs Side-by-Side: Critical Drivers for Your S/4HANA Decision
| Factor | In-App Extensibility | Side-by-Side Extensibility |
| Complexity of Requirement | Small enhancements, minor workflows | Complex apps, multi-system integrations |
| Upgrade Safety | Moderate risk if heavily customized | High; core system untouched |
| Time-to-Implement | Fast | Longer due to external development |
| Innovation Potential | Limited | High; supports AI, ML, IoT |
| Maintenance | Lower for small changes, higher if heavily customized | Autonomous, easier to manage at scale |
| Cost | Lower upfront | Higher upfront investment |
What is the Right Way to Choose an Extension Strategy
Start from a Business Strategy – Make decisions based on business-driving factors, not just technical prerequisites.
Concentrate on an upgrade-safe Path – Limit your customization in the S/4HANA core so you’re not carrying long-term risk.
Apply SAP BTP for Innovation—When to use side-by-side, which is AI/advanced functionality/cross-system workflow.
In-App & Side-by-Side Working in Tandem
Hybrid Approach:
- Use in-app extensions for minor, low-risk improvements.
- Use side-by-side extensions for advanced, complex, or forward-looking solutions.
What “in-app” actually includes, by technique:
| Technique | Cloud (Public Edition) | On-Premise / Private Cloud Edition |
|---|---|---|
| Custom Fields & Logic (Key User Extensibility) | Supported | Supported |
| Custom CDS Views / Custom Business Objects | Supported (via Extensibility apps) | Supported |
| ABAP Cloud development (RAP, released APIs only) | Only option for developer extensibility | Available alongside classic techniques |
| Classic BAdIs / user exits / enhancement points | Not available | Available, but flagged by ATC as an upgrade risk |
| Core object modification | Blocked | Technically possible, strongly discouraged |
Example:
A logistics company adds custom fields on delivery orders in-app but builds a side-by-side analytics application on SAP BTP for routing and predictive demand planning.
SAP Extensibility Success: An Executive Checklist
- Evaluate both technical and business implications for all extensions
- Assess the upgrade risk of in-app customizations
- Explore alternate designs through side-by-side development
- Record all changes and connections for governance and audit
- Define KPIs to monitor adoption, performance, and ROI
Conclusion
The SAP in-app vs. side-by-Side Extensibility choice isn’t really a single decision you make once — it’s a filter you apply to every customization request that lands on your backlog. Small, contained changes that stay inside SAP’s released extension points belong in-app, where they inherit S/4HANA’s own upgrade safety. Anything that needs to reach outside the core — AI, IoT, cross-system workflows, or heavier compute — belongs on BTP, where isolation from the core is the whole point, not a side benefit.
Most mature SAP shops end up running both simultaneously, and the real skill isn’t picking one paradigm forever; it’s building a lightweight governance habit (even a one-page checklist) that routes each new request to the right lane before a developer starts building. Get that triage step right, and the in-app/side-by-side question stops being a recurring architecture debate and becomes routine.
Overall, deciding on SAP in-app vs side-by-side extensibility isn’t just a technical choice—it’s strategic.
- In-app extensions: Best for small, low-risk improvements.
- Side-by-side extensions: Enable innovation, integration, and expansion while preserving core system stability.
Your extension strategy is about more than code; it’s about business agility, innovation, and future-proofing your SAP landscape.
FAQs
Q: What’s the primary difference between an in-app extension and a side-by-side extension
A: An in app extensions run within S/4HANA, while side-by-side extensions are external apps leveraging APIs or services to communicate with S/4HANA.
Q: Which is better for upgrades?
A: This is an upgradable side-by-side extensibility – your core remains unchanged. In-your-soul in-app changes make the upgrade difficult.
Q. Can I use in-app and side-by-side extensions?
A: Yes. Hybrid Solution: Make small in-app enhancements and side-by-side, large innovations.
Q: What are the possibilities of using side-by-side extensions with SAP BTP?
A: With SAP Business Technology Platform, you get agility and control with APIs, integration tools, and analytics for external applications that are flexible and scalable.
Q: Who decides extension policy?
A: It’s a joint effort of CIOs, owners of SAP transformation, enterprise architects, and leaders of business processes – all working together to strike the right balance between strategic vision on one side and business needs and technical constraints on the other.
Q: Does in-app extensibility work the same way on S/4HANA Cloud and on-premise?
A: No. On Cloud editions, in-app extensibility is limited to Key User tools and the ABAP Cloud/RAP development model against released APIs. On-premise and Private Cloud Edition systems can also use classic techniques like BAdIs and user exits, though these carry more upgrade risk.
Q: What is RAP, and where does it fit into this decision?
A: RAP (RESTful Application Programming Model) is SAP’s modern ABAP development model for building both in-app extensions (via ABAP Cloud, using released APIs) and side-by-side apps (on the BTP ABAP Environment). It’s the common thread between the two strategies, not a separate third option.
Q: How does SAP flag risky in-app customizations before an upgrade?
A: The ABAP Test Cockpit (ATC) and the Custom Code Migration app check custom code against released APIs and core-modification rules, flagging anything that could break during an S/4HANA upgrade.
