Upgrade Safe Development
Practices, tools, and architectural patterns that guarantee your S/4HANA extensions survive every SAP release upgrade — from S/4HANA 2023 OP to 2025 OP and beyond — with zero rework.
S/4HANA Release Cycle & Clean Core Guarantee
Executive Summary
Upgrade safety is the primary business driver for Clean Core. SAP S/4HANA On-Premise releases every approximately 2 years (2023 → 2025 → 2027). For a clean core system, each upgrade requires minimal custom code regression testing because: no SAP standard objects are modified, all custom code uses C1-released APIs that SAP guarantees stable, and side-by-side extensions on BTP are entirely independent of S/4HANA's version. A non-clean-core system requires months of regression testing per upgrade cycle — a cost that compounds every release.
The Cost of Non-Clean-Core Upgrades
| Scenario | Clean Core | Non-Clean-Core |
|---|---|---|
| Upgrade effort | 4–8 weeks | 6–18 months |
| Regression testing scope | Minimal (API-compliant code only) | Extensive (all modifications) |
| Upgrade risk level | Low | High |
| Typical upgrade cost | €100K–300K | €1M–5M |
| Business disruption | Minimal | Significant |
| Upgrade frequency | Every 2 years (on schedule) | Often delayed (too expensive) |
The 4 Pillars of Upgrade Safety
Ensured by ABAP Cloud language version and ATC enforcement. Zero implicit or explicit enhancements placed on any SAP standard object.
C1 API contract from SAP — 10+ years of guaranteed backward compatibility. Verified by the ABAP compiler at activation time (not just at code review).
BTP extensions consume only released OData V4 APIs. When S/4HANA upgrades, the C1 API contract ensures all BTP extensions continue working without change.
ABAP Unit tests and Fiori OPA5 tests run automatically after upgrade sandbox deployment. SAP Cloud ALM Upgrade Impact Analysis surfaces affected objects before testing begins.
Pre-Upgrade Checklist
Complete this checklist before every S/4HANA upgrade. Start the first four items at least 6 months before the target go-live date.
PRE-UPGRADE CHECKLIST — S/4HANA Clean Core System
□ Run ATC check on all custom Z-packages → 0 BLOCKER findings
□ Run SAP Clean Core Assessment → review new violations since last run
□ Check SAP API deprecation notices for S/4 target release
(available in SAP Note 2888621 / SAP Help API Deprecation page)
□ Review Cloud ALM Upgrade Impact Analysis report
□ Execute ABAP Unit test suite → all tests PASS
□ Check SAP Fiori Launchpad compatibility (SAPUI5 version update)
□ Verify BTP Destination URLs still valid after S/4 hostname changes
□ Run Fiori apps smoke test in upgrade sandbox (manual + OPA5)
□ Review Custom Fields for any structural changes in target release
□ Verify BAdI interfaces unchanged (SAP occasionally adds optional methods)
□ Test side-by-side CAP extensions against upgraded sandbox S/4
□ Document all changes in SAP Cloud ALM Upgrade Impact register
□ Get sign-off from Clean Core Council before production upgradeSAP API Deprecation Management
" Check for deprecated API usage in custom code:
" 1. ATC Check: SLIN_UOPER finds deprecated operations
" Run via ADT: Right-click project → Run As → ABAP Test Cockpit
" 2. Review SAP API Deprecation page:
" help.sap.com → search "API deprecation S/4HANA 2025"
" Lists all APIs deprecated in target release + replacement API
" 3. Replace deprecated pattern with successor:
" Example: I_SalesOrderPartner (deprecated in 2025 OP)
" → replacement: I_SalesOrderPartner_2 (new in 2025 OP)
" Old (deprecated):
SELECT SalesOrder, PartnerFunction, AddressID
FROM I_SalesOrderPartner " Deprecated in S/4HANA 2025
WHERE SalesOrder = @lv_so.
" New (upgrade-safe):
SELECT SalesOrder, PartnerFunction, BusinessPartner
FROM I_SalesOrderPartner_2 " Released in S/4HANA 2025 OP
WHERE SalesOrder = @lv_so.CI/CD Pipeline for Upgrade Safety
Integrate ATC checks and ABAP Unit tests into the CI/CD pipeline so that every transport is automatically validated. Non-compliant code never reaches the Quality system.
# Jenkinsfile excerpt — Clean Core CI/CD gate
pipeline:
stages:
- name: ABAP-Build
steps:
- abapAddonAssemblyKit # ATC transport check
- name: ATC-Clean-Core-Check
steps:
- script: |
# Run ATC with ZCLEANCORE_STRICT profile
# Fails pipeline on any BLOCKER finding
curl -X POST \
"https://s4h-dev.corp/sap/bc/adt/atcworklists" \
-H "Authorization: Bearer $ATC_TOKEN" \
-d '{"profile":"ZCLEANCORE_STRICT","maxFindings":"0"}'
- name: ABAP-Unit-Tests
steps:
- script: |
# Run all ABAP Unit tests in Z-packages
# Fails on any test failure
- name: Deploy-To-QA
condition: all-checks-pass
steps:
- sapTransportDeployment
- name: Fiori-OPA5-Tests
steps:
- runFioriTests # Smoke tests post-deploymentDEWA 2025 OP Upgrade Status (June 2025)
- Target Go-Live
- August 2025
- ATC BLOCKER Findings
- 0
- ATC MAJOR Findings
- 23 (remediating)
- BAdIs Compatible (2025 OP)
- 14/14
- CAP Extensions Tested vs Sandbox
- 6/6 Passing
- Estimated Upgrade Effort
- 6 weeks
- Comparable Non-Clean-Core Effort
- 12 months
Best Practices
Run the ATC upgrade readiness check 6 months before the planned upgrade date. Complex remediations (e.g. replacing BAPIs with EML) take weeks, not days.
SAP publishes API deprecation lists for each target release. Subscribe to the relevant S/4HANA release notes and check your API usage against the deprecation list annually.
ABAP Unit tests and OPA5 Fiori tests must exist before the upgrade, not during. A test suite you write during the upgrade cannot catch regressions that have already happened.
SAP Cloud ALM automatically cross-references your custom code objects with SAP's "what changed in this release" list. It surfaces affected objects before you start manual testing.
Set a KPI: target date for zero BLOCKER ATC findings and track it monthly. Visibility at management level drives consistent remediation effort before crunch time.