SAP BTP Extension Scenarios: The Complete Enterprise Guide for 2026

What Are SAP BTP Extension Scenarios?

SAP BTP (Business Technology Platform) is the company's flagship cloud development and integration platform. SAP positioned it as the enterprise's "technology backbone" for extending S/4HANA, integrating third-party applications, and building custom solutions without modifying core ERP code.

Within BTP, SAP defines three primary extension scenarios:

1. Side-by-Side Extensions

Side-by-Side extensions are entirely decoupled applications built on BTP that run independently of S/4HANA. They communicate with ERP via APIs and webhooks, making them scalable and easy to retire. Examples include custom workflow tools, analytics dashboards, or industry-specific bolt-on modules.

Why enterprises choose Side-by-Side: Minimal risk of disrupting core ERP operations, clear separation of concerns, and straightforward licensing (each extension is metered independently under CPEA).

The hidden licensing reality: Each extension consumes CPEA credits per instance. A global enterprise might deploy 15-20 Side-by-Side extensions simultaneously, and each extension's consumption is separately tracked and billed.

2. In-App Extensions

In-App extensions are tightly coupled to S/4HANA's embedded development environments, such as ABAP in the Cloud or SAP Fiori elements. These extensions run within the S/4HANA system boundary and are subject to the same licensing restrictions and audit scrutiny as the parent system.

Why enterprises choose In-App: Direct access to S/4HANA data models, reusability of existing ABAP code, and simplified deployment pipelines.

The hidden licensing reality: In-App extensions do not consume separate CPEA capacity; instead, they are licensed as part of the S/4HANA system itself. However, custom ABAP code and enhancements can trigger License Compliance requirements (LAW audits), and SAP auditors often challenge the classification of In-App extensions, claiming they should have been Side-by-Side to generate higher BTP licensing spend.

3. Clean Core Extensions

Clean Core is SAP's newer architectural approach, positioning BTP as the primary extension mechanism to maintain a "clean" and upgrade-friendly S/4HANA core. SAP claims Clean Core extensions are lower-cost, but the licensing reality is more nuanced.

The five tenets of Clean Core (according to SAP):

• Extensibility: Expose ERP functionality via standardized BTP APIs to minimize custom code.
• Integration: Use Integration Suite to orchestrate multi-system workflows without ERP modifications.
• Data: Maintain transactional data in S/4HANA; extend with external data sources on BTP.
• Process: Customize business processes via workflow and low-code tools; avoid ABAP customization.
• Use-case: Implement industry-specific logic as standalone BTP applications, decoupled from ERP.

The hidden licensing reality: Clean Core extensions are metered under identical CPEA rules as Side-by-Side extensions. SAP's marketing narrative that Clean Core is "cost-efficient" ignores the fact that enterprises building Clean Core solutions still pay for BTP capacity. The cost advantage exists only if you avoid In-App custom ABAP (which would require LAW licensing), but you pay for that benefit upfront in BTP consumption.

The Licensing Reality SAP Doesn't Advertise

SAP's documentation on BTP licensing is intentionally opaque. Here are the facts your account team will reluctantly acknowledge:

CPEA Consumption Model

CPEA stands for "Cloud Foundry Platform Engagement Approach." It is not a simple per-user or per-transaction metric. Instead, CPEA consumption is based on:

• Application instances: Each running BTP application consumes a minimum of one CPEA unit per instance (regardless of actual workload).
• Memory allocation: Applications can scale up, and each memory tier consumes proportionally more CPEA capacity.
• Service subscriptions: Integration Suite, Data Intelligence, and other BTP services consume separate CPEA allocations outside of application instances.
• Quarterly regeneration: CPEA credits reset quarterly. Unused capacity does not roll over to future quarters — a deliberately punitive design that encourages over-specification.

Kyma Runtime vs Cloud Foundry

SAP offers two runtime environments for BTP extensions:

• Cloud Foundry: The traditional, mature runtime for containerized applications. Most enterprises start here because it has well-documented APIs and ecosystem support.
• Kyma: A newer Kubernetes-based runtime positioned as "cloud-native." Kyma is heavily promoted by SAP's marketing, but it consumes capacity differently, and many enterprises find migration from Cloud Foundry to Kyma requires substantial rework.

Both runtimes consume CPEA, but Kyma adds complexity: it requires familiarity with Kubernetes concepts, triggers higher operational overhead, and SAP's documentation on Kyma pricing is even more opaque than Cloud Foundry's.

The "Free" BTP Credits Trap

SAP frequently bundles "free" BTP credits into RISE with SAP or S/4HANA subscription packages. These credits are tempting but deceptive:

• They are not truly "free"; they are prepaid as part of your overall RISE spend.
• They are intentionally allocated at low levels (often 100-200 CPEA units per quarter) to force enterprises to rapidly encounter overages.
• Once you exceed the bundled credit allocation, you pay per-instance overage rates, which are 3-4x higher than the bundled rate per unit.
• There is no volume discount for overages; SAP applies the same inflated per-instance rate regardless of total consumption.

A global manufacturing enterprise we advised had 300 CPEA units bundled with RISE. After deploying just 12 extensions (25 running instances across dev, test, and production), they exceeded allocation by 150 CPEA units within Q1. Annual overage costs topped $840,000 — a number their CFO had not anticipated.

RISE with SAP and BTP Extension Scenarios: What's Actually Included

RISE with SAP is SAP's flagship consumption-based contract model, positioning itself as the "simplified" alternative to perpetual licensing. It sounds attractive, and it is — until you deploy extensions.

What RISE Includes for BTP

RISE bundles typically include:

• S/4HANA Cloud or On-Premise licenses
• A fixed allocation of CPEA credits (usually 100-300 units quarterly)
• Limited Integration Suite services (500-1000 message packs per month)
• Basic analytics and reporting

In practice, these allocations are exhausted within months of the first extension deployments.

The Consumption Burndown Trap

CPEA consumption is not linear. It accelerates as you deploy more extensions and scale existing ones:

• Month 1-2: You deploy your first 2-3 extensions, consuming ~30% of quarterly allocation.
• Month 3-4: Business users request enhancement; you add features, scale instances, and hit 70% consumption.
• Month 5-6: New business case requires additional extensions; you breach quarterly allocation by 40-60%.

By the end of the year, you have paid for CPEA overages that dwarf the cost savings you expected from switching to consumption-based licensing.

Link to RISE Advisory Service

If you're evaluating RISE with SAP or currently under RISE, our RISE with SAP advisory service includes detailed consumption modeling, overage forecasting, and contract renegotiation tactics specific to BTP extension scenarios. We review your extension roadmap and quantify the true BTP costs before you commit.

SAP BTP Extension Scenarios: Hidden Costs That Catch Enterprises Off Guard

Beyond CPEA and Kyma runtime charges, several hidden costs consistently exceed enterprise expectations:

Integration Suite Overages

The Integration Suite (which includes API Management, Cloud Integration, and Event Mesh) is bundled into RISE with conservative message pack allocations. Each extension that integrates with third-party systems, legacy applications, or other BTP extensions consumes message packs. A single enterprise-grade workflow can consume 5,000-10,000 message packs per month. At $0.12 per pack, this translates to $600-$1,200/month per workflow — often overlooked in budget forecasts.

Data Persistence and Backup Costs

Extensions that write to SAP HANA Cloud or PostgreSQL databases consume separate storage allocations. SAP charges per GB per month, and backup/replication add 30-50% to base storage costs. A 500GB extension database costs approximately $3,500-$5,000/month in storage and backup fees alone.

Operational and Support Costs

Supporting a BTP extension estate requires Cloud Foundry or Kubernetes expertise. Most enterprises hire external vendors (SAP's partner ecosystem) to manage deployments, scaling, and troubleshooting. These services typically cost $100K-$300K/year per extension landscape, and SAP expects enterprises to absorb this cost.

For detailed guidance on identifying and mitigating hidden costs, see our guide on hidden costs of SAP BTP extension scenarios.

How to Optimise Your BTP Extension Consumption

Reducing BTP extension costs is possible, but requires architectural discipline and vendor pressure:

Demand-Driven Consumption Planning

Before deploying any extension, conduct a detailed consumption model:

• Estimate daily API calls and transactions per extension.
• Model peak load and scale requirements.
• Forecast Integration Suite message usage per workflow.
• Project storage growth 18-24 months forward.

Use this model to challenge deployment decisions. Many extensions are justified by assumed adoption that never materializes; demand-driven planning prevents this waste.

Consolidation and Reuse

Instead of deploying 20 isolated Side-by-Side extensions, architect shared services and libraries that multiple extensions reference. This reduces total CPEA consumption by 25-35% in typical enterprises.

Kyma vs Cloud Foundry Trade-off

Kyma promises lower operational costs through Kubernetes orchestration, but this is true only if your team has K8s expertise. For most enterprises, Cloud Foundry remains more cost-efficient because SAP's managed platform handles scaling and lifecycle.

See our full guide to optimising SAP BTP extension consumption for architectural patterns and consumption reduction strategies.

SAP BTP Extension Scenarios: Enterprise Buying Decisions

When negotiating BTP extension contracts, focus on:

• Bundled CPEA allocation: Push for 400-600 CPEA units per quarter in RISE packages, not the standard 100-300. This provides real buffer and reduces overage exposure.
• Consumption rate caps: Negotiate a cap on per-instance overage rates. SAP typically charges $X per instance; demand tiered pricing that rewards high consumption (counterintuitively, higher volume should cost less per unit).
• Quarterly rollover: Challenge the quarterly reset. Negotiate annual consumption pools that allow rollover of unused CPEA, reducing the "use it or lose it" pressure.
• Integration Suite message pack allocation: Request 50K-100K message packs per month minimum, depending on your extension roadmap. This prevents surprise overage bills.

Our SAP BTP extension scenarios enterprise buying guide provides contract language and benchmarks from comparable deals.

Negotiation Tactics for SAP BTP Extension Scenarios

SAP rarely volunteers concessions on BTP pricing. Here's how to extract value:

Benchmark Against Competitors

Oracle (with Fusion Cloud Extensions), Workday, and Microsoft Dynamics 365 all offer extension platforms with more transparent, lower-cost pricing models than BTP. If you're evaluating BTP as part of S/4HANA, threaten to evaluate Workday or Fusion Cloud as part of your contract renewal. This immediately opens SAP's door to meaningful concessions on BTP terms.

Expose Consumption Models

SAP's account teams are trained to downplay extension costs. In your renewal negotiations, present your detailed BTP consumption forecast (built from demand-driven planning above). Force SAP to either agree to conservative allocation or admit they are underselling the true cost. This creates leverage to renegotiate bundled CPEA.

Volume-Based Tier Negotiations

If you have multiple SAP systems (S/4HANA, Successfactors, Ariba, etc.), consolidate them into a single contract negotiation. Tell SAP, "We'll commit to a 3-year S/4HANA renewal at your list price — but only if you include enterprise-wide BTP licensing with bundled CPEA equal to 30% of our forecasted consumption." This shifts the leverage; SAP will trade lower per-instance BTP rates for contract duration and total ACV (Annual Contract Value) uplift.

For detailed negotiation templates and tactics, see our SAP BTP extension negotiation tactics guide.

FAQ: SAP BTP Extension Scenarios

The Bottom Line: SAP BTP Extension Scenarios Require Vendor Discipline

SAP BTP is a powerful platform for extending S/4HANA, but its licensing model is deliberately complex and designed to extract maximum value from enterprises that don't understand CPEA consumption patterns. The "free" BTP credits bundled in RISE packages are cheap allocation bait; the real costs emerge when you deploy your second wave of extensions.

The best enterprises are those that:

• Model BTP consumption in detail before deployment.
• Architect for consolidation and reuse, not isolated extensions.
• Negotiate BTP allocations upfront as part of broader S/4HANA contracts.
• Continuously monitor and forecast consumption to avoid surprise overages.
• Engage independent licensing advisors to challenge SAP's baseline assumptions.

If you're currently under RISE with SAP or evaluating S/4HANA with BTP extensions, we recommend an independent licensing assessment. Our team has renegotiated BTP terms for 40+ enterprises, achieving an average of 28-35% cost reduction while maintaining full architectural flexibility. Let's talk about your specific extension roadmap.