The platform inside the platform
SAP Business Technology Platform is the layer that has quietly absorbed the integration, extension, and AI scaffolding work around the S/4HANA estate at most large enterprises. As of early 2026 the platform offers 81 services covering integration, application development, automation, analytics, and AI. The pitch from SAP and the integrator ecosystem is coherent. Build extensions on the platform that already understands S/4HANA. Use the integration patterns SAP has designed for SAP. Avoid the brittle middleware approach that bedevilled the previous generation of SAP estates.
The pitch works on the brochure. The reality at customers two or three years into a BTP deployment is harder to undo. Extensions written in ABAP Cloud and the CAP framework are expensive to migrate to any other platform. Integration patterns built on SAP Event Mesh or Integration Suite couple the customer's broader application landscape to SAP infrastructure. The AI services on BTP create per-call commercial relationships that compound on top of the S/4HANA licence. Published commentary places the switching cost after two to three years of BTP deployment at 50 percent or more of the customer's infrastructure budget. That number is in the same range as the original migration cost. The customer who joined BTP to extend SAP cleanly has built a second migration to do.
This piece is the REFORGE path for the customer who is already inside that second migration.
What BTP actually contains at a typical customer
The 81 services on BTP fall into a small number of families that most customers actually use. Mapping a real BTP footprint is the first step of every REFORGE engagement that touches the platform.
Integration patterns. SAP Integration Suite, SAP Event Mesh, the API Management surface, and the various pre-built content packages that handle SAP-to-SAP and SAP-to-non-SAP flows. At a typical enterprise BTP deployment, this is the family of services the customer is most deeply dependent on. The replacement candidate is the open-standard equivalent — an event bus the customer operates, an API gateway the customer operates, and a deliberate move to standard protocols at every integration boundary.
Extension development. SAP Cloud Application Programming Model, ABAP Cloud, and the various build tools that ship with the platform. The customer who has built CAP-based extensions has built application logic in a runtime that does not exist outside BTP. The replacement is a deliberate rewrite of the extension logic into a runtime the customer's platform team operates, on a language and framework choice the customer makes.
Process automation. SAP Build Process Automation and the workflow surfaces that automate cross-system processes. At a typical customer, these are the workflows that handle approvals, document routing, and the human-in-the-loop processes that span the SAP estate. The replacement is a workflow engine the customer operates.
Analytics. SAP Datasphere, SAP Analytics Cloud, and the data-warehousing services on BTP. These services hold the customer's analytical workloads on infrastructure SAP operates, with commercial terms that scale with consumption. The replacement is the open-format analytics stack covered separately in our Snowflake piece.
AI services. SAP AI Core, the AI Foundation surface, and the various model endpoints SAP markets as the AI-native extension to the platform. The replacement is the model layer the customer chooses, against the data the customer controls.
Identity and authentication. SAP Cloud Identity Services and the various IAM surfaces. The replacement is the IAM stack the customer operates, with the SAP estate as one of the consumers rather than the source of truth.
What the BTP lock-in actually does to the customer
Three structural effects compound over the years of BTP deployment.
Skill investment in proprietary languages. The customer's development team builds expertise in CAP, ABAP Cloud, and the BTP-specific tooling. The skill investment is real and the developers who acquire it are valuable inside the SAP ecosystem. The skill investment also does not transfer cleanly to any other platform. The customer's ability to move work outside BTP is constrained by the skill mix the customer has been hiring against for the BTP years.
Integration coupling. Every integration built on Event Mesh or Integration Suite is an integration that depends on BTP's runtime. The non-SAP systems on the other side of those integrations are coupled to BTP at the protocol level. Removing BTP means rebuilding every coupled integration. The cost of the rebuild scales with the number of integrations the customer has built on BTP-specific patterns.
Commercial commitment compounding. The BTP commitment compounds against the S/4HANA commitment. Each renewal cycle, the customer is negotiating two interdependent contracts with the same vendor. The leverage on either contract is structurally limited by the dependency on the other.
The REFORGE sequence
The sequence we run for a BTP-deep customer takes 18 to 24 months. The S/4HANA core stays in place for the entire duration. The BTP services retire on a workflow-by-workflow schedule.
Quarter one — the integration surface. The most important first move is the integration surface, because every subsequent move depends on the integration boundary the customer operates. The customer's chosen event bus and API gateway are stood up in parallel with the existing BTP integration footprint. New integrations land on the customer-owned surface. Existing integrations migrate on a fixed cadence. The Event Mesh and Integration Suite footprint shrinks against the schedule.
Quarter two — the extension runtime. The CAP and ABAP Cloud extensions are inventoried, prioritised, and rewritten into the runtime the customer's development team operates. The rewrite is not the academic version that aims for a like-for-like port. It is the working version that captures the business logic the extension provides and ships it on the customer's platform. The customer's developers learn the new runtime in the course of the work. The skill mix shifts during the engagement.
Quarter three — process automation. The workflow engine the customer operates absorbs the workflows previously running on SAP Build Process Automation. The human-in-the-loop steps are designed against the user experience the customer's operations teams want, not against the BTP-vended surface. The workflows ship in batches, with each batch retiring a portion of the BTP commitment.
Quarter four — analytics and the data layer. The data-warehouse workloads on Datasphere, the dashboards on Analytics Cloud, and the underlying data-engineering pipelines move to the open-format stack the customer operates. This is the work we have written about separately in the Snowflake piece; the BTP-deep customer follows the same architecture with the additional consideration of unwinding the Datasphere commitment.
Quarter five — AI services. The AI workloads on BTP migrate to the model layer the customer chooses. The replacement is straightforward when the data layer has already moved. The customer's evaluation suite, prompt management, and observability are stood up against the AI workloads in the same pattern we use for every agentic engagement.
Quarter six — identity and authentication. The IAM consolidation moves last because the other workflows depend on it. The SAP estate becomes one of many consumers of the customer's IAM stack rather than the source of identity for the entire enterprise.
Quarter seven and eight — cleanup and handover. The residual BTP services that the customer chooses to retain are documented, the integration boundaries are formalised, and the platform engineering team takes ownership of the running stack. The BTP licence at the next renewal reflects the smaller footprint.
What stays on SAP
The S/4HANA core. The financial postings. The procurement workflow. The regulated transaction recording. The reporting that goes to the supervisory authority. The integrator's work on the core stays where it is. The customer is not retiring SAP. The customer is unwinding the second migration that BTP created.
The Middle East dimension
Middle East customers running BTP carry an additional consideration around data residency. BTP services run on hyperscaler regions chosen by SAP. Customers with regulatory expectations about where their workloads run face a structurally limited choice. The REFORGE sequence above gives the customer the freedom to choose the hosting posture for each workflow independently, against the regulatory posture the customer has agreed with the supervisor.
The saasinator perspective
BTP is not a bad platform on the merits. The services are competent and the integration patterns are mature. The argument is not against the platform. The argument is against the commercial structure that turns a clean extension layer into a second renewal lock-in. The customer who joined BTP to extend SAP cleanly did the rational thing at the time. The customer who recognises three years later that the second migration is a separate decision is doing the rational thing now.
The REFORGE sequence is reversible at every stage. The customer who runs the integration-surface quarter has not committed to the extension-runtime quarter. The customer who runs the extension-runtime quarter has not committed to anything else. Each quarter is justified on its own.
What to bring to the diagnostic
If your enterprise has a BTP footprint of 12 to 24 months or more, the conversation worth having is the integration-surface inventory. Bring the BTP services list, the integration-pattern inventory, the extension catalogue, and the current commercial commitment. The diagnostic is ten working days. The output is the workflow recommendation, the architecture sketch, and the first-quarter scope.