1. The Strategic Motivation for Kyma Migration

While SAP BTP Cloud Foundry remains supported, large enterprises are transitioning critical workloads to SAP BTP Kyma Runtime (Kubernetes) to eliminate key architectural bottlenecks:

• Standard Container Ecosystem: Build custom OCI containers (Docker) with full control over OS packages, specialized native C/C++ libraries, and polyglot runtimes (Python, Go, Rust).
• Istio Service Mesh: Fine-grained mutual TLS (mTLS), distributed tracing, and edge token inspection via APIRules.
• Kubernetes Native Scaling: Scale from zero (serverless) up to massive multi-core workloads without Cloud Foundry container memory ceilings.

2. Translating manifest.yml into Kubernetes Deployments

In Cloud Foundry, apps are defined in manifest.yml:

applications:
  - name: order-service
    memory: 1G
    instances: 2
    services:
      - uaa-shared-auth
      - btp-destination-service

In Kyma, this translates into:

• A Kubernetes Deployment with replicas: 2 and resource limits (memory: 1Gi).
• A Kubernetes Service exposing port 8080.
• ServiceBinding custom resources created by the SAP BTP Service Operator to mount secret credentials.

3. From VCAP_SERVICES to Volume Mounts

In Cloud Foundry, applications parse a gigantic JSON blob injected into the environment variable VCAP_SERVICES. In Kubernetes/Kyma, the SAP BTP Service Binding Operator mounts credentials directly to /etc/secrets/sapcp/<binding-name>/.

Both SAP CAP and the SAP Cloud SDK automatically detect Kyma service bindings when the environment variable SERVICE_BINDING_ROOT=/etc/secrets/sapcp is defined. Zero application code rewrite is required.