SAP ECC End of Support Assessment: 22-Point Readiness Checklist

SAP ECC 6.0 with Enhancement Packages 0 through 5 lost mainstream maintenance on 31 December 2025. ECC 6.0 with EHP 6, 7, or 8 remains under mainstream maintenance until 31 December 2027. Organisations that have not confirmed their exact EHP level may be operating without mainstream support already. Run transaction SE16 on table CVERS or contact your SAP Basis team to confirm the version string before making any other planning decisions.

SAP offers optional Extended Maintenance for ECC 6.0 EHP 6-8 customers through 31 December 2030, at a premium of approximately two percentage points above the standard 22% maintenance rate — effectively a 9% cost increase on your current annual maintenance bill. Extended maintenance covers security patches and legal change packages but does not deliver new functional capabilities. It is a bridge, not a destination. Organisations should model the total cost of this three-year bridge against alternative paths before committing.

SAP has offered select customers with highly complex ECC landscapes an extension of ECC support to 2033 via the SAP ERP Private Edition (RISE with SAP Private Cloud) route. This option is not universally available and is structured to anchor customers to the RISE commercial model rather than preserve pure on-premise ECC. Organisations exploring this route should have independent legal counsel review the RISE contract terms — particularly data portability, exit provisions, and price escalation clauses — before signing. Do not rely solely on SAP account team representations.

Third-party maintenance providers — most notably Rimini Street (which has announced ECC support through 2040) and Spinnaker Support — offer annual maintenance savings of 50 to 90% versus SAP's standard rates. For organisations with a 24- to 36-month migration timeline, switching to third-party support after 2027 could free material capital to fund the S/4HANA project itself. Key caveats: third-party support does not deliver new SAP functionality, SAP may apply pressure tactics during re-licensing conversations, and some SAP cloud services require active SAP maintenance. Model the financial case independently before approaching SAP.

Many organisations do not have a current, accurate inventory of their SAP contractual entitlements. The ECC-to-S/4HANA transition requires a clear picture of every Named User license (Professional, Limited Professional, Employee), every engine license (BW, SCM, CRM, EWM), and every industry-specific add-on. Shelfware — licensed software you are paying maintenance on but not using — represents both a current cost drain and a migration risk: SAP will expect to convert all contractual entitlements, not just active deployments. An independent license review conducted before any SAP negotiation is essential.

SAP offers conversion credits when ECC customers migrate to RISE or S/4HANA cloud, applying a portion of ongoing maintenance spend as a credit against the new subscription. These credits are declining annually. Customers who signed in 2021 received credits equivalent to approximately 90% of annual maintenance; by 2025–2026, market evidence suggests credits have declined to 50–70%. Every year of delay represents a material reduction in the commercial value of your ECC asset. Organisations with annual SAP maintenance exceeding £500k should treat this as a board-level financial decision, not an IT procurement matter.

Shelfware — licenses under contract but not actively deployed — inflates your maintenance obligation and, if carried forward into the S/4HANA migration negotiation, will inflate your future subscription cost. SAP sales teams frequently use the total license portfolio as the baseline for migration commercial proposals. An independent assessment that accurately identifies active versus unused entitlements gives you a defensible basis for negotiating a right-sized migration package. Organisations routinely reduce their S/4HANA subscription baseline by 20 to 40% through pre-negotiation shelfware remediation.

SAP's Digital Access / Document-based Licensing model (DDLC), introduced in 2018, changed the way third-party and custom integrations to SAP systems are licensed. Organisations with custom applications, middleware, or third-party systems that create or read SAP documents (Sales Orders, Purchase Orders, Delivery documents, etc.) may have unquantified indirect access exposure. This exposure does not disappear on migration — in fact, DDLC enforcement typically intensifies during S/4HANA contract negotiations. Document your integration landscape and model your DDLC exposure before entering migration discussions with SAP.

SAP contracts typically include broad audit rights that allow SAP to conduct a license compliance review with relatively short notice. During migration negotiations, SAP audit teams have historically been deployed as a commercial lever — creating licensing claims that can be resolved through a migration agreement. Understanding what your contract permits, what measurement methodology applies to your license types, and where your compliance position is defensible gives you a significantly stronger negotiating posture. Never enter migration negotiations with SAP without having independently reviewed your audit exposure.

Greenfield (new implementation) delivers the cleanest S/4HANA deployment and maximum access to SAP's standard best practices, but is the most disruptive, most expensive, and longest to execute — typically 24 to 36 months for a mid-to-large enterprise. Brownfield (system conversion) preserves existing processes and data, reduces implementation timeline by 30 to 50%, but carries legacy complexity forward. Selective Data Transition combines selective process redesign with data migration — offering a middle path that many organisations find practical. The correct choice depends on process complexity, custom code volume, data quality, and business transformation ambition. Insist on a fit-gap analysis before your SI commits to a path.

RISE with SAP bundles infrastructure, S/4HANA cloud, BTP platform credits, and SAP Business Network starter access into a single subscription — but at a price premium that typically exceeds a comparable on-premise or hyperscaler-hosted deployment by 15 to 30% over a five-year horizon. RISE contracts also contain lock-in provisions, data portability restrictions, and price escalation mechanisms that are negotiable at signing but almost impossible to renegotiate at renewal. Standalone S/4HANA cloud and on-premise options offer more commercial flexibility but require more internal infrastructure management. The deployment model decision should be driven by independent TCO modelling, not SAP account team presentations.

SAP Compatibility Packs allowed organisations to run classic ECC business processes (such as classic GL, classic cost-of-sales accounting, and classic project system) within S/4HANA without completing full process re-engineering. These Compatibility Packs expire in May 2026. Any S/4HANA migration planned after this date requires full process migration to S/4HANA native equivalents — eliminating a significant shortcut that early movers were able to use. This adds scope, time, and cost to migrations initiated from mid-2026 onwards. If your organisation is still in early planning stages, factor this into your migration effort estimate immediately.

SAP launched GROW with SAP as a preconfigured, faster-to-deploy entry point for S/4HANA Cloud Public Edition, targeting organisations that can adopt SAP's standard best practices with minimal customisation. For ECC organisations with simpler process footprints or subsidiaries that can be migrated independently of a complex core, GROW offers a quicker time-to-value than a full RISE deployment. However, the Public Edition's customisation constraints are significant — heavily customised ECC environments typically cannot migrate to Public Edition without fundamental process redesign. Validate fit before committing to this path.

Custom ABAP code is consistently the largest single driver of migration cost and timeline overrun in ECC-to-S/4HANA projects. SAP's Custom Code Migration (CCMIG) workbench and the ABAP Test Cockpit (ATC) allow organisations to scan their ABAP repository and identify custom objects that reference obsolete APIs, deprecated function modules, or compatibility pack-dependent functionality. The output — typically expressed as number of objects requiring remediation and estimated development effort — is the single most important technical input to a migration business case. Organisations that skip this step consistently underestimate migration scope by 40 to 60%.

S/4HANA migrations are significantly affected by data volume: large ECC databases (500GB to multi-TB) extend migration downtime windows, increase testing cycles, and complicate data validation. SAP's HANA database also has different memory scaling characteristics than traditional Oracle or MSSQL ECC deployments. Pre-migration data archiving — using SAP ILM or third-party tools like OpenText or Informatica — can reduce migration database size by 30 to 60%, compressing downtime and reducing HANA infrastructure costs. Conduct a data quality and archiving assessment early; do not leave it to the implementation partner's discovery phase.

ECC environments in large enterprises typically have 40 to 200+ inbound and outbound integrations to non-SAP systems — including MES, WMS, HR systems, financial reporting platforms, EDI networks, and third-party analytics tools. Each integration must be assessed for S/4HANA compatibility: some will require only reconfiguration, others will require redevelopment, and some may require replacement of the connected non-SAP system. Integration complexity is the second-largest driver of migration cost overruns after custom code. A documented integration inventory with dependency mapping is a prerequisite for any credible migration business case.

S/4HANA runs exclusively on SAP HANA, an in-memory database that has fundamentally different infrastructure requirements from traditional Oracle or MSSQL-based ECC deployments. HANA requires certified hardware configurations, significant RAM (minimum 256GB for most enterprise deployments, often 1TB to 4TB+), and either dedicated on-premise infrastructure or a compatible IaaS platform (AWS, Azure, Google Cloud, or SAP's own BTP/RISE infrastructure). Organisations on-premise will need to evaluate whether to refresh infrastructure or move to cloud hosting as part of the migration. Get infrastructure sizing estimates from SAP's Quick Sizer tool or a certified HANA infrastructure partner before finalising the migration approach.

ECC-to-S/4HANA migrations are enterprise transformation programmes, not IT upgrade projects. They require board-level sponsorship, a cross-functional steering committee (IT, Finance, Operations, Legal, HR), and governance structures that can make process design decisions within weeks rather than months. Organisations that frame the migration as a technology project and assign it solely to IT consistently experience scope drift, stakeholder disengagement, and schedule overrun. If your organisation does not yet have an executive sponsor with budget authority and cross-functional mandate, establish one before engaging any implementation partner.

S/4HANA migrations typically require business process changes across Finance (Universal Journal replaces FI and CO documents), Procurement (new purchasing processes), Supply Chain (new MRP and production planning logic), and HR (if integrating SuccessFactors). User retraining requirements are substantial. Organisations that underinvest in change management — typically budget 10 to 15% of total programme cost for OCM — routinely experience adoption failure and post-go-live productivity loss. Assess your internal change management capability and budget honestly before finalising the programme business case.

The pool of experienced SAP S/4HANA implementation consultants is finite, and demand is increasing rapidly as the 2027 deadline approaches. Organisations starting procurement in late 2026 or 2027 will face constrained partner availability, inflated day rates, and reduced leverage on programme governance terms. Tier-1 SIs (Accenture, Deloitte, IBM, Capgemini) are already reporting pipeline pressure for 2027 delivery slots. An independent partner selection process — with competitive bidding, fixed-price or milestone-based commercial structures, and exit provisions — protects the organisation significantly better than a sole-source negotiation driven by urgency.

SAP account teams will provide a Total Cost of Ownership model that compares migrating to RISE favourably against staying on ECC. These models are designed to support a commercial outcome, not an objective financial decision. An independent TCO should compare at minimum four scenarios: (1) migrate to RISE with SAP on SAP's current commercial terms; (2) migrate to S/4HANA on-premise or hyperscaler-hosted; (3) remain on ECC with SAP extended maintenance to 2030 plus third-party support post-2030; (4) switch to third-party support now and defer migration. Each scenario should include implementation costs, ongoing subscription or maintenance costs, infrastructure, internal resource, and opportunity cost of business disruption.

The single most common mistake we see from ECC organisations is treating the migration decision as continuous — always under review, never committed. This creates organisational paralysis, allows SAP commercial pressure to accumulate unchecked, and compresses the migration execution window. The assessment items in this checklist are designed to be completed within 8 to 12 weeks with appropriate internal and independent advisory support. Once completed, the organisation should be in a position to make a governance-level decision — migrate by when, via which path, on what commercial terms, with which implementation partner — before Q3 2026. Organisations that defer this decision beyond mid-2026 face materially higher costs and significantly reduced options.