SAP API Deprecation Policy: 2-Year Minimum Support, 1-Year Decommission Notice

TL;DR

• Bottom line: SAP will not deprecate an API sooner than 2 years after its initial release, and will not decommission it sooner than 1 year after the deprecation announcement. This gives integrators a minimum 3-year guaranteed window from API release to removal. [src1]
• Key limit: Only Level A (released, ABAP Cloud) APIs carry formal stability contracts backed by SAP. Levels B-D have no contractual upgrade guarantees. [src5]
• Watch out for: Release contracts (C0-C3) define stability per repository object type, not a blanket backward-compatibility promise — a C1 contract (system-internal use) does not guarantee remote API stability. [src6]
• Best for: Planning integration upgrade cycles, assessing migration urgency for deprecated SAP APIs, and choosing between released vs. classic API surfaces.
• Authentication: N/A — this card covers policy, not API access patterns.

System Profile

This card covers SAP's cross-product API deprecation policy as documented in the SAP API Style Guide and SAP Business Accelerator Hub. The policy applies to APIs published on the SAP Business Accelerator Hub across SAP S/4HANA Cloud, SAP SuccessFactors, SAP Ariba, SAP Concur, SAP BTP, and other SAP cloud products. On-premise SAP systems (ECC, BW) follow different support lifecycle rules tied to SAP's product maintenance schedule. [src1, src2]

API Surfaces & Deprecation Policy Scope

[src1, src2, src5]

Constraints

• SAP will not deprecate an API sooner than 2 years after initial release [src1]
• Decommission occurs no sooner than 1 year after deprecation announcement [src1]
• May announce decommissioning sometime after deprecation, with at least 1 year's notice prior to the decommission date [src1]
• Only released APIs (Level A) on SAP Business Accelerator Hub are covered by the formal deprecation policy [src2]
• Classic APIs (Level B) are generally upgrade-stable based on SAP expert nominations, not formal contracts [src5]
• Individual SAP products (SuccessFactors, Ariba, Concur) may have product-specific deprecation timelines that differ from the central policy [src1]
• Release contracts protect specific aspects of objects (extensibility, internal use, remote API, configuration) — not blanket backward compatibility [src6]

Integration Pattern Decision Tree

START -- Need to assess SAP API deprecation risk for an integration
|-- Is the API published on SAP Business Accelerator Hub?
|   |-- YES --> Covered by SAP API Deprecation Policy
|   |   |-- Is the API status "Active"?
|   |   |   |-- YES --> Safe to use; minimum 2 years before deprecation can begin
|   |   |   |-- NO --> Check status below
|   |   |-- Is the API status "Deprecated"?
|   |   |   |-- YES --> Still functional; minimum 1 year until decommission
|   |   |   |   |-- Is a successor API identified?
|   |   |   |   |   |-- YES --> Begin migration to successor API
|   |   |   |   |   |-- NO --> Monitor Business Accelerator Hub for successor
|   |   |-- Is the API status "Decommissioned"?
|   |   |   |-- YES --> API is disabled; migrate immediately
|   |   |-- Is the API status "Beta"?
|   |       |-- YES --> Not production-ready; no deprecation guarantees apply
|   |-- NO --> Not covered by formal deprecation policy
|       |-- Is it a classic ABAP API (RFC, BAPI, classic CDS)?
|       |   |-- YES --> Level B/C; generally stable but no formal contract
|       |   |   |-- Check Simplification Database for upgrade impact
|       |   |   |-- Use ATC check before upgrades
|       |-- Is it a direct SAP table access or modification?
|           |-- YES --> Level D; expect breakage on any upgrade
|               |-- Migrate to released API immediately

[src1, src4, src5, src7]

Quick Reference

SAP API Lifecycle States

[src1, src3, src4]

SAP API Deprecation Timeline

[src1, src2, src3]

Release Contracts (C0-C3)

[src6]

Clean Core Levels (A-D)

[src5, src7]

Step-by-Step Integration Guide

1. Check current API status on SAP Business Accelerator Hub

Navigate to the SAP Business Accelerator Hub and search for your API. The lifecycle badge (Active, Deprecated, Decommissioned) appears on each API page. For deprecated APIs, the page documents the deprecation date, successor API, and planned decommission date. [src1, src4]

# Check API status via SAP Business Accelerator Hub
# Navigate to: https://api.sap.com/
# Search for your API name or browse by product
# Look for lifecycle badge: Active | Deprecated | Decommissioned
# For deprecated APIs: note deprecation date, successor API link, decommission date

Verify: API page shows lifecycle state badge and, if deprecated, links to the successor API.

2. Determine your Clean Core level

Assess your existing extensions and integrations against the 4-level model. Use the ATC (ABAP Test Cockpit) check in your S/4HANA system to identify which APIs your custom code consumes and their release status. [src5, src7]

" In SAP S/4HANA (ADT or SE80):
" 1. Run ATC check on your custom package
" 2. Look for findings related to:
"    - Use of non-released APIs (Level C/D violations)
"    - Use of deprecated APIs
"    - Direct table access instead of CDS views
" 3. Navigate to each finding to see the released successor
"
" In Eclipse (ADT):
" Right-click package > Run As > ABAP Test Cockpit
" Filter by: "Cloud Readiness" check variant

Verify: ATC results show 0 findings for Level C/D usage in new development.

3. Map deprecated APIs to successors

For each deprecated API your integration consumes, use the API Comparator on SAP Business Accelerator Hub to see a side-by-side comparison of deprecated fields vs. successor fields. [src3, src8]

# On the deprecated API page in SAP Business Accelerator Hub:
# 1. Click "Successor API" link
# 2. Use API Comparator (if available) to compare field-by-field
# 3. Document: removed fields, renamed fields, changed data types
# 4. For CDS views: check the "Deprecated and Decommissioned CDS Views"
#    help page for your S/4HANA Cloud version

Verify: Migration mapping document exists for each deprecated API with field-level changes documented.

4. Plan migration timeline

Based on the guaranteed timelines, build your migration plan. The minimum window from deprecation to decommission is 1 year, but SAP recommends migrating as soon as the successor is available. [src1, src2]

Migration Timeline Template:
|-------|-------|-------|-------|-------|-------|
T+0     T+6mo   T+12mo  T+18mo  T+24mo  T+36mo
|       |       |       |       |       |
API     Earliest         Earliest Earliest Earliest
released deprec.         decomm.  decomm.  decomm.
        announce         announce (best    (worst
                         (1yr     case)    case)
                         before)

Action items:
1. Month 0-6 after deprecation: Analyze successor API, document field mapping
2. Month 6-9: Develop and test migration in sandbox
3. Month 9-12: Deploy to production; decommission old integration
4. Buffer: Always complete migration 3 months before announced decommission date

Verify: Migration plan has target completion date at least 3 months before announced decommission date.

Code Examples

Python: Check API deprecation status heuristic

# Input:  SAP API name or path
# Output: Current lifecycle status and deprecation details

def check_api_status_heuristic(api_name: str, product: str = "S/4HANA Cloud") -> dict:
    """
    Heuristic check for SAP API status.
    In production, integrate with SAP API Metadata service or
    parse SAP Business Accelerator Hub programmatically.
    """
    known_deprecated = {
        "API_PURCHASEORDER_PROCESS_SRV": {
            "status": "deprecated",
            "deprecated_date": "2024-05",
            "successor": "API_PURCHASEORDER_2",
            "decommission_date": "TBD (min 2025-05)"
        },
        "SFAPI_Partner_API": {
            "status": "deprecated",
            "deprecated_date": "2023-01",
            "successor": "OData APIs per entity",
            "decommission_date": "2024-01 (SuccessFactors)"
        }
    }
    if api_name in known_deprecated:
        return known_deprecated[api_name]
    return {"status": "active", "note": f"Verify on api.sap.com for {product}"}

# Example usage
result = check_api_status_heuristic("API_PURCHASEORDER_PROCESS_SRV")
print(f"Status: {result['status']}")
print(f"Successor: {result.get('successor', 'N/A')}")

cURL: Test if an SAP OData service is available

# Input:  SAP S/4HANA Cloud system URL, OAuth token
# Output: HTTP status code (200 = active, 404 = decommissioned)

# Check if a specific OData service is available (not decommissioned)
curl -s -o /dev/null -w "%{http_code}" \
  -H "Authorization: Bearer $SAP_TOKEN" \
  "https://$SAP_HOST/sap/opu/odata/sap/API_BUSINESS_PARTNER/$metadata"
# Expected: 200 = active, 404 = decommissioned or not available

# For S/4HANA Cloud, verify API accessibility
curl -X GET \
  -H "Authorization: Bearer $SAP_TOKEN" \
  -H "Accept: application/json" \
  "https://$SAP_HOST/sap/opu/odata/sap/API_BUSINESS_PARTNER?$top=1"
# Expected: JSON response = API is active and accessible

Error Handling & Failure Points

Common Error Codes (Deprecation-Related)

[src3, src7]

Failure Points in Production

• Silent deprecation in sandbox: SAP may decommission APIs in sandbox/test tenants before production. Fix: Monitor SAP release notes per release cycle (quarterly for S/4HANA Cloud Public Edition). [src1]
• Successor API has different field names/types: Deprecated API fields do not map 1:1 to successor. Fix: Use API Comparator on Business Accelerator Hub to generate field mapping before migration. [src3, src8]
• SuccessFactors-specific timeline: SuccessFactors APIs have their own deprecation cadence with product-specific decommission dates. Fix: Check SAP Note 2682094 and 2757846 for SFAPI-specific status. [src1]
• Clean Core level regression: After S/4HANA upgrade, previously stable classic APIs may have released successors. Fix: Run ATC Cloud Readiness check after each upgrade. [src7]
• Release contract scope mismatch: Assuming C1 (system-internal) contract protects remote integrations. Fix: Verify C2 (remote API) contract for any API consumed from outside the SAP system. [src6]

Anti-Patterns

Wrong: Assuming all SAP APIs have the same deprecation timeline

// BAD -- treating SAP as a monolith
// "SAP gives us 2 years before deprecation, so we're safe"
// Reality: the 2-year policy applies to APIs on SAP Business Accelerator Hub.
// Product-specific APIs (SFAPI, Ariba, Concur) may have shorter timelines.
// Classic ABAP APIs have NO formal deprecation timeline.

Correct: Check policy scope per API surface

// GOOD -- verify which policy applies to your specific API
// 1. Is API on SAP Business Accelerator Hub? --> 2-year/1-year policy applies
// 2. Is it a SuccessFactors SFAPI? --> Check SAP Note 2682094 for dates
// 3. Is it a classic RFC/BAPI? --> No formal deprecation policy; product lifecycle
// 4. Is it a direct table read? --> Level D; no guarantees at all

Wrong: Equating release contract with backward compatibility

// BAD -- misunderstanding release contracts
// "This CDS view has a C1 contract, so it's safe for our external integration"
// Reality: C1 = system-internal use only. It allows field length changes
// that could break external consumers.
// C2 = remote API use. Only C2 guarantees stability for external integrations.

Correct: Match release contract to consumption pattern

// GOOD -- use the right contract for the right scenario
// On-stack ABAP Cloud extension? --> C1 (system-internal) is sufficient
// External integration via API? --> Require C2 (remote API) contract
// Custom fields/extensibility? --> Require C0 (extension) contract
// Configuration content? --> C3 (configuration) applies

Wrong: Building on Level C/D APIs for new integrations

// BAD -- choosing convenience over stability
// "The unreleased BAPI does exactly what we need, stable for years"
// Reality: Level C/D objects have no stability guarantee.
// SAP can change or remove them without notice in any release.

Correct: Use released APIs (Level A) for all new development

// GOOD -- invest in Clean Core from the start
// 1. Search SAP Business Accelerator Hub for released equivalent
// 2. If no released API exists, use Level B (classic API) as interim
// 3. Register customer influence request for the missing released API
// 4. Plan migration to released API when SAP delivers it
// 5. NEVER build new integrations on Level C/D objects

[src5, src6, src7]

Common Pitfalls

• Confusing product support lifecycle with API deprecation: SAP's product maintenance dates (e.g., ECC end of support 2027) are separate from API-specific deprecation policies. Fix: Track both product lifecycle AND API-specific deprecation separately. [src1]
• Ignoring product-specific policies: SuccessFactors deprecated the Partner API, SFAPI Adhoc, and SFAPI for Simple Entities on their own timeline. Fix: Always check product-specific deprecation notices in addition to the central policy. [src1]
• Missing the C1 vs C2 distinction: C1 allows field length extensions that would break external consumers. Fix: Require C2 release contract for any API consumed remotely. [src6]
• Assuming deprecated = broken: Deprecated APIs continue to work and receive bug fixes until decommission. Fix: Use the deprecation window for orderly migration rather than emergency action. [src1, src3]
• Not running ATC checks before upgrades: S/4HANA Cloud quarterly releases can introduce new released successors that flag your classic API usage. Fix: Include ATC Cloud Readiness check in every upgrade testing cycle. [src7]
• Relying on Simplification Database alone for Level C objects: The database tracks changes but does not guarantee notification before changes happen. Fix: Migrate Level C objects to Level A/B proactively. [src5]

Diagnostic Commands

# 1. Check API status on SAP Business Accelerator Hub
# Navigate to: https://api.sap.com/
# Search for API name -> check lifecycle badge (Active/Deprecated/Decommissioned)

# 2. Run ATC Cloud Readiness check (in SAP system)
# ADT (Eclipse): Right-click package > Run As > ABAP Test Cockpit
# Select check variant: "Cloud Readiness" or "ABAP Cloud Readiness"
# Review findings for: unreleased API usage, deprecated API usage

# 3. Check Simplification Database for upgrade impact
# Transaction: /n/SDF/SMON or Simplification Item Catalog
# URL: https://me.sap.com/app/simplification
# Filter by: your S/4HANA target release

# 4. Check SuccessFactors SFAPI status
# SAP Note 2795839: SFAPI feature status check tool
# SAP Note 2682094: Partner API, SFAPI Adhoc deprecation details

# 5. Verify CDS view deprecation status (in SAP system)
# ADT: Open CDS view > check "Release State" in Properties
# States: Released (C1/C2), Not Released, Deprecated
# For deprecated views: check "Successor" annotation

Version History & Compatibility

[src1, src5]

When to Use / When Not to Use

Cross-System Comparison

Important Caveats

• The 2-year/1-year policy applies specifically to APIs published on the SAP Business Accelerator Hub. Classic ABAP APIs, RFC modules, and BAPIs not published there follow the broader SAP product maintenance lifecycle instead. [src1]
• SAP product-specific teams (SuccessFactors, Ariba, Concur) operate their own deprecation calendars that may define shorter notice periods. Always check product-specific documentation. [src1]
• The Clean Core Level A-D model was introduced in late 2024, replacing the older 3-tier model. Some documentation still references the 3-tier model. Use the A-D level model for current assessments. [src5]
• Release contracts (C0-C3) protect specific aspects of objects — not everything about the object. A CDS view with C1 contract guarantees field stability for on-stack use but may allow field length changes that break external consumers. [src6]
• SAP reserves the right to deviate from the standard deprecation policy in exceptional circumstances, though this is rare and typically involves security-critical changes. [src1]
• This card does not cover SAP on-premise (ECC) API lifecycle, which is governed entirely by SAP's product maintenance schedule. [src1]