Oracle Third-Party Support Savings Benchmark 2026

How much does Oracle third-party support actually save?

The single largest recurring line in a mature Oracle estate is not licences — it is support. Oracle third-party support is independent maintenance for Oracle software provided by a vendor other than Oracle, such as Rimini Street or Spinnaker Support, covering break-fix, tax and regulatory updates, and security mitigation for the Oracle versions you already run. Oracle's own equivalent, Oracle Software Update License & Support (SULS), is priced at 22% of the net licence fees you originally paid and rises every year at renewal. Third-party providers price the same coverage at roughly half that number, and they do not apply an annual uplift. That two-part difference — a lower base, then a frozen base — is why the saving widens the longer you measure it.

Across the Oracle Licensing Experts engagement base, the median first-year saving on the annual support fee is 52%. The reason it is not exactly 50% — the figure third-party providers advertise — is that real moves rarely transfer the entire estate. Buyers keep a slice on Oracle support for workloads still chasing patches and new releases, and the blended saving on the migrated portion runs a few points either side of half depending on product mix and provider. Where the whole stable estate moves, the first-year saving lands at the full 50%; where only the most mature applications move, the realised saving on that slice exceeds 55% because almost no Oracle code is being forgone.

The table below sets the two models side by side on a $1.0M Oracle support base and carries them forward, because the headline percentage understates the real gap. Oracle support compounds at a median 6.0% a year — the figure documented in our companion Oracle support renewal uplift tracker — while the third-party fee holds flat for the life of the contract. By year ten the Oracle bill has grown 69% while the third-party bill has not moved, so the annual saving that started at 52% has widened to roughly 71% on a single-year comparison, and 62% measured across the cumulative decade.

Read the bottom two rows together and the strategic point is clear: the value of third-party support is not the one-off discount, it is the permanent removal of the uplift. A buyer who negotiates a hard cap with Oracle slows the compounding; a buyer who moves to third-party support stops it. On the $1.0M base above, the decade saving is $8.38M — more than eight times the original annual fee — and every dollar of it comes from money Oracle would otherwise have collected for maintenance on software the customer already owns outright.

Executive summary

Oracle support is sold as a service and behaves like a tax. For software you have already bought outright under a perpetual licence, Oracle bills 22% of the net licence value every year for the right to patches, upgrades, and a support line — and raises that bill annually whether or not you consume anything new. For estates that have stopped chasing the latest release, this is the least scrutinised large cost in the IT budget, paid on autopilot because letting support lapse feels riskier than absorbing another increase. Third-party support exists precisely to break that asymmetry, and this benchmark quantifies how far it goes.

The central finding is that independent third-party support saves a median 52% on the annual support fee in year one, and far more over time. Because providers freeze the fee for the contract term while Oracle compounds at a median 6.0% a year, the five-year support TCO falls 56% and the ten-year TCO 62% — on a $1.0M base, that is $8.38M kept inside the business over a decade. The saving is not uniform: mature applications such as E-Business Suite, PeopleSoft, JD Edwards and Siebel net 60% or more over five years because they are off the active release cycle and almost no Oracle code is forgone, while Database Enterprise Edition nets around 55% net because a larger share of those customers still value Oracle's patch stream.

The decision is not all-or-nothing. In our engagement base, 62% of a typical estate's support spend sits on workloads genuinely suited to third-party support — stable, on a current or terminal release, not bound to a near-term upgrade or cloud roadmap. The remaining 38% stays with Oracle because it needs active patches, new releases, or specific roadmap access. The right answer is almost always a hybrid: move the stable majority, keep the roadmap-bound minority, and re-test the split at each renewal as workloads mature.

The one number that must be modelled before any move is reinstatement. Oracle charges the back-support fees for the lapsed period plus a penalty of about 150% of those fees, then resumes billing at the current uplifted rate — roughly $2.5M to undo a single year's lapse on a $1.0M base. That penalty is not a reason to stay; it is a reason to plan the move as a permanent exit for the workloads that qualify, and to keep on Oracle support only what you genuinely intend to upgrade. The rest of this report segments the saving by product family and estate size, models the TCO and reinstatement maths, sets out what you keep and what you give up, addresses the legality question head-on, and lays out the sequence we use to take an estate to third-party support without creating a compliance gap.

Methodology & data set

The numbers in this report are drawn from the support reviews, renewal analyses, and third-party support evaluations our advisors have run for global enterprises over more than two decades. The data set spans organisations from roughly $500K to more than $40M in annual Oracle support spend, across Database Enterprise Edition and its options, Oracle Fusion Middleware (WebLogic, SOA Suite, Oracle Service Bus), and the major applications — E-Business Suite, PeopleSoft, JD Edwards EnterpriseOne, and Siebel CRM. The reference period for pricing is the 2026 Oracle Technology price list and current published third-party provider rate cards.

Three methodological choices shape how the figures should be read. First, every saving is expressed against the customer's current Oracle support fee, not against list, because that is the number a buyer is actually deciding to stop paying. Second, the "annual fee saving" measures the first-year reduction on the migrated portion of the estate, while the "TCO" figures carry both models forward — Oracle compounding at the 6.0% median uplift, third-party support frozen — so the gap widens over the measurement window. Third, the suitability percentages describe the share of support spend, not the count of systems, because a single high-value Database cluster can outweigh dozens of small instances.

These are aggregated advisory benchmarks intended to let a CIO, CFO, or procurement lead sanity-check a third-party support business case against comparable estates. They are not a substitute for a forensic review of a specific environment: the realised saving on any given estate depends on the current discount embedded in the support base, the product mix, the provider chosen, and how much of the estate is genuinely off the upgrade path. Every figure is an illustrative aggregate, carries the label "Oracle Licensing Experts benchmark, 2026," and is anonymised so that no individual client engagement can be identified. Oracle Licensing Experts is independent and not affiliated with Oracle Corporation; we hold no reseller relationship with any third-party support provider, so the analysis is buyer-side and unbiased.

How much can you save by Oracle product family?

Third-party providers price at roughly half your Oracle fee regardless of product, so the headline year-one saving is broadly similar across the estate. The variance in the table below comes from the net saving — the gross fee reduction minus the value of what you actually give up. For a stable application like Siebel CRM, which Oracle places years into extended or sustaining support with no meaningful new releases, the value forgone is close to zero, so the net saving approaches the gross. For Database Enterprise Edition, where more customers still apply quarterly Critical Patch Updates and may want to move between release versions, a portion of the gross saving is offset by the patch access being replaced, so the realised net saving is a few points lower.

The applications picture is the most compelling part of the third-party support case, and it is the one Oracle works hardest to obscure. E-Business Suite, PeopleSoft, and JD Edwards customers are paying 22% a year, rising, for a code base Oracle is no longer meaningfully enhancing. The patches that matter to those estates — payroll tax tables, statutory and regulatory updates, year-end legislative changes — are exactly what mature third-party providers specialise in delivering, often faster than Oracle and with a named engineer rather than a service-request queue. The customer keeps the perpetual licence, keeps running the software indefinitely, and pays roughly half the maintenance for support that is, for a stable applications estate, functionally equivalent or better.

Database Enterprise Edition and Middleware sit in the "conditional" band not because the saving is poor — 55–56% net over five years is substantial — but because the decision needs a sharper look at the upgrade roadmap. A Database estate sitting on a long-term-support release such as 19c, with no plan to move to 23ai for several years, behaves like a mature application and captures close to the full saving. A Database estate mid-migration, or one that depends on the latest security patches for regulatory reasons, should keep that portion on Oracle support and move only the stable remainder. This is exactly the hybrid split the suitability section quantifies, and the reason a product-by-product review beats a blanket decision in either direction.

The reason the net saving exceeds the gross fee reduction for the most mature applications repays a closer look, because the arithmetic is counter-intuitive at first glance. The gross saving is the fee you stop paying Oracle. The net saving adds back the value of what you would otherwise have consumed — and for a code base Oracle has placed into sustaining support, that value is close to zero, so almost none of the gross is clawed back. For Siebel and the stable applications, you were paying 22% a year, rising, for upgrade rights you were never going to exercise and feature releases that were never coming; converting that to a frozen fee at half the price loses you nothing you valued. For Database Enterprise Edition the net sits below the gross precisely because a meaningful share of those customers do consume Oracle's quarterly patch stream and do move between versions, so part of the fee bought something real. The product-family table is, in effect, a map of how much of your Oracle support fee is buying maintenance you actually use versus rights you are paying to keep idle.

What is the 5- and 10-year TCO delta of leaving Oracle support?

The year-one percentage is the wrong number to plan around, because it ignores the mechanism that makes Oracle support so expensive: compounding. Oracle support is not a flat fee; it is a 22% base that rises at a median 6.0% a year, so the bill in year ten is 69% higher than in year one even if you add nothing. Third-party support replaces that escalating curve with a flat line. Modelling both forward is the only way to see the real decision, and it turns a "save half" headline into a "save nearly two-thirds over a decade" reality.

The table below carries a $1.0M Oracle support base across ten years against a third-party fee fixed at $0.48M — the median migrated-estate rate. Oracle's column compounds at 6.0%; the third-party column holds. The cumulative rows are what a CFO should anchor on, because they capture the total cash difference, not a single-year snapshot.

Two figures inside this table deserve emphasis. The first is the year-ten annual saving of $1.21M — by the end of the decade the customer is saving more each year than the entire original annual fee, because Oracle's bill has grown 69% while the third-party bill has not moved at all. The second is the cumulative $8.38M, which is the number that belongs in the business case. Against the typical cost of a third-party support transition — provider onboarding, a licence-grant review, and an internal estate inventory — that decade saving represents a return measured in multiples within the first year, and it is recurring cash, not a one-time reduction.

A note on discounting: a strict net-present-value model trims the headline cumulative saving because future dollars are worth less, but it does not change the decision. At a 6.0% Oracle uplift and any plausible discount rate below it, the present value of the saving still runs well into seven figures on this base, because the saving is front-loaded — it starts at 52% in year one and only grows. The compounding works against the buyer on Oracle support and for the buyer the moment the fee is frozen.

Which Oracle estates are suited to third-party support?

Third-party support is not a fit for every workload, and any honest benchmark has to say so. The deciding question is simple: does this system need Oracle's own code in the foreseeable future? If it is stable, running a release you intend to keep, and the patches that matter are regulatory and break-fix rather than new features, it is a candidate. If it is mid-upgrade, depends on Oracle's latest security patches for compliance reasons, or is bound to a cloud or product roadmap that requires an active Oracle relationship, it stays on Oracle support. The 62% figure is the share of support spend — not systems — that falls on the candidate side of that line in a typical mature estate.

Suitability varies sharply by product, and the pattern follows Oracle's own release cadence. Applications that Oracle has moved into extended, sustaining, or "continuous innovation" support with no disruptive new releases — Siebel, PeopleSoft, JD Edwards, and stable E-Business Suite — are the strongest candidates, because the customer is paying full maintenance for a code base that is barely changing. Database and Middleware are more mixed: a terminal-release Database estate is a strong candidate, while one mid-migration to a new version is not. The table below shows the share of each product family's support spend our reviews typically find suited to a third-party move.

The practical consequence is that the right move for most enterprises is a hybrid, not a binary. Splitting the estate lets you capture the saving on the stable 62% while keeping Oracle support on the roadmap-bound remainder — and it sidesteps the all-or-nothing framing Oracle's account teams reach for when a customer raises third-party support. There is one structural caveat to model carefully: where the workloads you keep on Oracle support share a Customer Support Identifier or a matched support set with the workloads you want to move, Oracle's repricing rules can re-rate the support on what you keep. That matched-set mechanic, examined in our uplift research, is why the support set map must be reconstructed before any partial move — the saving is real, but the structure determines how cleanly you can realise it.

What does it cost to reinstate Oracle support if you go back?

Reinstatement is the mechanism Oracle relies on to make leaving feel irreversible, and it is the single most important number to understand before any third-party move. Oracle support reinstatement is the fee Oracle charges to restart maintenance after it has lapsed: the back-support fees you would have paid during the gap, plus a reinstatement penalty of approximately 150% of those back fees, after which support resumes at the then-current — uplifted — rate. The penalty exists for exactly one reason: to ensure that a customer who leaves cannot treat Oracle support as something to switch off and on opportunistically.

The table models the reinstatement cost against the fees avoided, on the same $1.0M Oracle base, for support holidays of increasing length. The avoided figure is what you did not pay Oracle during the lapse; the reinstatement figure is what Oracle would charge to bring you back. Read together, they show why a lapse only makes financial sense if it is permanent.

The pattern in the net column is the point: no matter how long the lapse, returning to Oracle costs roughly $1.5M more than never having left, because the 150% penalty scales with the fees you avoided. That is by design — Oracle wants the reinstatement maths to look so punitive that customers never seriously consider third-party support. But the table also contains the counter-move, in its bottom row. The rational version of stopping payment is not a holiday you intend to reverse; it is a permanent exit for workloads you have decided to keep running as-is. For those workloads, you never reinstate, so the penalty never applies, and the saving is pure and recurring.

There is a second, subtler cost the reinstatement table does not show, and it is the one that traps unprepared buyers: the version gap. While you are on third-party support you are not taking Oracle's patches or upgrades, so the software drifts further from Oracle's current release with each year. If you later decide to return, reinstatement buys you back the support contract but not the lost time — you may face a substantial upgrade project to reach a version Oracle still supports before the reinstated maintenance is of any use. This is another reason the move should be reserved for workloads you genuinely intend to freeze: for a stable application you will run as-is, the version gap is irrelevant because you were never going to upgrade; for a system you might want to advance, the gap compounds the reinstatement penalty and the two together make a round-trip genuinely expensive. The discipline, again, is to move only what you will keep still.

This is why provider selection and exit planning matter as much as the headline saving. A credible third-party provider underwrites the support you are giving up — security mitigation, regulatory updates, break-fix — so that "permanent" is a safe position rather than a leap. The reinstatement penalty should shape which workloads you move, not whether you move at all: keep on Oracle support anything you genuinely expect to upgrade, move the stable estate you intend to run untouched, and the penalty becomes irrelevant to the systems that deliver the saving. We model the full reinstatement exposure for every workload before a client commits, precisely so the decision is made with the worst case on the table, not hidden under it.

What do you keep and what do you give up with third-party support?

The most common misconception about third-party support is that you are surrendering your licences. You are not. Your Oracle licences are perpetual: you bought the right to run that software forever, and dropping Oracle support changes nothing about that grant. What you stop buying is maintenance — the annual fee for Oracle's patches, upgrades, and support line. The software keeps running exactly as it did the day before. The decision is therefore narrow: is Oracle's maintenance stream worth 22% a year, rising, for this workload — or is independent maintenance at half the price sufficient for software you intend to keep as-is?

The table below maps what transfers and what does not. The crucial column is the third-party replacement: a mature provider does not simply drop the items Oracle stops supplying — it substitutes its own engineering for most of them. Tax, legal, and regulatory updates for payroll and financials are delivered by the provider, often faster than Oracle. Security is handled through "virtual patching" and configuration hardening rather than Oracle's binary patches. What genuinely cannot be replaced is Oracle's proprietary code: new product versions, Oracle's own Critical Patch Updates, and certified upgrades. Those require an active Oracle Software Update License & Support contract, full stop.

For a stable estate, the give-up column is largely theoretical. A Siebel or PeopleSoft customer who has no plan to upgrade is paying Oracle for version upgrades it will never take and Critical Patch Updates it can have mitigated another way — so the items "lost" were not being used. For a Database estate that applies every quarterly Critical Patch Update for regulatory reasons, the calculus is different, and that workload likely belongs in the 38% that stays on Oracle support. The scope table is not an argument for or against; it is the checklist that decides, workload by workload, which side of the hybrid line each system falls on.

One element deserves a direct word: security. Oracle's strongest retention argument is that leaving its support means leaving its Critical Patch Updates, and therefore exposure. In practice, mature third-party providers address vulnerabilities through virtual patching at the network and application layer, configuration hardening, and rapid mitigation guidance — an approach security teams increasingly accept for stable, well-segmented estates. The honest position is that the security trade-off is real and must be assessed per workload with the security team in the room; it is neither the disqualifier Oracle implies nor a non-issue. For internet-facing or highly regulated systems, weight it heavily; for well-segmented internal applications, it is routinely manageable.

Is third-party support for Oracle legal?

The legality question is the one Oracle account teams raise first, and it is worth answering precisely because the fear it creates is disproportionate to the actual legal position. There is nothing in an Oracle licence that requires you to buy support from Oracle. Support is a separate, annual, cancellable contract; the perpetual licence stands on its own. Dropping support is a routine commercial decision, exercised by thousands of organisations, and it does not breach the licence grant.

The reason the question feels fraught is the decade-plus of litigation between Oracle and Rimini Street — the most prominent independent provider. That history is instructive rather than disqualifying. The courts have consistently held that third-party support itself is lawful; the disputes turned on how a provider delivered it — specifically, whether software was copied, cross-used between customers, or hosted on the provider's own systems in ways the licences did not permit. The outcome reshaped how compliant providers operate: modern third-party support is delivered within the customer's own environment and licence grant, which removes the conduct that was ever found objectionable. The headline for a buyer is that the practice is legal, and the compliance burden sits with the provider's delivery model, which is exactly what provider due diligence should examine.

This is where independent, buyer-side advice protects you in a way a provider's sales team cannot. The right questions are forensic: does the provider deliver support without copying Oracle's code outside your grant; how does it handle updates it develops; what are its indemnities; and — critically — does anything in your ordering documents or Oracle Master Agreement create an unusual constraint? We review the licence grant, the support contract terms, and the provider's delivery model together, so that the move is made on solid ground and the "is it legal?" objection is answered with evidence rather than reassurance. Note that this report is benchmarking and licensing guidance, not legal advice; the legal characterisation of any specific contract should be confirmed with qualified counsel.

What Oracle doesn't tell you about third-party support

Oracle's retention playbook against third-party support is consistent, and recognising it is half the battle. The first move is the security argument — "leave our support and you lose Critical Patch Updates." It is the strongest point and the one to assess seriously, but it is presented as a disqualifier when it is a workload-by-workload trade-off that mature providers address through virtual patching. The second move is the legality insinuation, designed to make a lawful, routine decision feel risky; the litigation history reshaped provider conduct, it did not make the practice illegal. The third move is the cloud pivot — an offer of OCI credits or Support Rewards framed as a "better" answer than third-party support, which converts a maintenance saving into new cloud commitment and lock-in.

What Oracle never volunteers is the reinstatement-as-deterrent logic in plain terms: the 150% penalty is not there to price a service, it is there to make sure you never test the alternative. Nor does Oracle mention that the support set structure can often be reorganised before a partial move to protect the support on what you keep, or that a credible provider will underwrite the regulatory and security updates you are most worried about losing. The renewal quote arrives as a single number with a deadline precisely so that the question "should we still be buying this from Oracle at all?" never gets asked. The whole point of an independent benchmark is to put that question back on the table with the numbers attached.

The last unspoken fact is the most important: the saving is recurring and the decision is reversible only at a cost, which means the value of getting it right is enormous and the value of getting expert eyes on it before you act is correspondingly high. A botched partial move that triggers matched-set repricing, or a provider chosen on price alone whose delivery model creates a compliance gap, can erase the saving. Done properly — the support set mapped, the suitable workloads identified, the provider vetted, the licence grant confirmed — third-party support is among the cleanest large savings available in the entire Oracle relationship.

Recommendations: how to capture the third-party support saving safely

Third-party support fails most often not because the saving is illusory but because the move is rushed — a partial termination that triggers repricing, or a provider picked on price whose model creates exposure. The following sequence is the one we run to capture the saving cleanly.

1. Inventory the estate and the support spend by workload. Map every product, version, support line, and Customer Support Identifier, with the current fee and the upgrade intent for each. You cannot decide what to move until you can see where the spend sits and which systems you actually intend to keep as-is.
2. Separate the stable workloads from the roadmap-bound ones. Classify each system as a candidate (stable, current or terminal release, no near-term upgrade) or a keep (mid-migration, CPU-critical, roadmap-bound). The candidate set is your saving; the keep set protects your access to Oracle code where you genuinely need it.
3. Reconstruct the support set map before any partial move. Where candidate and keep workloads share a matched support set or CSI, model Oracle's repricing impact on the workloads you keep before you terminate anything. Never trigger a partial termination blind — restructure the sets first where the contract allows.
4. Run forensic provider due diligence. Assess each provider's delivery model (support delivered within your grant, no improper copying or cross-use), its regulatory and security update track record, its SLAs, and its indemnities. Price is the last screen, not the first.
5. Model the reinstatement exposure on the workloads you move. Confirm you genuinely intend to run each moved workload as-is, so the 150% reinstatement penalty never applies. Anything you might upgrade stays on Oracle support.
6. Bring the security team in early. Assess the virtual-patching and hardening approach per workload, weighting internet-facing and highly regulated systems heavily and well-segmented internal systems lightly. Document the security position before, not after, the move.
7. Time the move against the Oracle renewal date. Transition before the next renewal so you stop the uplift cleanly, and avoid co-terming traps that drag a moved workload back into an Oracle invoice. Re-test the hybrid split at every subsequent renewal as workloads mature into candidates.