SAP ends mainstream maintenance for ECC on December 31, 2027, and the date will not move. For an executive the date is less useful than the choice behind it. There are three real options, and they resolve on three different dates. Migrate to S/4HANA by the end of 2027. Buy extended maintenance to the end of 2030, which adds about 9% to the maintenance bill. Or sign the private cloud transition option before 2028 and carry ECC support to 2033. A tier 1 program needs about 36 months from decision to go-live, so for most companies the first option is already a compressed one, and the real question is which bridge to buy.
The 2027 date is three decision points, not one cliff
Most of the writing about SAP's deadline treats it as a single cliff. It is a sequence. Mainstream maintenance for ECC on enhancement packs 6 through 8 ends on December 31, 2027 (Rimini Street). From 2028 through the end of 2030, SAP sells extended maintenance at a premium. For customers who commit before 2028, a private cloud subscription carries ECC support to 2033 (The Register).
Each of those is a decision with its own deadline, its own cost, and its own signature date. Seen that way, the three options line up as follows.
| Option | Support runs to | What it costs | What you must do, and by when |
|---|---|---|---|
| Migrate to S/4HANA | No ECC support needed after go-live | A large S/4HANA migration runs $5M to $50M | Be live by December 31, 2027, which means deciding in 2024 under the 36-month rule |
| Extended maintenance | December 31, 2030 | Plus 2 points on license value, about 9% more on the maintenance bill | Elect it for the 2028 to 2030 window; negotiate exit terms before signing |
| Private cloud transition option | 2033 | A subscription, with ECC support included | Sign before 2028, roughly 14 months from now |
The migration cost figure is from Redress Compliance, a license negotiation firm, which puts a large S/4HANA migration at $5M to $50M (Redress). This article does not re-run the full multi-vendor picture or the arithmetic of delay. For the Oracle and Microsoft dates beside SAP's, see the pillar on ERP support deadlines.
A 2027 go-live needed a decision in 2024
A tier 1 ERP program needs about 36 months from the decision to proceed to a stable go-live. Published ranges put large implementations at 12 to 36 months (ERP Research), and the short end of that range describes the build, not the whole program. Selection and contracting take six to nine months on their own. Data cleanup starts before the SI arrives and runs past go-live.
Apply the rule to each SAP date and the calendar becomes concrete. To be off ECC by December 31, 2027, the decision needed to land by the end of 2024. To use extended maintenance and be live by the end of 2030, the program has to start within about the next 12 months. To use the private cloud transition option and be live by 2033, a company has room, but the subscription itself has to be signed inside roughly 14 months.
| Target go-live | Decision needed by (36-month rule) | Position in November 2026 |
|---|---|---|
| End of 2027 (off ECC at mainstream end) | End of 2024 | Late. A bridge is now part of the plan, not a fallback |
| End of 2030 (extended maintenance window) | End of 2027 | On time if the program starts within about 12 months |
| 2033 (private cloud transition option) | 2030, with the subscription signed before 2028 | Comfortable on the program, but the signature is due within about 14 months |
A company that has not started cannot reach a clean 2027 go-live without compressing testing or splitting into waves it did not plan. Compression is where overruns come from. For most ECC customers reading this, the honest position is that the first option has already closed, and the decision is between the two bridges.
Extended maintenance adds about 9% to the bill
SAP standard maintenance runs at about 22% of license value a year (ERP Research). Extended maintenance for the 2028 to 2030 window adds 2 percentage points on the license basis, taking the rate to about 24% (Rimini Street, Crowe). Two points on a 22-point base is close to a 9% increase in what you pay. Redress Compliance, a license negotiation firm, reports quotes of 2 to 4 points before negotiation (Redress), so the 2-point figure is the floor, not the ceiling.
In real dollars, on three maintenance bases, using the 2-point premium and before any negotiated relief, the premium looks like this.
| Annual SAP maintenance today | Extended maintenance premium per year | Premium over 2028 to 2030 |
|---|---|---|
| $5M | About $450,000 | About $1.4M |
| $10M | About $900,000 | About $2.7M |
| $20M | About $1.8M | About $5.4M |
The premium is small next to the migration it buys time for. On a $10M maintenance base, roughly $2.7M over three years sits against a migration that Redress puts in the millions to tens of millions. The money is not the risk in extended maintenance. The exit terms are. Once a customer is billed for the window, there is no mechanism to leave early, so a company that commits through 2030 pays through 2030 even if it goes live in 2029 (Redress). Settle that point before signing, not after.
Buying the transition licence is not the same as being live
SAP's third option is a private cloud subscription that carries ECC support to 2033 for customers who commit before 2028. It is the longest runway on offer, and it comes with a signature deadline that arrives well before the support date it buys.
The adoption numbers show why the distinction between buying and running matters. Gartner counted roughly 35,000 ECC customers, and by the end of 2024 about 39% of them had bought or subscribed to S/4HANA transition licenses (The Register). A license on the books is not a system in production. A company can hold a transition license, or sign the private cloud option, and still be two or three years from go-live with the whole program ahead of it. The subscription secures support and a commercial position. It does not move the 36-month clock on the work.
That is the trap in the 2033 figure. It reads as comfort, and the program timeline is comfortable. The commitment is not. A board that signs the private cloud option in 2027 has bought support to 2033 and has also agreed to a multi-year subscription before it has run a selection. The right default is to treat the signature as what it is, a commercial commitment with its own terms, and to negotiate it on the same footing as any other multi-year contract rather than as relief from a deadline.
Extended maintenance and third-party support are bridges, not destinations
The question executives ask most often is whether a bridge can replace the program for a long time. In our experience, no company uses extended maintenance or third-party support as a destination. Every one we have seen used it as a bridge to a planned go-live, and the ones that used it well decided early, built the premium into the program budget, and negotiated the exit terms while they still had bargaining power.
Third-party support providers price at roughly half the vendor's maintenance bill, according to Redress Compliance; Rimini Street, the largest such provider, claims savings of up to 90% (Redress). Both are sellers of the service, so the number to put in a business case is the quote you receive, not either claim. What a third-party contract does not include is SAP's own regulatory content, new functionality, or a return to vendor support without a reinstatement fee.
For a company with a dated go-live two or three years out, those gaps are tolerable, and a bridge can avoid the 25 to 40% cost penalty Redress attributes to a compressed migration (Redress). For a company with no date, the gaps compound. The eventual program gets harder, not easier, because the distance between the old system and the new one keeps widening. The decision rule is a function of one number, where your realistic go-live lands. If it falls inside the 2028 to 2030 window, buy extended maintenance. If it falls beyond 2030, bridge with the private cloud transition option or third-party support, and put an end date on the bridge in the budget.
Time the signature to SAP's December year-end, not the support date
It is widely assumed that SAP uses the support deadline to pressure customers into signing. We have not seen it work that way. The account teams we have negotiated against did not lean on the support date. What they offered were financial incentives to commit faster, and those followed SAP's quarter-end and year-end close, not any customer deadline.
That splits the calendar in two. The support date tells you when you must decide. SAP's fiscal calendar tells you when to sign, and SAP's fiscal year ends in December. A customer ready to commit in the last weeks of SAP's fourth quarter will usually see better terms than one who signs in January. The practical sequence is to finish selection and internal approval on your own timeline, then hold the signature for SAP's year-end. The converse holds too. An offer that expires in the last week of a quarter is about SAP's number, and it usually reappears next quarter.