Clean Core BTP Extension Strategy

Clean core BTP extension strategy is the architectural discipline of extending SAP S/4HANA without modifying the digital core. Every customization, integration, and custom application lives outside the core — on SAP BTP as a side-by-side extension, as a clean-core RAP/ABAP object, or as a BTP-native AI agent — connected via APIs and events. This preserves the S/4HANA upgrade path and is the prerequisite for SAP's AI roadmap.

Use DEBCOR's Clean Core Readiness Assessment at debcor.com/assess/clean-core — a structured self-assessment covering custom code volume, integration complexity, BTP foundation readiness, and migration timeline. Results in 5 minutes. It identifies where your landscape sits across the three extension tiers and what needs to move before S/4HANA cutover or AI agent deployment.

The real architectural choice is on-stack versus side-by-side, not side-by-side versus RAP. RAP (RESTful Application Programming Model) is SAP's programming model for building ABAP services, and it runs in both places. On-stack means ABAP Cloud developer extensibility inside S/4HANA — direct access to business objects, released APIs only, upgrade-stable, and where BAdI implementations and extensions that must sit close to the data belong. Side-by-side means a separate system on SAP BTP that reaches S/4HANA through released APIs and events — with independent scaling, its own lifecycle, and its own release cadence. Same programming model; different deployment, different constraints.

AI agents are the most important clean-core extension category in SAP's current roadmap. Joule agents, custom AI agents, and automation workflows all run on BTP — outside the S/4HANA core, connected via APIs and events. A clean core extension strategy that accounts for AI from the start deploys agents significantly faster: the extension framework, data access patterns, and governance architecture are already in place.

Z-programs fall into three categories: retire (functionality now standard in S/4HANA), remediate (rewrite to be upgrade-safe without BTP migration), or migrate to BTP (rebuild as side-by-side extension or RAP object). DEBCOR classifies every Z-program before migration and builds the extension strategy for those that must move. This classification should start before the migration plan is finalized.

When classifying Z-programs for a clean core migration, every object falls into one of three categories. Retire: the functionality now exists in standard S/4HANA — the Z-program is simply decommissioned, which reduces maintenance burden and upgrade risk. Remediate: the Z-program contains genuine custom logic worth keeping, but it needs to be rewritten using upgrade-safe ABAP patterns (extension points, BADIs, enhancement spots) rather than core modifications. Migrate to BTP: the Z-program represents a capability that belongs as a side-by-side BTP extension or RAP object — rebuilt outside the core and connected via APIs. Getting this classification right before migration is what separates a clean cutover from one that carries technical debt forward.

SAP's ABAP Test Cockpit (ATC) scans your ABAP custom code against the S/4HANA compatibility rules — flagging every object that needs to change before migration can proceed safely. SAP recommends ATC. We treat it as mandatory — we won't scope a remediation without it, because without it the scope is undefined and the timeline is a guess. The analysis should run before the migration plan is finalized, not after. DEBCOR can run and interpret the analysis as a standalone engagement, and can use AI-assisted classification to compress the review cycle significantly.

Z-programs are custom ABAP programs built entirely outside SAP standard — reports, interfaces, conversion programs. User exits are SAP-provided hooks where custom code is inserted without modifying the standard program itself — when implemented correctly, they are upgrade-safe. Enhancements are broader customizations including BADIs, enhancement spots, and implicit enhancements. Together, all three make up your custom code footprint — and all three need to be inventoried and classified before a clean core migration. Not knowing which user exits and enhancements exist in a landscape is one of the most common sources of migration scope surprises.

AI agents run on SAP BTP — which includes SAP Integration Suite. PI/PO is a standalone product and was never a prerequisite for deploying agents. An agent on BTP reaches S/4HANA through released OData, REST and SOAP APIs via the Destination service and Cloud Connector. If you still run PI/PO for existing interfaces, that only means PI/PO itself cannot serve as the agent connectivity layer — it does not block agents from connecting to SAP processes. Modern agentic connectivity is built on Integration Suite and BTP's released API surface, not on PI/PO.