SAP BTP Architecture for S/4HANA Migration Projects

SAP Business Technology Platform is positioned as the extension and integration layer for S/4HANA. In practice, most migration teams encounter BTP as a set of partially overlapping services with inconsistent documentation and overlapping capability claims. This post cuts through the positioning to give you a working architecture model and a clear decision framework for common migration scenarios.

The four pillars — what they actually cover

SAP describes BTP around four capability areas. Here is what each means operationally:

Database and Data Management covers SAP HANA Cloud (a managed HANA instance on BTP), SAP Datasphere (formerly Data Warehouse Cloud — integration and data federation across heterogeneous sources), and the Data Intelligence service for ML pipelines. For migration projects, HANA Cloud is relevant when you need a persistence layer for custom BTP applications that should not touch the S/4HANA database directly.

Analytics covers SAP Analytics Cloud (SAC) with its live connection to S/4HANA via OData, planning capabilities, and embedded AI forecasting. The key migration consideration is whether your current BW or BEx reporting landscape can be gradually replaced with SAC Live or whether you need a full Datasphere-mediated data tier first.

Application Development and Automation is where most extension and remediation work lands. This includes the Cloud Foundry and Kyma runtime environments, SAP Build (low-code/no-code tooling), and the workflow and integration services. This is where you deploy CAP applications, host custom microservices, and run integration flows via SAP Integration Suite.

Intelligent Technologies covers AI Foundation (access to SAP’s ML models), Document Information Extraction, and Business AI features embedded in S/4HANA. Relevant for post-migration automation — not usually in scope for the migration itself.

How BTP connects to S/4HANA

The connectivity model is consistent across all BTP services:

graph LR
    subgraph "SAP BTP"
        CF["Cloud Foundry Runtime\n(CAP / custom apps)"]
        KYMA["Kyma Runtime\n(Kubernetes-based)"]
        IAS["Identity Authentication\nService (IAS)"]
        DEST["Destination Service"]
        CONN["SAP Connectivity\nService + Cloud Connector"]
        INTG["SAP Integration Suite\n(iFlow / API Mgmt)"]
    end

    subgraph "S/4HANA"
        direction TB
        ODATA["Released OData V4\n(CDS-based services)"]
        BAPI_RFC["RFC / BAPI\n(via Cloud Connector)"]
        GRAPH["SAP Graph\n(unified entity model)"]
    end

    CF -->|HTTP + OAuth 2.0| DEST
    KYMA -->|HTTP + OAuth 2.0| DEST
    DEST --> CONN
    CONN -->|SNC-encrypted tunnel| BAPI_RFC
    DEST -->|HTTPS| ODATA
    INTG -->|iFlow| ODATA
    INTG -->|iFlow| BAPI_RFC
    IAS -->|SAML 2.0 / OIDC trust| S4AUTH["S/4HANA OAuth Server"]

    style BAPI_RFC fill:#fa8,color:#000
    style ODATA fill:#8f8,color:#000

The Destination Service is the central configuration store for backend connections. Every CAP service or BTP application uses a named destination rather than hardcoded URLs. For on-premise S/4HANA, the Cloud Connector establishes an outbound-only, encrypted tunnel from the on-premise network to BTP — no inbound firewall rules required.

For S/4HANA Public Cloud (multi-tenant SaaS), destinations are preconfigured via the Managed System setup in BTP Cockpit and authentication happens through OAuth 2.0 with the S/4HANA system as authorisation server.

CAP vs RAP — where each belongs

This is the most common architectural question on BTP migration projects.

RAP (ABAP RESTful Application Programming Model) runs inside the ABAP system. It is the right choice when:

• Business logic must run in the ABAP tier (financial postings, inventory movements, workflow triggers)
• You need transactional consistency with S/4HANA tables
• Your team has ABAP expertise and the use case is transactional

CAP (Cloud Application Programming Model) runs on BTP in Node.js or Java. It is the right choice when:

• You are building a multi-cloud extension that aggregates data from S/4HANA and non-SAP systems
• The extension team works in JavaScript or Java and should not have ABAP access
• The use case is read-heavy analytics, collaboration, or notification — not core transactional

The mistake to avoid: building CAP extensions that replicate S/4HANA business logic by calling RFC or BAPI in sequence to simulate a transaction. CAP consumes S/4HANA data and triggers standard transactional APIs; it does not own transaction control inside the ABAP system.

Cloud Foundry vs Kyma

Both are application runtime environments on BTP. The architectural differences have practical consequences for migration teams:

Dimension	Cloud Foundry	Kyma
Abstraction level	PaaS — push source, CF handles containerisation	Kubernetes — you manage Helm charts and pods
Scaling model	Horizontal, instance-based	Pod autoscaling, HPA
Networking	Route-based, CF internal networking	Istio service mesh, full k8s networking
Best for	CAP applications, standard BTP services	Microservice architectures, custom runtimes, event-driven workloads
Complexity	Lower — suitable for ABAP-background teams	Higher — requires Kubernetes expertise
Event mesh integration	Via SAP Event Mesh service binding	Native via SAP BTP Kyma Eventing

For most S/4HANA migration extension scenarios, Cloud Foundry is the pragmatic choice. Kyma becomes relevant when the organisation already runs Kubernetes workloads and wants to consolidate runtime infrastructure, or when event-driven integration patterns are central to the architecture.

The layered BTP architecture

graph TD
    subgraph "End Users"
        U["SAP Launchpad Service\n(Fiori / custom tiles)"]
    end
    subgraph "BTP Application Layer"
        CAP["CAP Node.js / Java\n(CF or Kyma runtime)"]
        WKFL["SAP Build Process\nAutomation (workflows)"]
    end
    subgraph "BTP Platform Services"
        DEST2["Destination Service"]
        AUTH["Authorization &\nTrust Management (XSUAA)"]
        EM["Event Mesh"]
        IS["Integration Suite\n(API Mgmt / iFlows)"]
    end
    subgraph "Data Services"
        HC["HANA Cloud\n(extension persistence)"]
        DSP["Datasphere\n(federated data)"]
    end
    subgraph "Backend Systems"
        S4["S/4HANA\n(on-prem or cloud)"]
        OTHER["3rd-party / legacy\nsystems"]
    end

    U --> CAP
    U --> WKFL
    CAP --> DEST2
    CAP --> AUTH
    CAP --> EM
    CAP --> HC
    WKFL --> IS
    IS --> S4
    IS --> OTHER
    DEST2 --> S4
    DSP --> S4
    DSP --> OTHER

    style S4 fill:#4a90d9,color:#fff
    style HC fill:#6dbf6d,color:#fff

Where migration projects should start on BTP

A common failure mode is procuring a BTP contract at the start of an S/4HANA program and then spending the first six months exploring services rather than building. A focused starting point:

Month 1–2: Connectivity and identity Establish the Cloud Connector, configure destinations for your S/4HANA development and QA systems, and set up IAS with the ABAP trust configuration. Without this foundation, nothing else works reliably.

Month 2–4: Extension pattern decision Classify your custom development backlog: which items belong in RAP (transactional, ABAP-logic-heavy) and which belong in CAP (integration, aggregation, notifications). Do not build in CAP what belongs in RAP.

Month 4–6: First integration flow Build one real integration scenario end-to-end — typically a business event from S/4HANA (e.g., a sales order created event via SAP Event Mesh) triggering a CAP service action. This surfaces the authentication edge cases, event schema design decisions, and error handling patterns you will reuse across the programme.

Ongoing: Decouple extension deployment from ABAP transport One of BTP’s principal benefits for migration is that BTP extensions can be deployed and updated independently of the ABAP transport cycle. Design for this from the start: the CAP service contract (the OData V4 API it exposes) should be stable, while implementation can be iterated rapidly.

The organisations that extract value from BTP fastest treat it as a deliberate engineering decision — not a platform to explore. Clarity on what S/4HANA owns vs what BTP owns is the architectural prerequisite for everything else.

---

SAP, S/4HANA, ABAP, BTP, CAP, Cloud Foundry, Kyma, and related marks are trademarks of SAP SE.