Every year you pay your vendor a maintenance fee that mostly funds enhancements your end-of-life system will never receive. Faced with that equation, third-party ERP maintenance, offered by providers such as Rimini Street or Spinnaker Support, appeals to many CIOs and CFOs running SAP ECC, Oracle E-Business Suite or JD Edwards.
This article argues neither for nor against. It gives you a decision framework: what third-party support really covers, how to calculate a 5-year TCO, which contractual risks to examine, and how to combine it with a migration you are delaying but not abandoning.
This article is strategic analysis, not legal advice. License and support clauses depend on your contract: have your legal counsel review them before any decision.
Context: ECC end of support and budget pressure
SAP ends mainstream maintenance for ECC 6.0 at the end of 2027. Extended maintenance is available from January 2028 to December 2030, at a two-point premium on the maintenance base (SAPinsider, SAP support deadlines). For the migration options themselves, see our guide to SAP ECC end of support 2027: options for late movers, which we do not repeat here.
The budget problem is familiar: the maintenance bill stays flat or rises, while perceived value falls as the vendor’s roadmap concentrates on the cloud. Before looking at third-party support, clean up the baseline: our article on hidden ERP maintenance costs and our ERP license audit guide (in French) show that part of the savings is often available without changing provider.
Third-party providers position themselves exactly here. In June 2025, Rimini Street announced it would extend support to all releases of SAP ECC 6.0 and S/4HANA through 2040, claiming savings of up to 90% on total support cost (Rimini Street press release). That is the provider’s sales claim, not a result you will get by default: recalculate it against your own contract.
What third-party maintenance covers (and what it does not)
Third-party support replaces the vendor’s maintenance contract with a support service delivered by an independent provider. To decide well, separate what is usually covered from what is not.
Usually covered
- Incident handling (break/fix) with response-time commitments. Rimini Street highlights a named support engineer and a ten-minute response on critical cases (Rimini Street press release).
- Support for custom developments, which the vendor either does not handle or bills separately.
- Tax and regulatory updates, in a form that differs from the vendor’s (see below).
- Complementary security services, such as vulnerability monitoring, to be verified contract by contract.
Not covered
- New releases and functional enhancements from the vendor: by leaving maintenance, you give up future upgrades and vendor code fixes. Your system is frozen in its current state.
- Access to innovations (AI, new modules, user-interface changes) that are now delivered through cloud offerings.
- Any rights attached to maintenance in your contract: read them line by line.
The critical case of regulatory change: who delivers legal updates?
This point decides eligibility for a European company. E-invoicing, payroll filings, VAT returns, accounting changes: on a vendor-supported ERP, these arrive as patches or notes delivered under maintenance. With third-party support, the provider must analyze and reproduce them in another form, often as patches or workaround procedures.
Spinnaker Support describes its “Global Tax, Regulatory & Compliance” offering this way: monitoring tax and regulatory requirements, then delivering updates tailored to the software and the country (Spinnaker Support, capabilities overview). What this means for France, Germany or Italy varies sharply by topic. Ask the following questions, country by country and obligation by obligation:
- Which exact regulatory obligations are covered in my scope (countries, modules)?
- What is the delay between a rule taking effect and delivery of the update?
- Does the provider commit contractually to that delay, and with what penalties?
- Who tests the update in my environment, and who bears the risk in case of a filing error?
If your ERP must connect to e-invoicing platforms or filing formats that change regularly, this item alone can make third-party support unsuitable. Do not discover that after signing.
TCO: a 5-year calculation model
Do not compare two maintenance prices. Compare two cost trajectories over five years. Here are the variables to include.
Vendor maintenance side
- Annual maintenance fees, with the indexation set in the contract.
- Any extended-maintenance premium (for example, two points on ECC beyond 2027 per SAPinsider).
- Migration cost, spread over the period.
Third-party support side
- The provider’s annual fee and its indexation.
- Compliance costs, internal or external, that the vendor used to absorb (testing legal updates, adaptations).
- Complementary security cost if the provider does not cover it.
- Exit cost: a possible return to vendor maintenance, or migration to another system.
- Opportunity cost: enhancement projects deferred or funded separately.
Worked example, purely illustrative. Assume a mid-market company paying €1,000K a year in vendor maintenance; these are demonstration assumptions, not market data. With third-party support at €500K a year, gross savings over five years are €2,500K. But if you must add €150K a year in compliance and complementary security costs, net savings fall to €1,750K. If you also have to return to vendor maintenance in year 4 at a return cost of €400K, net savings drop to €1,350K. The result remains favorable, but it is very sensitive to your assumptions: redo this calculation with your own data and vary each variable by plus or minus 30%.
What matters is not the headline savings percentage, but the net difference once all ancillary costs are included, and how well it holds up in an adverse scenario.
Risks: returning to vendor support, license clauses, litigation
Going back to the vendor: a changing risk
Historically, the main brake on third-party support was the cost of returning. A vendor could demand reinstatement fees and back maintenance for the period of absence. That changed in 2026: on 9 July 2026, the European Commission made SAP’s commitments in case AT.40823 legally binding. SAP committed to removing reinstatement fees and reducing retroactive maintenance fees for customers who return after a period away. SAP also committed to clarifying the initial license term during which a support contract cannot be terminated, and to no longer restarting a new term with each additional license purchase. These commitments apply worldwide for ten years, under the supervision of a monitoring trustee (European Commission, press release IP/26/1554).
The consequence: the risk tied to returning is lower than before for SAP customers. It has not disappeared. The commitments do not freeze the commercial terms of your contract, and the detail of reduced retroactive amounts depends on how they are implemented. Ask SAP in writing for the return conditions applicable to your contract before terminating. For Oracle, return conditions fall under Oracle’s policy and your contract: do not transpose these SAP commitments.
License clauses and scope of use
Third-party support assumes you have the right to give a provider access to your software and its code. Check your contracts for:
- partial support termination conditions (some contracts require you to maintain or terminate all licenses together);
- clauses limiting the use of patches and updates obtained before termination;
- restrictions on third-party access to environments and code.
What a provider may do with the vendor’s software is precisely what has fueled the litigation.
Public litigation: Oracle v. Rimini Street
Oracle and Rimini Street have been in US courts for over a decade. In 2023, the Ninth Circuit affirmed four of the five contempt findings against Rimini Street for violating a 2018 permanent injunction, and reversed one; the facts included hosting Oracle files on Rimini’s systems and cross-using development environments (Ninth Circuit decision, 24 August 2023; IP Update analysis). The products concerned included PeopleSoft, JD Edwards, Siebel and Oracle Database.
What to take from it, carefully: this dispute concerns how a provider works with a vendor’s code, not the legality of third-party support as such. It does show that the provider’s working method (environment isolation, origin of fixes) is a due diligence item, and that you do not want to be exposed to indirect litigation. A US proceeding does not automatically carry over to a European contract: have your counsel analyze your situation.
Profiles where it fits, and where it does not
| Criterion | Rather relevant | Rather not relevant |
|---|---|---|
| Functional stability | Stable ERP, few enhancements expected | Frequent vendor enhancements needed |
| Regulatory exposure | Few local changes in scope | Many shifting local obligations (e-invoicing, payroll filings) |
| Geographic scope | One or two well-covered countries | Many countries, including atypical markets |
| Customizations | Heavy custom development poorly supported by the vendor | Near-standard ERP |
| Migration roadmap | Migration planned within 3 to 5 years | No defined path |
| Governance | In-house team able to manage a provider | Few internal skills |
| Vendor contract | Clear partial-termination conditions | Rigid or ambiguous license clauses |
Reading: third-party support is a cash-management tool for a stable system you know how to replace eventually. It is not a strategy for a system you hope never to touch.
Combining it with a migration strategy
The classic trap is using the savings to postpone migration indefinitely. The healthy scenario is the reverse: third-party support buys a 3-to-5-year window in which you prepare the target, and part of the savings funds that preparation.
- Years 1 and 2: stabilize, document, clean up custom developments. This is the “clean core” logic, detailed in our article on SAP clean core strategy with BTP.
- Years 2 and 3: choose the target and the integrator, launch the data and interface workstreams.
- Years 3 to 5: migrate, with the third-party contract exit date aligned to go-live.
Write the exit date and conditions in at signing: commitment term, notice period, no penalty for early termination linked to the migration. Also set a dedicated budget for the share of savings reinvested in the migration, otherwise the decision slips again.
5 common mistakes in the decision
Negotiating too late. Once you have given notice on vendor maintenance, your bargaining power with the vendor shrinks. Even if you stay, simply studying a credible alternative feeds a renegotiation of your fees, service levels or license scope. Use third-party offers as a benchmark from the audit stage, not only as a destination.
Confusing maintenance savings with run savings. Third-party support reduces neither hosting, nor operating costs, nor application management services (AMS). If your budget is dominated by those items, the lever is elsewhere, and the audit mentioned in the introduction will show you faster than a support tender.
Ignoring the organizational dimension. Changing support provider changes the escalation path, incident management processes and the relationship with your business teams. Appoint a contract owner on the IT side, and define who arbitrates when an incident involves the provider, the integrator and the vendor at once.
Underestimating regulatory compliance cost. The trap: comparing the third-party fee with the vendor maintenance without costing the testing and adaptation of the legal updates the vendor used to deliver. The consequence: net savings well below headline savings, or even negative on a multi-country scope. The countermeasure: include this item in the TCO and have it validated by the CFO and the compliance officer.
Signing without an exit clause aligned to go-live. The trap: a multi-year commitment unrelated to the migration calendar. The consequence: you pay for two supports in parallel, or you give up migrating on schedule to amortize the contract. The countermeasure: negotiate a penalty-free exit at the target’s production date, with a notice period compatible with your plan.
Due diligence checklist before signing
- Which countries, modules and regulatory obligations are covered, in writing?
- What is the delivery time for legal updates, and what are the penalties for delay?
- Who bears the risk of a compliance error caused by a third-party update?
- How does the provider work on the vendor’s code (environment isolation, origin of fixes)?
- Does your vendor contract allow partial termination? Have you obtained a written answer from the vendor?
- What are the written conditions for returning to the vendor (reinstatement fees, retroactivity)?
- What security scope is included, and what must you add?
- What are the commitment term, indexation and early-exit conditions?
- Which comparable references (same release, same country, same industry) can you contact directly?
- What is the net 5-year TCO in three scenarios (favorable, central, adverse), validated by the CFO?
Going further
If you are torn between third-party support, extended maintenance and accelerated migration, a trajectory assessment can cost all three scenarios with your own data before you commit. Contact us to discuss it. You can also dig deeper with our guide to SAP ECC end of support 2027 and our method for auditing ERP maintenance costs.
