JinJin48
JinJin48
SAP Consultant | BTP · S/4HANA · US Global Rollout
· 14 min read

Cover infographic showing the three independent axes of every SAP BTP deployment: Runtime, Infrastructure, and Procurement.

TL;DR
  • Every SAP BTP deployment is defined by three independent axes: the runtime that hosts the workload, the infrastructure that runs the runtime, and the procurement model that pays for it.
  • The three axes are orthogonal — choosing Cloud Foundry does not lock you into Azure, and buying through AWS Marketplace does not force you to host on AWS.
  • 2025 and 2026 added three structural shifts: Hyperscaler Marketplace availability (GA September 2025), SAP-owned datacenters (mid-2025 onward, target eight by end of 2026), and Sovereign Cloud On-Site (September 2025).

Introduction

If you have read BTP-001 for the platform overview, BTP-002 for the architecture, and BTP-003 for the capability map, the next question on any real project is operational: “Where does this actually run, and how do we buy it?”

That is the question this article answers. The single phrase “deployment model” hides three independent decisions, and conflating them is one of the most common sources of confusion in BTP project design. This article separates those decisions, defines each one, and then shows how the 2025–2026 updates from SAP change the menu of options at every layer.

1) The Three Axes of a BTP Deployment

Hub-and-spoke diagram showing BTP Deployment at center connected to three axes: Runtime, Infrastructure, and Procurement.

AxisQuestion It AnswersExample Choices
RuntimeWhat hosts my workload?Cloud Foundry, Kyma, ABAP environment, Neo (deprecated)
InfrastructureWhere does that runtime physically run?AWS, Azure, GCP, Alibaba Cloud, SAP-owned datacenter, customer site (Sovereign Cloud On-Site)
ProcurementHow was the deployment bought?Trial, Free Tier, PAYG, BTPEA, RISE bundle, Hyperscaler Marketplace

These axes are orthogonal. A Cloud Foundry workload running on Microsoft Azure that was procured through the AWS Marketplace is a perfectly valid combination — the marketplace is a procurement channel, not a hosting location. A team that learns these axes as one bundled “deployment model” will keep tripping over decisions that do not actually belong to the same layer.

The runtime menu itself is well-defined: SAP BTP today supports three actively maintained runtimes (Cloud Foundry, Kyma, and the ABAP environment), with the legacy Neo runtime in long-term sunset, as documented in the SAP Community runtime overview.

The remaining sections walk through each axis in turn, then close with the 2025–2026 narrative shifts.

2) The Runtime Axis

Spectrum diagram of SAP BTP runtimes from Cloud Foundry to Kyma to ABAP environment to Neo deprecated.

Runtimes are the execution environments that host application code on SAP BTP. SAP today supports three actively maintained runtimes plus one in long-term sunset.

Cloud Foundry

Three-column diagram of Cloud Foundry on SAP BTP across AWS, Azure, and GCP, with shared buildpack and auto-scaling features.

The Cloud Foundry environment is based on the open-source Cloud Foundry application platform. Developers focus on writing code; the platform handles container build, routing, networking, and scaling automatically. Cloud Foundry supports any language for which a buildpack exists — official SAP buildpacks, Cloud Foundry Foundation buildpacks, and community buildpacks all work, as documented in the SAP Community runtime walkthrough.

Cloud Foundry on SAP BTP is available on three hyperscalers: AWS, Microsoft Azure, and Google Cloud. It remains, by deployment count, the most widely used SAP BTP runtime.

Kyma

Two-column comparison of Cloud Foundry and Kyma runtimes on SAP BTP, highlighting simplicity versus control and shared non-functional parity.

The Kyma environment is a fully managed Kubernetes runtime based on the open-source Kyma project. Compared with Cloud Foundry, Kyma exposes more low-level control: developers can shape network policies, deploy custom CRDs, and operate at the pod level. The SAP-samples multi-tenant SaaS reference documents Kyma as the recommended choice for highly scalable applications, advanced network-security requirements, teams with deep Kubernetes expertise, and multi-application scenarios where the cost of a managed Kubernetes cluster is justified.

Kyma is available on four hyperscalers: AWS, Microsoft Azure, Google Cloud, and Alibaba Cloud — one more than Cloud Foundry. Its free plan has an important limit: only one Kyma free plan per global account, capped at 30 days, per the SAP Help Portal trial documentation.

ABAP Environment

Hierarchy tree of the ABAP environment on SAP BTP showing its lineage from S/4HANA Cloud and its support for RAP, Fiori, and CDS.

The ABAP environment, sometimes informally called Steampunk, is built on the same ABAP platform cloud release that powers SAP S/4HANA Cloud. It supports the ABAP RESTful Application Programming Model (RAP), including SAP Fiori and Core Data Services (CDS). For organizations with significant ABAP investment, this is the path that preserves existing skills while moving the runtime to the cloud.

The trade-off, noted in the same SAP Community walkthrough, is that the ABAP environment offers less application isolation than Cloud Foundry or Kyma. Resources are shared across the environment, similar to a traditional ABAP NetWeaver server.

Neo — Deprecated

Neo is the original SAP-proprietary runtime, available since 2012. It is not a viable choice for new development. SAP has announced Neo will sunset on December 31, 2028, subject to customer or partner contract terms, per SAP’s own community guidance. Cloud Foundry, Kyma, and the ABAP environment together cover every use case that Neo supported.

Combining Runtimes

Hub-and-spoke diagram showing one BTP global account hosting both Cloud Foundry and Kyma subaccounts in parallel.

The runtime choice does not have to be binary. The SAP Help Portal comparison document explicitly states that Cloud Foundry and Kyma can be combined within a single architecture, and that workloads can be added to either runtime as scaling needs grow. Both runtimes are managed by SAP, both run on multi-availability-zone infrastructure, and both offer identical SLA levels — so the decision is driven by application architecture, not by non-functional differences.

3) The Infrastructure Axis

Matrix of four BTP infrastructure options: hyperscaler-hosted, SAP-owned datacenter, sovereign cloud on-site, and customer-hosted Kubernetes.

Once the runtime is chosen, the next question is where that runtime physically runs. This is the infrastructure axis.

Hyperscaler Hosting

Most SAP BTP services historically run on hyperscaler infrastructure managed by SAP. The hyperscaler choice determines which BTP regions are available and where the data physically resides. Cloud Foundry runs on AWS, Microsoft Azure, and Google Cloud. Kyma additionally runs on Alibaba Cloud.

The current per-region availability of services shifts frequently as SAP rolls out capacity. The authoritative live list is maintained on the SAP Help Portal Regions page; consultants and architects should consult it directly rather than rely on any static enumeration.

SAP-Owned Datacenters

Timeline of SAP-owned datacenter rollout from 2024 announcement to mid-2025 Frankfurt launch to 8 DCs target by end of 2026.

In October 2024 SAP announced a new addition to its datacenter strategy: starting mid-2025, SAP began offering SAP BTP (Multi-Cloud Foundation) from SAP-owned datacenters, beginning with Frankfurt, Germany. The SAP Community announcement sets a target of eight SAP-operated BTP datacenters by the end of 2026, with country plans spanning Germany, the United Arab Emirates, the United States, Japan, China, and Australia.

The driver is data sovereignty. Country-specific regulations — and in many cases internal corporate policies — increasingly require that operational responsibility for the underlying datacenter sit with SAP rather than with a third-party hyperscaler. The SAP-owned option exists to satisfy that requirement.

Sovereign Cloud On-Site

Layered diagram of Sovereign Cloud On-Site showing customer facility hosting SAP-managed infrastructure that runs BTP services.

In September 2025, SAP launched Sovereign Cloud On-Site. This is the most extreme end of the data-residency spectrum: SAP-managed infrastructure placed inside the customer’s own physical facilities, as documented in IgniteSAP’s coverage of the hybrid SAP landscape. The target market is defense, financial services, healthcare, and public sector workloads that, for legal or operational reasons, cannot sit on shared hyperscaler infrastructure under regulations such as GDPR, HIPAA, FedRAMP, and their national equivalents.

Public technical detail on Sovereign Cloud On-Site is still limited at the time of writing. For most enterprises, it is mentioned here for completeness — the relevant question to ask is whether your specific compliance regime actually requires it, because it sits outside the standard BTP catalog.

Customer-Hosted Workloads Consuming BTP Services

There is one additional pattern worth naming, even though it does not host BTP itself. A customer can run application workloads on their own hyperscaler-managed Kubernetes cluster (AWS EKS, Azure AKS, GCP GKE) and consume SAP BTP services from those workloads using the SAP BTP Service Operator, a Kubernetes operator that exposes BTP services to Kubernetes-native tooling. This pattern is sometimes described as “BTP services on any hyperscaler” — but precisely, the BTP services still run on SAP-managed infrastructure. Only the consuming workload is on the customer-owned cluster.

4) The Procurement Axis

Spectrum of six SAP BTP procurement channels: Trial, Free Tier, PAYG, BTPEA, RISE bundle, and Hyperscaler Marketplace.

The third axis is how the deployment is purchased and operated. The procurement choice has no direct effect on which runtime hosts the workload or which hyperscaler runs it underneath — it is a commercial channel, not a hosting decision.

Trial Account

A trial account is the cheapest way to evaluate SAP BTP. It is free, time-limited, and explicitly non-commercial. Per the SAP Help Portal trial documentation, a trial account runs for 90 days total, suspends after 30 days (extendable), provides 4 GB of application memory, 8 GB of instance memory, 10 routes, 40 services, and 2 cloud-connector on-premise systems, with no SLA. It cannot be used for production. Crucially, a trial account cannot be upgraded — to move beyond it, the customer must register for an enterprise account separately.

Free Tier

Free tier is a commercial model — not a free account. It is accessed by signing up for the SAP BTP Enterprise Agreement (BTPEA) or Pay-As-You-Go for SAP BTP, and gives the customer a productive account with no time limit, with access to over 90 services across paid, free tier, and “always free” plans. Free tier accounts can graduate from free to paid plans without re-provisioning, which trial accounts cannot.

Pay-As-You-Go and BTPEA

The two primary commercial models for an enterprise account are Pay-As-You-Go (PAYG) and the SAP BTP Enterprise Agreement (BTPEA). The detailed differences belong in BTP-005 on licensing; for the purpose of this article, both are vehicles that gate access to free tier and to marketplace procurement.

RISE with SAP

RISE with SAP is a bundled subscription that includes S/4HANA Private Cloud, SAP Enterprise Support, BTP credits, and managed infrastructure on one of three hyperscalers (AWS, Azure, or GCP). The RISE Order Form fixes the hyperscaler choice, which then determines BTP credit availability, which BTP regions are accessible, and how data egress is priced, as the SAP Licensing Experts 2026 RISE guide details. The BTP component inside a RISE deal is not technically different from BTP procured directly — but it is contractually entangled with the rest of the bundle, and the commercial implications belong in the licensing discussion (BTP-005).

Hyperscaler Marketplace

Hub-and-spoke diagram of SAP BTP at the center with three hyperscaler marketplace channels: Azure, AWS, and Google Cloud.

The newest procurement channel is the hyperscaler marketplace. Announced at SAP Sapphire Orlando 2025 and reaching general availability in the United States in September 2025, this option lets customers purchase SAP BTP services through the Microsoft Azure, Amazon Web Services, and Google Cloud marketplaces using existing committed cloud spend agreements (Azure MACC, AWS EDP, Google CUD), per SAP’s official announcement.

The benefits are commercial: existing cloud commitments can be drawn down toward BTP, procurement uses familiar marketplace workflows, and billing is consolidated through the hyperscaler. The mechanism still requires a CPEA-style spend agreement with SAP first; the marketplace is a draw-down channel, not a stand-alone PAYG path. And as covered in the SAPinsider multi-cloud strategy article, the marketplace channel does not change the fact that BTP tenants are still administratively SAP-managed, even when they share datacenters with the customer’s own hyperscaler resources.

5) Account Hierarchy: How Deployments Are Organized

Hierarchy tree of SAP BTP account organization: Global Account at top, branching to Directories and Subaccounts, then to Cloud Foundry Org and Spaces.

Within any procurement model, the account structure follows the same hierarchy. The SAP BTP onboarding tutorial describes it as: Global Account → optional Directories → Subaccounts → (for Cloud Foundry only) Org → Spaces.

LevelRole
Global AccountThe realization of the contract with SAP. Region-independent. Manages subaccounts, members, and quotas.
DirectoryOptional grouping layer for subaccounts. Can contain other directories (hierarchy).
SubaccountTied to a region. The unit at which environments and entitlements are activated.
Org / SpaceCloud Foundry only. One org per subaccount; spaces subdivide that org.

Entitlements and quotas are managed at the global account level, distributed to directories and subaccounts, and consumed by subaccounts. Removing a quota from one subaccount returns it to the global pool, where it can be reassigned. Each subaccount is associated with a region — the physical datacenter location — and the user’s own geographic location does not have to match. This is the lever that makes the runtime axis and the infrastructure axis compose: a customer in Tokyo can operate a Kyma subaccount on Azure US East and a Cloud Foundry subaccount on AWS Singapore from the same global account.

6) What’s Changed in 2025–2026

Three-column summary of 2025-2026 SAP BTP shifts: Hyperscaler Marketplace, SAP-owned datacenters, and Sovereign Cloud On-Site.

Three structural shifts in 2025 and 2026 expand the menu of deployment options without invalidating any earlier choices.

ShiftWhenWhat Changed
Hyperscaler MarketplaceGA September 2025 (US)BTP procurement now possible through Azure / AWS / GCP marketplaces, drawing down committed cloud spend.
SAP-owned datacentersmid-2025 onwardFirst location: Frankfurt. Target: 8 SAP-operated BTP DCs by end of 2026, spanning Germany, UAE, USA, Japan, China, Australia.
Sovereign Cloud On-SiteAnnounced September 2025SAP-managed infrastructure inside customer-owned facilities for data-sovereignty-bound workloads.

These shifts all sit on the infrastructure and procurement axes — none of them changes the runtime axis, as confirmed by SAP’s official marketplace announcement. Cloud Foundry, Kyma, and ABAP remain the three active runtimes; Neo continues its sunset to December 31, 2028.

The practical implication is that BTP is becoming more flexible at the edges of the buying decision (where commercial terms meet hyperscaler relationships) and at the edges of the hosting decision (where sovereignty rules meet datacenter operations), without disrupting the runtime choices that already-built BTP applications depend on.

Summary

A BTP deployment is best understood through three independent axes — runtime, infrastructure, and procurement — each of which is a separate decision. Most architectural mistakes on real projects come from collapsing these axes into a single “we picked Azure” or “we’re on RISE” framing, which loses signal that matters when a future requirement crosses an axis boundary.

Cloud Foundry and Kyma cover the bulk of cloud-native workloads, with the ABAP environment as the right answer for ABAP-centric extension scenarios. Hyperscaler hosting remains the dominant infrastructure choice, with SAP-owned datacenters and Sovereign Cloud On-Site as the answer when sovereignty rules require them. Hyperscaler Marketplace, available in the US since September 2025, joins trial, free tier, PAYG, BTPEA, and RISE as an additional procurement channel — not a replacement for any of them.

The practical takeaway for SAP architects in 2026: treat the three axes as a planning checklist on every new BTP initiative. Decide the runtime first based on workload character, the infrastructure second based on data residency and existing cloud relationships, and the procurement model last based on commercial terms. Doing them in that order keeps each decision focused on the question it actually answers.

FAQ

Q: If I pick AWS as my hyperscaler, am I locked into AWS marketplace for procurement? A: No. The infrastructure axis (where BTP runs) and the procurement axis (how it is bought) are independent. You can host on AWS and procure through the Azure marketplace, or vice versa, as long as you have the underlying SAP spend agreement in place.

Q: Can I run the same application on both Cloud Foundry and Kyma? A: Not the same instance, but you can split a workload across both runtimes within the same global account. The SAP Help Portal explicitly recommends combining the two for scenarios where parts of the application benefit from Cloud Foundry’s simplicity and other parts need Kyma’s Kubernetes-level control.

Q: Is the trial account the same as free tier? A: No. Trial is a 90-day non-commercial evaluation account that cannot be upgraded and cannot be used for production. Free tier is a commercial model — accessed via BTPEA or PAYG — that has no time limit and supports productive use, with the option to graduate to paid plans without re-provisioning.

Q: What happens to my Neo workloads after December 31, 2028? A: SAP has announced Neo will sunset on that date, subject to individual customer and partner contract terms. The migration target is Cloud Foundry, the ABAP environment, or Kyma depending on the workload. The “subject to contract terms” language means specific exit dates may differ between customers — confirm yours directly with SAP.

Q: Does Hyperscaler Marketplace availability mean I can spin up BTP from scratch with pure pay-as-you-go through AWS? A: No. Marketplace procurement still requires a CPEA-style spend agreement with SAP first. The marketplace is a draw-down channel against existing committed spend, not a stand-alone PAYG entry point.

References

  1. SAP Help Portal — Comparison: SAP BTP, Kyma Runtime and SAP BTP, Cloud Foundry Runtime (PDF) — accessed 2026-05-06
  2. SAP Help Portal — Trial Accounts and Free Tier — accessed 2026-05-06
  3. SAP Tutorial — Take a Tour of SAP BTP Trial — accessed 2026-05-06
  4. SAP-samples — btp-cap-multitenant-saas (Cloud Foundry vs Kyma) — accessed 2026-05-06
  5. SAP-samples — Deploy Fiori on Any Hyperscaler (BTP Service Operator) — accessed 2026-05-06
  6. SAP Community — Expanding Horizons: Hyperscaler Partners and SAP-Owned Datacenters — accessed 2026-05-06
  7. SAP Community — SAP BTP Now Available on Microsoft Azure, AWS, and Google Cloud Marketplaces — accessed 2026-05-06
  8. IgniteSAP — The Hybrid SAP Consultant (Sovereign Cloud On-Site) — accessed 2026-05-06
  9. SAP Community — SAP BTP Environments: Cloud Foundry vs ABAP vs Kyma — accessed 2026-05-06
  10. SAP Community — SAP BTP Runtimes Personal Considerations — accessed 2026-05-06
  11. SAPinsider — Embracing a Multi-Cloud Strategy with SAP BTP — accessed 2026-05-06
  12. SAP Licensing Experts — RISE Hyperscaler Choice Guide 2026 — accessed 2026-05-06

This site organizes BTP knowledge into the following structure:

L1. Big PictureL2. Functional Domains
BTP-001 What is BTPL2-A. Integration
BTP-002 BTP ArchitectureL2-B. Application Development & Automation
BTP-003 BTP Capability MapL2-C. Data & Analytics
BTP-004 Deployment Models (this article)L2-D. AI
BTP-005 Licensing ModelsL2-E. Foundation Services
BTP-006 Clean Core StrategyL2-F. Architecture & Operations
L2-G. Use Cases & Patterns