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 customisation, 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.

A side-by-side extension is a full application or agent built on SAP BTP that connects to S/4HANA via APIs and events — no ABAP required, full technology choice. A RAP extension (RESTful Application Programming Model) is clean-core ABAP inside the ABAP Environment on BTP — custom business logic written in modern ABAP that follows SAP's extension framework, is upgrade-safe, and connects natively to S/4HANA data.

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 finalised.

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. It is a mandatory step. Without it, the scope of custom code remediation is undefined and any migration timeline is a guess. The analysis should run before the migration plan is finalised, 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 customisations 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.

SAP Integration Suite (on BTP) is the connectivity layer AI agents use to access SAP data and execute actions via MCP. PI/PO is the predecessor middleware and does not support MCP connectivity — it cannot serve as the agent integration layer. Organisations still running PI/PO cannot deploy AI agents that connect to SAP processes until the migration to Integration Suite is complete. The PI/PO to Integration Suite migration should be scoped as a prerequisite to AI agent deployment, not a separate future project.