On-Premises Extensions
Extensibility for S/4HANA On-Premise deployments — the most flexible but most governance-intensive environment. All three tiers are available, but Clean Core compliance requires deliberate enforcement via ATC, governance processes, and architectural discipline.
Architecture Overview
Executive Summary
S/4HANA On-Premise gives the most extension flexibility — all three tiers are available, including full ABAP developer access. However, this flexibility is also the biggest risk: without enforced Clean Core governance, on-premise systems accumulate technical debt (modifications, unreleased API usage, direct table access) that makes upgrades expensive. The on-premise Clean Core journey requires more deliberate process enforcement than PCE or Public Cloud.
On-Premise Clean Core Journey
| Phase | Activity | Timeline |
|---|---|---|
| 1. Assess | Run Clean Core Assessment tool. Count modifications, violations, custom objects. Classify each. | 4-8 weeks |
| 2. Freeze | Stop all new non-clean-core development. Set ATC transport gate. | Immediate |
| 3. Migrate | Convert existing custom code to ABAP Cloud (CDS views, released APIs, RAP). | 12-36 months |
| 4. Enforce | ATC in CI/CD. Cloud ALM tracking. Quarterly Clean Core health report. | Ongoing |
| 5. Upgrade | S/4HANA 2025 OP with minimal regression effort. | Every ~2 years |
Cloud Connector — BTP Connectivity
Cloud Connector is installed in the DMZ and creates a secure reverse-proxy tunnel between the BTP Connectivity Service and the on-premise S/4HANA system. Access control defines an explicit allowlist of exposed paths — all other paths are denied by default.
# Cloud Connector Access Control — expose S/4HANA OData APIs to BTP
# Configured in Cloud Connector Admin UI (https://localhost:8443)
# Virtual host mapping:
# Virtual: s4hana-prod (virtual hostname visible from BTP)
# Physical: actual-s4h.dewa.local:44310 (internal hostname)
# Allowed resources (explicit allowlist — deny by default):
# Path: /sap/opu/odata/sap/
# Accessible: Yes — all subpaths
# (This exposes all OData V4 APIs from S/4HANA standard namespace)
# Path: /sap/opu/odata4/sap/
# Accessible: Yes — OData V4 services
# Block all other paths (default behaviour):
# Direct table access: NOT accessible
# Internal RFC paths: NOT accessible (use released RFCs only if needed)ABAP Migration Example — Classic to ABAP Cloud
" ❌ BEFORE — Classic ABAP (non-clean-core):
" Direct SELECT on SAP table + CALL FUNCTION
SELECT vbeln soldto netwr waerk
FROM vbak " Direct table SELECT — forbidden
INTO TABLE @lt_vbak
WHERE vkorg = '1000'
AND audat >= @lv_from_date.
LOOP AT lt_vbak INTO DATA(ls_vbak).
CALL FUNCTION 'BAPI_SALESORDER_GETDETAIL' " RFC — forbidden
EXPORTING salesorderid = ls_vbak-vbeln
IMPORTING order_header_in = ls_header.
ENDLOOP.
" ✅ AFTER — ABAP Cloud (clean core):
" CDS view + EML (Entity Manipulation Language)
SELECT SalesOrder, SoldToParty, TotalNetAmount, TransactionCurrency
FROM I_SalesOrder " Released CDS view
WHERE SalesOrganization = '1000'
AND SalesOrderDate >= @lv_from_date
INTO TABLE @DATA(lt_sales_orders).
" For single-record deep read:
READ ENTITIES OF i_salesorder_api01
ENTITY SalesOrder
ALL FIELDS
WITH VALUE #( ( SalesOrder = lv_so_id ) )
RESULT DATA(lt_detail).Migration Prioritisation Framework
Enterprise Example — DEWA S/4HANA 2023 OP Migration
- Initial custom objects (2023)
- 8,247
- ATC BLOCKER findings (start)
- 2,341
- SAP modifications (start)
- 47
- ATC BLOCKER findings (current)
- 23 (99% reduction)
- SAP modifications remaining
- 0 (all removed)
- Cloud Connector version
- 2.17 (HA pair)
- Access control rules
- 23 (explicit allowlist)
- Target
- 0 BLOCKERs before 2025 OP upgrade (Q3 2025)
Best Practices
Stop accumulating new debt while migrating old. Every new BLOCKER finding added during migration extends the timeline.
Modifications to SAP standard objects are the highest upgrade risk — they receive priority over unreleased API usage (C0).
Each legacy object needs an owner, effort estimate, and deadline. Untracked migration work stalls at the upgrade gate.
Trend data (BLOCKER count over time) is the most effective way to demonstrate progress to management and justify continued investment.
Some legacy Z-reports can be retired instead of migrated. High-effort, low-business-value objects are prime retirement candidates.