A finance sponsor is asked to defer an ECC transition because “SAP support runs long enough.” Before accepting that proposal, the CIO needs to establish which installed releases are covered, under which agreement, and whether the intended migration path remains deliverable. A maintenance date alone answers none of those questions.
The defensible outcome of SAP ECC maintenance planning is a support-runway register and a dated funding gate. Treat vendor coverage, operational viability, security obligations and migration readiness as separate approvals. Deferral is credible only when those approvals support it; starting migration is credible only when the programme has a deliverable scope and schedule.
Establish the release-specific coverage, not the headline deadline
SAP’s extended-maintenance commercial summary distinguishes SAP ERP 6.0 releases: mainstream support for systems before enhancement package 6 ends on December 31, 2025, while enhancement packages 6–8 have mainstream support through December 31, 2027. Do not copy the later date onto every ECC installation.
Start with an installed-product inventory owned by the SAP application team. Record the precise product version and enhancement package, then check the corresponding maintenance record. SAP identifies the Product Availability Matrix, or PAM, as the place to verify maintenance timelines for individual products and versions. Retain the record used, its document version where available, and the date checked.
Use the following worksheet for each installed product or dependency. Keep unresolved entries visible rather than assigning an assumed estate-wide expiry date.
| Register field | Evidence to retain | Accountable role |
|---|---|---|
| Installed scope | Product, release, enhancement package, installation and business processes served | SAP application owner |
| Maintenance status | Matching PAM record, confirmed coverage dates and verification date | SAP platform owner |
| Contractual coverage | Applicable support agreement, addendum, covered scope and commercial conditions | Procurement and legal |
| Operating and security position | Dependency coverage, control requirements, recovery evidence and accepted exceptions | Operations and security owners |
| Unresolved dependencies | Blocker, evidence needed, resolution owner and due date | Migration lead |
| Decision timetable | Latest responsible decision date, funding gate and assumptions behind both | CIO and finance sponsor |
Version-specific evidence should also govern any proposal to improve ECC while deferring migration. The improve-or-replace investment framework calls for proof against the installed version and relevant commercial terms, rather than accepting a general statement that the product supports a workflow. Apply that same discipline to claims that the current estate can safely remain in service.
Distinguish purchasable coverage from an assumed extension
SAP’s published summary describes optional extended maintenance from January 1, 2028, through December 31, 2030. For on-premises customers, it requires a separate addendum to an active SAP support agreement and applies across the commercial Business Suite 7 core-application landscape. An available option is not evidence that your company has contracted it.
The pricing distinction matters to the funding case. SAP describes an additional two percentage points on the maintenance base of covered core applications and add-ons, not simply a two-percent increase to the existing support invoice. Ask procurement to reconcile the quoted base and covered scope with the register. An unexplained “extended support allowance” is not a sufficient budget assumption.
Keep later transition arrangements separate. In its guidance on planning beyond extended maintenance, SAP describes Transition Option for SAP ERP as a conditional subscription for qualifying large and complex customers whose transformations are underway, intended to cover 2031–2033. Systems must move to SAP ERP, private edition on SAP HANA before December 31, 2030; additional eligibility requirements apply, and Java-dependent capabilities are excluded.
That is not an unconditional extension for an unchanged on-premises ECC estate. If a deferral proposal depends on it, require confirmation of eligibility, ordering availability, price, covered capabilities and binding terms before using it in the approved schedule.
Then obtain separate operating and security decisions. Ask operations to demonstrate recoverability and ownership of critical dependencies. Ask security to identify required corrections and controls, and whether the proposed support arrangement supplies what those obligations require. Do not let a maintenance entitlement stand in for either sign-off.
Work backward from the constraints on your migration path
The latest responsible funding date should be calculated from the work and constraints, not selected by subtracting a generic migration duration from maintenance expiry. First establish the intended transition route and target environment. Then require the delivery team to identify prerequisites, estimates, sequencing and uncertainty for that particular estate.
A migration-path restriction can be decisive independently of support entitlement. SAP states that conversion tooling for Business Suite 7 systems on third-party databases will only be available before the relevant reseller/support agreements end in 2030. Afterward, only greenfield transition scenarios will be supported. For an affected estate, a proposal to defer must therefore explain whether the intended conversion remains achievable within that boundary.
Ask the team to produce a dependency-led schedule covering:
- Release and target compatibility checks, including installed add-ons and connected applications.
- Custom-code assessment and disposition, with unresolved business decisions assigned to owners.
- Data preparation, interface changes and end-to-end acceptance evidence.
- Infrastructure, commercial approvals, internal staff capacity and delivery commitments.
- Migration rehearsals, permitted cutover windows, recovery planning and stabilization.
These are evaluation requirements, not claims that every programme needs the same work. For retained custom capabilities, use a separate SAP extension-placement assessment to resolve where they should run. Bring its unresolved blockers and estimates back into the timetable without turning maintenance planning into detailed architecture design.
Work backward through the critical dependencies, allowing explicitly approved contingency for unresolved work. Record when funding must be released, not merely when the programme should finish. If a prerequisite has no owner or credible estimate, the resulting decision date remains provisional.
Choose between starting now and a time-bounded deferral
Starting now is the stronger choice when verified coverage or migration-path constraints leave insufficient room for the dependency-led plan, or when continuing-operation requirements cannot be met on acceptable terms. “Start” need not mean authorizing the entire implementation immediately. Where a material uncertainty could change the route, fund a bounded assessment with a specified output and decision gate.
A time-bounded deferral is defensible when contractual coverage is confirmed, operating and security owners accept the continuing obligations, and a credible backward schedule preserves the intended transition route. Its approval should identify what the business gains from waiting, what it must fund during the deferral, and which events would trigger an earlier decision.
Test both options against the same required business outcomes and planning horizon. Include interim work, continuing operation and eventual transition in the deferral case. For starting now, require explicit assumptions about internal capacity and delivery dependencies rather than treating an earlier kickoff as proof of lower exposure.
At the next funding gate, put the register and backward schedule side by side. Approve migration, approve a dated deferral with conditions, or commission a bounded assessment of the specific uncertainty preventing a decision. Do not approve an unsupported expiry date.
If you need to turn that decision into functional and technical work packages, discuss the estate, dependencies and migration requirements with Digiventi’s SAP specialists.
