Your SAP BTP Decision Is Really a Lock-In Decision

SAP Business Technology Platform is where SAP wants your extensions, integrations, analytics and AI to live. The pitch is simple: stay inside the SAP ecosystem, benefit from tight integration with S/4HANA, and keep your core clean.

That pitch is mostly true. What it does not say clearly is that every extension you build on BTP is an extension that becomes harder to move away from SAP. That is not automatically wrong. It is a trade-off that needs to be made with open eyes, not by default.

This piece is for enterprise architects, SAP programme leads and CTOs deciding where to build extensions and integrations in an S/4HANA landscape.

The short version

BTP offers genuine integration advantages for S/4HANA extensions. It also increases SAP lock-in with every service you deploy on it. Decide per workload, not as a blanket policy. Some things belong on BTP. Others belong outside it.

• BTP is strongest for extensions that read and write S/4HANA data in real time.
• Analytics, integration middleware and AI workloads have competitive alternatives outside SAP.
• Every BTP service you adopt adds to switching cost. Account for this in architecture decisions.
• Clean Core does not require BTP. It requires keeping customisations out of the S/4HANA core.
• Evaluate BTP against hyperscaler alternatives for each workload on total cost, including exit cost.

This article sits inside the sap s/4hana, clean core and rap cluster, where the wider argument is set out in full.

What Clean Core actually requires

Clean Core is SAP's architecture principle that says: do not modify the S/4HANA core. Keep the core upgrade-safe by moving customisations to the extension layer.

Many teams interpret this as: move customisations to BTP. But Clean Core does not mandate BTP. It mandates that extensions sit outside the core and communicate through stable APIs. Those APIs — OData services, RAP-based interfaces, CDS views — work from BTP, from a hyperscaler, or from an on-premise integration layer.

The distinction matters because it separates two decisions that are often conflated:

1. Should we keep S/4HANA core clean? Yes. This is good architecture regardless of where extensions live. 2. Should extensions live on BTP? It depends on the workload.

Conflating these two decisions leads to a blanket BTP-first policy that is more about vendor alignment than architecture.

Should your organisation do this now?

• Yes, if you are planning S/4HANA extensions and have not evaluated alternatives to BTP.
• Not yet, if you are still in the middle of S/4HANA migration and have no extensions to build.
• Instead, first: complete the migration, then evaluate extension options.
• Measure it by: total cost of ownership per extension, including switching cost.

Where BTP earns its place

BTP is the right choice when the extension needs tight, low-latency integration with S/4HANA data. Specific scenarios:

Side-by-side extensions using RAP. If you are building a custom application that extends S/4HANA business objects — say, a specialised approval workflow for purchase orders — the RAP programming model on BTP gives you native access to the business object layer. Building the same thing on a hyperscaler means replicating data or building a custom API layer.

Fiori customisation. If your users live in the Fiori launchpad and the extension is a UI change or a new tile, BTP keeps the experience consistent.

SAP-to-SAP integration. If you run multiple SAP products — S/4HANA, SuccessFactors, Ariba — BTP Integration Suite provides pre-built connectors that a generic integration platform would have to replicate.

In these cases, BTP reduces development time and maintenance burden. The lock-in trade-off is reasonable because the workload is inherently SAP-specific.

Where BTP costs more than it should

BTP is a poor fit when the workload is not inherently SAP-specific and competitive alternatives exist at lower cost or with more capability.

Analytics and reporting. SAP Analytics Cloud is competent, but if your organisation already runs Power BI, Looker or Tableau for non-SAP data, adding a separate analytics tool for SAP data creates skill duplication and dashboard fragmentation. Most modern BI tools can connect to S/4HANA through OData or database connectors.

General-purpose integration. If you need to connect SAP with Salesforce, ServiceNow, a payment gateway and three other non-SAP systems, an integration platform like MuleSoft, Boomi or Workato may be a better fit than Integration Suite, because most of your integration surface is non-SAP.

AI and machine learning. SAP AI Core is narrow compared to what Azure, AWS or Google Cloud offer. If your AI use cases extend beyond SAP-specific scenarios like demand forecasting on SAP data, the hyperscaler platforms offer more models, more tooling and larger communities.

Data warehousing. SAP Datasphere exists, but if you already have a Snowflake, Databricks or BigQuery investment, adding a separate SAP-native data platform creates cost and complexity.

For each of these, the question is not whether BTP can do it. It usually can. The question is whether BTP is the best place for it, considering cost, capability and the switching cost you accumulate.

How to evaluate the trade-off

For each workload, I use a five-question test:

1. Does it need real-time read/write access to S/4HANA business objects? If yes, BTP is probably right. 2. Do competitive tools already exist in the organisation for this function? If yes, adding a BTP equivalent creates duplication. 3. Does the team that will build and maintain it have SAP skills? If no, BTP adds a skill acquisition cost. 4. What is the exit cost if we leave BTP in three years? Price the rewrite or migration. 5. Is the total cost of ownership lower on BTP or on an alternative, including the exit cost? Be honest about the number.

The answer is rarely all-BTP or no-BTP. A typical S/4HANA landscape might have side-by-side extensions on BTP, analytics on an existing BI platform, integration on a multi-cloud middleware, and AI workloads on a hyperscaler. That is not messy architecture. It is intentional architecture that places each workload where it performs best.

Should your organisation do this now?

• Yes, if you have a blanket BTP-first policy that has not been tested workload by workload.
• Not yet, if you have no current extension requirements.
• Instead, first: inventory your planned extensions and integrations.
• Measure it by: total cost of ownership per workload, compared across BTP and alternatives.

The licensing question

BTP licensing is consumption-based, which sounds flexible until you see the bill. Cloud credits are spent on compute, storage, API calls and individual services, and the pricing is not always straightforward to predict.

Three things to watch:

Credit burn rate. BTP credits are purchased in blocks. If your usage exceeds the purchased amount, overage rates apply and they are not cheap. Monitor consumption monthly, not annually.

Service-specific pricing. Each BTP service — Integration Suite, AI Core, HANA Cloud — has its own pricing model within the credit system. Understand each one before committing.

Minimum commitments. Some BTP services come with minimum annual commitments that are difficult to exit. Read the contract terms, not just the technical documentation.

I am not saying BTP is overpriced. I am saying the pricing requires active management, and many organisations underestimate the effort needed to track and optimise BTP costs.

Before you decide

Checklist:

• Inventory of planned extensions and integrations with clear workload descriptions.
• Five-question evaluation completed for each workload.
• Total cost of ownership comparison for the top five workloads, including exit costs.
• BTP credit consumption forecast based on realistic usage estimates.
• Skills assessment for SAP BTP development versus alternative platforms.
• Architecture decision record documenting the rationale for each workload placement.

Questions to ask:

• Your architect: for each planned extension, does it require real-time access to S/4HANA business objects?
• Your team: which non-SAP tools already exist in the organisation that could serve the same function?
• Your SAP account manager: what is the overage rate for BTP credits, and what are the minimum commitment terms?
• Your finance team: what is the annual BTP budget, and what does it cover?
• Your CTO: what is our target SAP dependency ratio in three years, and does BTP move us toward or away from it?

How to measure it

• Workload placement ratio. Percentage of new extensions on BTP versus alternatives, measured quarterly. Owner: enterprise architecture. Leading.
• BTP credit utilisation. Actual versus purchased credits. Baseline: first quarter. Owner: SAP Centre of Excellence. Review: monthly. Leading.
• Integration coverage. Percentage of data flows running through managed, monitored integration paths. Baseline: first inventory. Owner: integration architecture. Review: quarterly. Leading.
• Extension maintenance cost. Annual cost per extension, by platform. Baseline: first year of operation. Owner: application management. Review: annually. Lagging.
• Switching cost estimate. Estimated cost to move each BTP workload to an alternative, updated annually. Owner: enterprise architecture. Review: annually. Lagging.

Mistakes that cost the most

BTP-first as a default policy

Every extension goes to BTP without evaluation.

• Why it happens: it is the path of least resistance with SAP.
• Prevention: require a workload evaluation before platform selection.
• Early warning: non-SAP-specific workloads being built on BTP.

Ignoring exit costs

The extension works well today, but nobody has priced a move.

• Why it happens: exit feels hypothetical until it is not.
• Prevention: estimate exit cost at decision time and record it.
• Early warning: no architecture decision records for platform choices.

Underestimating BTP skill requirements

The team builds on BTP using SAP ABAP skills, but BTP development uses a different toolchain.

• Why it happens: BTP is SAP, so ABAP developers are assumed to cover it.
• Prevention: assess BTP-specific skills — Cloud Foundry, CAP model, Node.js or Java runtimes.
• Early warning: development velocity on BTP is slower than expected.

What to do next

List your next five planned extensions or integrations. Run the five-question test on each. Share the results with your SAP programme lead and your enterprise architect. Then read the related piece on ECC 2027: delete before you migrate and the SAP Clean Core topic page.

Last reviewed: 14 October 2026.

Views are my own and do not represent my employer.