SAP BTP explained: Business Technology Platform

Written by an SAP Finance & Treasury practitioner working with SAP since 2008 · how the guides are written · Updated 10 October 2026 · facts checked against the SAP Help Portal, SAP Learning and sap.com, October 2026

SAP BTP (SAP Business Technology Platform) is SAP's platform-as-a-service for building, extending and integrating around SAP applications rather than inside them. One account model holds everything it offers.

Since May 2026 BTP has a wider frame around it: SAP Business AI Platform, SAP's name for BTP, its data cloud and its AI foundation offered as one. In October 2026 SAP's own pages count what BTP does as a core piece of it, and the solution architect certification is being renamed to match. The accounts, runtimes and services described here are the same ones.

The older Neo environment reaches end of life on 31 December 2028, as SAP announced in 2023: Neo contracts cannot be renewed past that date, so any application still on Neo has to move to one of the three runtimes first. The BTP section of the SAP Help Portal documents every runtime and service.

What is SAP BTP?

SAP BTP is SAP's cloud platform for the work that belongs beside an SAP system rather than in it: custom applications, extensions to S/4HANA and the cloud suites, interfaces between systems, workflow and automation, data warehousing and analytics, and the AI services those applications call. Nothing on the platform posts a document or closes a period; it is where the things around the core are built, connected and run. On the platform sit three application runtimes (Cloud Foundry, Kyma, the ABAP environment), the SAP Integration Suite, SAP HANA Cloud, and analytics and AI services, hosted in AWS, Microsoft Azure, Google Cloud and Alibaba Cloud regions.

The platform has carried three names: HANA Cloud Platform, then SAP Cloud Platform (SCP), then Business Technology Platform when SAP folded the data, analytics and AI products under one umbrella in 2021. Job adverts and older documents still say "SAP Cloud Platform", and a CV that does is describing the same work. Two further services turn up under this heading in practice: SAP Document AI, still listed as Document Information Extraction in older adverts, which turns scanned documents into fields (SAP Help Portal), and Joule, SAP's generative AI assistant, which is provisioned and configured through BTP even though users meet it inside the applications (what Joule is, per SAP; what it changes for each role is in how AI is changing SAP work). The data row is the platform half of the analytics area.

How is a BTP account structured?

A BTP account is a global account that holds the commercial agreement and the pool of entitlements, optional directories that group what sits beneath it, and subaccounts, which are the unit that matters. Each subaccount is pinned to a single region and hyperscaler, carries its own trust configuration with an identity provider, its own destinations, its own role collections, and its own slice of the entitlement pool as quota. The account model is the first thing to learn, because it decides what can be deployed at all.

Two consequences follow. When an application deploys in development and nowhere else, the cause is almost always a target subaccount that was never entitled to the service plan the application calls — a commercial fact wearing a technical error message. And because the region is fixed at creation, data residency is decided before a line of code is written.

How is SAP BTP priced, and how do you keep the cost under control?

SAP BTP is sold under consumption-based agreements or as a subscription, and which one a company signed decides how the platform team has to watch its spend. As of October 2026, SAP's pricing page and its training describe four commercial models.

Two free options sit beside these. The trial is a non-commercial account that is shut down, with everything in it, after 90 days. The free tier is a set of free service plans inside a BTPEA or Pay-As-You-Go account, with no time limit, so work can move to a paid plan without being rebuilt. Cost control on BTP, the work usually filed under FinOps, rests on three things SAP provides: the cockpit shows actual consumption for the global account and each subaccount, a monthly balance statement reports what was charged against the credits, and the SAP Discovery Center lists service prices and has an estimator for planning. The habit that matters most is assigning entitlements to subaccounts deliberately, because a quota nobody granted cannot be consumed.

Cloud Foundry, Kyma or the ABAP environment?

Choose Cloud Foundry by default, Kyma when the team already runs Kubernetes, and the ABAP environment when the people who will maintain the code are ABAP developers. Three runtimes coexist, and in practice the choice is made by the skills already in the building rather than by a technical scorecard.

Two things the table cannot show. A Kyma cluster needs a named owner, because the operational burden is genuinely higher than pushing an app to Cloud Foundry. And the ABAP environment is not the same thing as ABAP Cloud inside an S/4HANA system, which is on-stack developer extensibility rather than a separate platform. SAP's own comparison of the first two is in "Cloud Foundry, Kyma, or Both?" on the SAP Help Portal.

What does SAP BTP development involve?

SAP BTP development is building applications and extensions on the platform, and it comes in three styles. CAP (the SAP Cloud Application Programming Model) is the framework for services written in Node.js or Java, with the data model and the service defined in CDS and the result deployed to Cloud Foundry or Kyma. RAP (the ABAP RESTful Application Programming Model) is its counterpart in the ABAP environment, written in ABAP Cloud. SAP Build is the low-code family — SAP Build Process Automation and SAP Build Work Zone, plus SAP Build Apps, which, as of October 2026, SAP is retiring as a product of its own — joined by SAP Build Code, the offering for professional developers that bundles the CAP and SAPUI5 tooling with Joule's code generation.

SAP Business Application Studio is the browser-based development environment where most CAP and SAPUI5 work is done; ABAP is written in ABAP Development Tools. Whichever style a team picks, the hard part is seldom the framework: it is knowing which released APIs and events of the SAP system being extended the code may rely on.

What is the SAP Integration Suite?

The SAP Integration Suite is BTP's integration platform, the successor to SAP Process Integration and Process Orchestration (PI and PO), and the piece with the widest reach, because every landscape has interfaces whether or not it has custom apps. It is a set of capabilities under one subscription rather than a single tool: Cloud Integration for the integration flows themselves, with the adapter set that decides which systems you can reach; API Management for proxying, throttling, key management and a developer portal; Event Mesh for publish-and-subscribe messaging; Open Connectors for third-party applications nobody wants to write an adapter for.

One detail saves arguments. Edge Integration Cell is a runtime that executes integration flows inside the customer's own network while the design and monitoring stay in the cloud — the standard answer to a data-residency or latency objection that would otherwise stop a migration from Process Orchestration entirely.

How does BTP connect to S/4HANA?

Through the Cloud Connector, destinations and principal propagation, in that order. The Cloud Connector is a small component installed inside the customer's network that opens an outbound tunnel to a named subaccount, so no inbound firewall port is required, and exposes only the resource paths listed explicitly in its access control list. That list is why a call fails with a 403 that no amount of code review explains. Destinations then hold the target, the protocol and the authentication type, and the application reads a destination by name rather than a hostname.

Identity is the other half. The subaccount has its own OAuth authorization server; applications describe their permissions as scopes, those become roles, roles are gathered into role collections, and role collections are mapped to groups coming from the corporate identity provider through SAP Cloud Identity Services. Principal propagation — carrying the named end user, not a technical account, all the way into the backend using a short-lived certificate — is the single configuration most often underestimated in a plan, and the one that decides whether backend authorization checks and audit trails mean anything. Role collections also put part of authorizations on the platform side, where the builder often ends up owning it (which combinations work).

When is an extension in-app, and when on BTP?

In-app when the requirement is a field, a validation or a small piece of logic on a standard object that key-user or developer extensibility can express; on BTP when it needs its own data model, user interface, integrations or release cycle. From the platform's side the difference is runtime and staffing: a key-user extension ships with the system and has no deployment, monitoring or on-call of its own, while a side-by-side app owns all of those, which means a team that can run it after the programme leaves. The decision itself — which extensibility option a requirement belongs in and why — is the subject of the clean core guide. Making that call repeatedly turns a builder into an architect, and it shapes the custom-code work in an S/4HANA conversion (what S/4HANA means for a career).

The test that settles most cases is whether every SAP object the extension depends on is released with a stability contract behind it. If not, there are three honest moves: request the API, redesign the requirement, or record that this piece is outside the rule and who owns its upgrade cost.

What does a week on a BTP project look like?

Early weeks are extensibility workshops; middle weeks are service-and-Fiori build with connectivity setup; cutover weeks are entitlements, destinations and role collections. The rhythm follows the phase, not the calendar.

• Design — what stays standard, what becomes a key-user extension, what becomes a side-by-side app, and who holds the entitlements.
• Build — the service and its data model, the Fiori front end, destinations, role collections, and a transport route that matches how the programme is structured.
• Test — connectivity is where it hurts: the Cloud Connector, principal propagation, an expired service key.
• Cutover — production quotas, destinations repointed, subscriptions and role collections assigned.
• Run — platform services update on SAP's cadence, not the programme's, so a BTP app is maintained continuously, not frozen between upgrades (the AMS side).

Promotion between subaccounts is nothing like a classic transport route: a pipeline builds the archive, Cloud Transport Management moves it, and the target subaccount must already hold the entitlements it expects, or the deployment succeeds and the application still cannot start.

Who works on BTP, and where do they come from?

A first delivery is usually three to six people, and the seats are recognisable even when one person holds two of them: a platform owner for accounts, entitlements and identity trust; an application developer in CAP or the ABAP environment; a Fiori developer (the Fiori and UX roles); an integration developer for the Integration Suite; and somebody named to operate the result. The characteristic staffing mistake is filling every build seat and none of the last one, which produces an application nobody can patch six months later. Each runtime recruits from a different pool.

• From ABAP — released APIs and ABAP Cloud instead of modifications, the model an ABAP developer interview now centres on; the shortest move (the developer route).
• From outside SAP — cloud developers arriving through CAP, JavaScript and Fiori; the working stack is Git, CI and APIs, so day one needs less SAP vocabulary.
• From Basis — platform operations is landscape work in a new place (the Basis route).
• From a functional area — owning the extension backlog long enough to own its platform side (crossing the divide).

Evidence beats vocabulary: an app in production, an interface you built and operated. Interviews go straight at connectivity and lifecycle — how an on-premise service reaches a cloud app, how identity travels with it (what interviews test). A trial account produces showable work before a first project.

What is SAP BTP not?

BTP is not a business application: nothing on it posts a document, and a side-by-side app built on a broken core process decorates the problem. It is not a way around the on-premise dependency, because reaching a backend still needs a Cloud Connector someone installs and patches. It does not make integration cheap; the mapping, error handling and reprocessing cost what they always cost. It does not replace Basis or security, since quotas, certificates and role collections are operations work with new names. And it is not a project with a go-live — there are applications, interfaces and services, each with its own lifecycle and each deprecated on SAP's calendar, not the customer's.