Retiring Old SAP Components During S/4HANA Migration: Licensing and Decommission Strategy

Why Component Retirement Is Critical in S/4HANA Migration

Most organisations that migrate from SAP ECC to S/4HANA focus the majority of their planning effort on the technical migration itself: data migration, custom code adaptation, integration re-architecture, and the operational cutover. The commercial and licensing dimension of migration — what happens to existing licences, which components become redundant, and how to structure the decommission to reduce ongoing costs — receives far less attention in most migration programmes.

This is a costly oversight. S/4HANA changes the licence baseline in fundamental ways. Capabilities that existed in ECC as separately licensed add-ons are in some cases embedded in S/4HANA core. Other ECC modules become obsolete because their function is replaced by S/4HANA's redesigned architecture. Still others remain technically available but are no longer strategically relevant for an organisation that has moved to S/4HANA's simplified data model.

Every one of these legacy components that persists in your licence portfolio — whether deployed or not — carries an annual maintenance obligation at SAP's standard rate of approximately 22 percent of net licence value. For an organisation with a $10 million ECC licence estate, retiring $3 million of components that are genuinely obsolete in S/4HANA saves $660,000 per year in maintenance, compounding over the full S/4HANA contract term. That saving does not happen automatically. It requires deliberate planning, proper documentation, and a commercial conversation with SAP.

What Changes in the Licence Baseline at S/4HANA Migration

Understanding which components are candidates for retirement starts with understanding how S/4HANA's architecture differs from ECC and what it means for licence entitlement.

Components Embedded in S/4HANA Core

S/4HANA's unified data model eliminates many of the architectural boundaries that required separate licensing in ECC. The most significant changes affect SAP Business Warehouse, SAP Advanced Planning and Optimisation, and certain SAP analytics capabilities. Organisations that licensed these as separate components in ECC may find that equivalent functionality is included in S/4HANA core without additional licensing — but this varies by deployment model and must be confirmed contractually, not assumed.

The critical discipline here is to verify what is genuinely included in your S/4HANA contract versus what SAP is representing as included but actually licensing separately. RISE with SAP — SAP's bundled cloud ERP subscription — has been particularly prone to this gap between what is pitched as included and what the contract actually covers. Before decommissioning any ECC component on the assumption it is covered in S/4HANA, obtain written confirmation from SAP that the specific use case is licensed under the new agreement.

Components Replaced by S/4HANA Architecture

Several ECC modules are replaced by S/4HANA's redesigned functional architecture rather than simply absorbed into core. SAP SRM (Supplier Relationship Management) functionality is largely replaced by SAP Ariba or by S/4HANA Sourcing and Procurement capabilities. SAP CRM functionality has been replaced by SAP Customer Experience products. SAP Extended Warehouse Management, previously a separate product, is now available as embedded functionality in S/4HANA.

For each of these, the migration question is not technical but commercial: does your S/4HANA contract include the replacement capability, or will it require an additional subscription or licence? The answer determines whether the ECC component can be retired with a net reduction in licence cost, or whether retiring it simply creates a capability gap that must be filled with a new purchase.

Components That Are Genuinely Obsolete

The clearest retirement candidates are components that have no S/4HANA equivalent and no longer serve a business function. Examples include SAP Solution Manager (replaced by SAP Cloud ALM in S/4HANA environments), certain industry-specific solutions that have been superseded by S/4HANA industry best practices, and legacy SAP products like SAP Business Warehouse Accelerator that were designed to address ECC performance limitations that do not exist in S/4HANA's HANA-native architecture.

These components should be explicitly identified, documented, and formally terminated as part of the S/4HANA migration commercial process. They represent pure maintenance cost savings with no offsetting licence requirement.

The Compatibility Pack Deadline: What You Need to Know

A related but distinct consideration during S/4HANA migration is the Digital Access position. S/4HANA deployments typically involve new or redesigned integrations, and each integration that creates documents in SAP generates Digital Access Licence Count (DDLC) obligations — SAP's metric for measuring externally-originated document creation across nine document categories. The DDLC licence baseline changes when ECC integrations are replaced by S/4HANA-compatible integrations, and this change should be assessed and documented as part of the migration's commercial planning, not discovered in a post-migration audit.

SAP introduced S/4HANA Compatibility Packs to allow organisations to use legacy business processes that had not yet been converted to S/4HANA's new architecture. These packs allowed organisations to migrate technically to S/4HANA while continuing to run old-style processes during a transition period.

SAP imposed a hard deadline of December 31, 2025, for most customers to cease using Compatibility Packs. SAP's position is that continued use of Compatibility Packs after that date constitutes commercial non-compliance — effectively a breach of contract. Organisations that have not completed the migration of their Compatibility Pack-dependent processes face significant exposure if they are still running these processes as of the start of 2026.

The licensing implication is direct: processes that depend on Compatibility Packs often involve ECC-era licence types that have no clean S/4HANA equivalent. These processes must be either converted to native S/4HANA architecture (which may require process redesign) or retired if they no longer serve a business function. The cost of non-compliance — in the form of SAP's audit position — significantly exceeds the cost of the conversion or retirement work in most cases.

How to Retire Components: The Process

Retiring SAP components is not simply a technical exercise of switching off software. It requires a structured commercial and legal process to ensure that the retirement is recognised by SAP, the maintenance obligation is eliminated, and the documentation exists to defend your position in any future audit.

Step 1: Inventory and Assessment

Begin with a comprehensive inventory of every SAP component in your current licence portfolio, cross-referenced against your actual system footprint. For each component, the assessment should answer three questions: Is it currently installed? Is it actively used? Does it have a functional equivalent in S/4HANA that is already covered in the new contract?

The inventory must cover both production environments and non-production systems — development, quality assurance, training, and sandbox environments. SAP audits typically examine all environments, not just production. A legacy component that has been retired from production but continues to exist in a development or test environment may still create a maintenance obligation and compliance exposure until it is formally decommissioned everywhere.

Step 2: Formal Communication with SAP

The retirement of SAP components should be communicated formally to SAP in writing — not simply handled through your SAP account manager in a verbal conversation. A formal written notification creates an evidence trail that the retirement took effect from a specific date. This is essential for audit defence: if SAP subsequently claims you were using or maintaining a retired component after the stated retirement date, the written notification is your primary defence.

The communication should specify each component being retired, the effective retirement date, the system landscape from which it is being removed (including all non-production environments), and any conversion programme or SAP letter of intent that covers the transition. Your SAP account team should provide written acknowledgement of the retirement, and that acknowledgement should be filed alongside your S/4HANA contracts and conversion paperwork.

Step 3: System Decommissioning and Licence Reduction

Following the formal communication, the technical decommissioning must be completed — removing or disabling the component in all relevant systems and producing a record of when the decommission was executed. This technical record, timestamped and retained, provides the operational evidence that supports the commercial notification.

For licence reduction purposes, the decommissioning date is the date from which the maintenance obligation should cease. If the decommissioning occurs mid-year within an annual maintenance cycle, there may be a partial-year maintenance credit or adjustment available — negotiate this explicitly rather than allowing SAP to continue charging for a full year after retirement.

Step 4: Negotiating the Commercial Outcome

Component retirement creates a commercial opportunity as well as a compliance necessity. The reduction in your licence portfolio's net value reduces your maintenance base, and that reduction should be reflected in your next annual maintenance invoice and in the long-term maintenance commitment in your S/4HANA contract.

More broadly, the retirement exercise gives you a cleaner, more defensible licence position going into the S/4HANA negotiation. An organisation that knows precisely what it owns, what it is retiring, and what the resulting S/4HANA requirement is can negotiate from a position of clarity. SAP account teams respect well-prepared customers and respond commercially to those who demonstrate they understand their position.

SAP's fiscal year ends December 31. If you are planning to retire legacy components as part of an S/4HANA migration that will also involve a contract renewal or new subscription commitment, the Q4 window is when SAP's commercial flexibility is highest. Component retirement discussions bundled with a new S/4HANA commitment in Q4 consistently produce better commercial outcomes than equivalent discussions in Q1 or Q2.

Common Retirement Mistakes and How to Avoid Them

In practice, the component retirement process goes wrong in several consistent ways. Understanding these failure modes in advance allows organisations to avoid them rather than recover from them.

Retiring Components Without Verifying S/4HANA Coverage

The most expensive mistake is retiring an ECC component on the assumption that its functionality is included in the S/4HANA contract, and then discovering post-retirement that it requires a separate purchase. This creates a double cost: the original maintenance saving from retirement is offset by the cost of the new S/4HANA capability licence. Always obtain written confirmation of coverage before retiring.

Failing to Retire Non-Production Systems

Legacy components persist longest in non-production environments because their retirement is typically lower priority than production cutover. But SAP's audit methodology examines all environments. A legacy component that runs in a development or test system three years after production retirement creates a compliance exposure that is disproportionate to any operational value it provides. Build non-production environment retirement into the migration programme timeline explicitly.

Carrying Shelfware Into the S/4HANA Conversion

As noted in the shelfware discussion, organisations that carry unused ECC licence inventory into their S/4HANA conversion are effectively paying conversion fees for assets they do not need. The component retirement exercise should be completed — or at least well advanced — before the S/4HANA conversion negotiation begins. The conversion should reflect the post-retirement portfolio, not the pre-retirement one.

Not Documenting the Retirement Properly

Documentation failures create audit exposure for years after the retirement has been completed operationally. The standard we recommend is a retirement file for each component containing: the formal written notification to SAP, SAP's written acknowledgement, the technical decommission record (with dates and environments), and a copy of any relevant conversion agreement or SAP programme documentation. This file should be stored with your master SAP contract documentation and retained for at least the duration of the S/4HANA contract term.

The Migration as a Licence Rationalisation Opportunity

S/4HANA migration is the single largest leverage point in the SAP commercial relationship. The migration represents a new multi-year commitment for SAP — new licence revenue, new subscription income, new professional services opportunities. SAP has a strong financial incentive to close migration deals, and that incentive creates flexibility that does not exist in routine renewal cycles.

Organisations that treat the migration as a licence rationalisation opportunity — using it to shed redundant components, negotiate out of shelfware, right-size their user portfolio, and establish favourable terms for the S/4HANA agreement — consistently achieve better commercial outcomes than those that treat it purely as a technical project. The commercial dimension of the migration deserves the same investment and discipline as the technical one.

If you are within eighteen to twenty-four months of an S/4HANA migration decision, now is the time to begin the component inventory and retirement assessment. The analysis is not complex, but it takes time and care to do properly. Starting early means the retirement is complete before the S/4HANA negotiation begins — giving you the cleanest possible position when SAP presents their migration proposal.