Third-Party Support for Oracle Database: The 2026 Buyer-Side Guide

What Is Third-Party Support for Oracle Database?

Third-party support for Oracle Database is an independent maintenance contract that replaces Oracle Premier Support with a non-Oracle provider who delivers break-fix support, performance and configuration assistance, security advisory, and interoperability guidance for your Oracle Database estate — while you keep your Oracle perpetual licenses and keep running the databases unchanged. You stop paying Oracle the 22% annual maintenance fee and pay a third-party provider roughly half that instead.

This is legal and well established. An Oracle perpetual license grants indefinite use rights for the licensed Database edition and options. Those rights do not expire when you stop buying Oracle support — the software keeps running, your entitlement is unchanged, and nothing in the license agreement forces you to maintain an active support contract to keep using what you already own. The two primary providers are Rimini Street, the publicly traded market leader, and Spinnaker Support, a more consultative firm focused on complex environments. Both have supported thousands of Oracle Database environments for over a decade.

The practical question is never whether you are allowed to switch — you are — but what you receive in return for half the cost. For databases specifically, the answer hinges almost entirely on one thing: Oracle's Critical Patch Updates. We deal with that head-on below.

How Much Does Third-Party Support Save on Oracle Database?

Third-party support for Oracle Database saves roughly 50% of your current Oracle annual maintenance bill in year one, with contractually capped annual increases that run far below Oracle's uncapped uplifts. Because Oracle Database carries the highest support load of any product line, the absolute dollar saving is usually the largest single line item available to a support-reduction program.

Oracle charges 22% of net license value per year for Enterprise Support, and applies that percentage to Enterprise Edition Processor licenses and every option licensed on top — Partitioning, Real Application Clusters (RAC), Advanced Security, Diagnostics Pack, Tuning Pack, In-Memory and the rest. A database estate with several options stacked per processor can carry an effective support rate well above the headline license price. Cutting that in half is material.

In our engagement data, Oracle Database Enterprise Edition plus its stacked options accounts for 55–70% of total annual Oracle support spend in a typical enterprise estate (Oracle Licensing Experts, 2026). That concentration is exactly why the Database is the first place a buyer-side advisor looks when the brief is to cut support cost. For a worked financial model, see our companion guide on the third-party support ROI model, and our insurance company case study showing a $2.8M annual saving.

Which Oracle Database Versions Are the Best Candidates?

The strongest third-party support candidates are stable, mature Oracle Database releases where you are no longer consuming Oracle's roadmap — primarily 11g, 12c and settled 19c estates. The weakest candidate is Oracle Database 23ai, where the current feature set and roadmap still carry active value worth paying Oracle to receive.

The decision is version-by-version and workload-by-workload, not all-or-nothing. Many enterprises move legacy 11g and 12c databases to third-party support while keeping a strategic 19c or 23ai footprint on Oracle Premier Support — preserving roadmap access where it matters and harvesting savings where it does not. This split approach also softens the commercial relationship impact discussed below.

For the wider product context — including Oracle's lifetime support timeline and where Extended Support fees bite — see our Oracle Database licensing guide.

Do You Lose Security Patches — and Does It Matter for a Database?

Yes, you lose Oracle's quarterly Critical Patch Updates, and for a database this is the tradeoff that decides the whole question. Third-party providers cannot redistribute Oracle CPUs; instead they deliver independent vulnerability advisory, configuration hardening, virtual patching guidance at the network and access layer, and in some cases independently developed fixes. Whether that substitute is adequate depends on the specific database's exposure, not on a blanket rule.

The honest, buyer-side assessment is that the answer varies sharply by deployment. An internal-only data warehouse behind multiple network controls, with no direct internet exposure and tightly governed access, carries a very different risk profile from an internet-facing transactional database holding cardholder or patient data. For the former, the loss of Oracle CPUs is often manageable with compensating controls. For the latter — especially under PCI-DSS, HIPAA or FedRAMP regimes that may expect vendor-supplied patching — third-party support on that specific database may be the wrong call regardless of the saving.

This is where buyers most need independent analysis rather than a provider's sales deck or Oracle's fear messaging. We assess each database's exposure, regulatory obligations, and compensating controls before recommending which databases can safely move and which should stay on Oracle support. That forensic, evidence-based split is the difference between a defensible support strategy and an audit-and-security liability.

Does Third-Party Support Cover RAC, Data Guard and Database Options?

Yes. Both Rimini Street and Spinnaker Support cover the full Oracle Database stack as deployed — Enterprise Edition and Standard Edition 2, Real Application Clusters (RAC), Data Guard, Partitioning, Advanced Security, Diagnostics Pack, Tuning Pack, In-Memory and the other options. The provider supports the configuration you are licensed to run; it does not alter, expand, or reduce your underlying Oracle license entitlements.

One point deserves emphasis because Oracle's account teams sometimes blur it: moving to third-party support changes who supports the software, not what you are licensed for. Your Processor and Named User Plus (NUP) entitlements are unchanged, and your compliance position is exactly what it was the day before you switched. That is precisely why a clean compliance position matters so much before you transition — any pre-existing options gap (a Diagnostics Pack accidentally enabled, a RAC node mis-counted) does not disappear, it simply becomes harder to resolve once your Oracle relationship is adversarial.

How Does Oracle Respond When You Move Database Support to a Third Party?

Oracle's response to a Database support termination is a predictable playbook: a senior escalation call, a discounted retention offer, warnings about security and upgrade rights, and — for some accounts — heightened audit attention. None of this is a reason not to switch; it is a set of moves to anticipate and use.

The escalation call typically arrives once Oracle's systems register your termination notice. Expect assertions about the risk of running databases without CPUs, a retention discount of 30–40% below your standard support rate contingent on a multi-year commitment, and pointed questions about your Database roadmap. Treated correctly, this call is leverage: if you were prepared to switch, you can document Oracle's discount offer and weigh it against the third-party quote — sometimes capturing a deep Oracle discount while staying on Premier Support for the databases where that makes sense.

The audit risk is real but manageable. Oracle's LMS team operates on its own risk model, and an account that has just terminated Database support sits in a higher-attention bracket because Oracle has less commercial incentive to keep the compliance conversation cooperative. The defense is preparation: close any compliance gap before you give notice. Our Oracle audit defense and compliance review teams run this pre-transition health check as standard.

How Do You Transition Oracle Database to Third-Party Support Safely?

A safe Oracle Database transition follows a defined sequence that protects you operationally and commercially. Rushing the notice to Oracle before the groundwork is done is the most common — and most expensive — mistake.

1. Run a forensic compliance review first. Identify and close any Database options or NUP gaps before Oracle knows you are leaving. A gap is far cheaper to fix while the relationship is still cooperative.
2. Inventory every database, version and option. Document exact version strings, patch levels, options in use, and configuration (RAC, Data Guard) for each instance — providers scope and price from this.
3. Archive software, patches and documentation from My Oracle Support. Once support is terminated, your access to MOS downloads for those products ends. Pull everything you may need first.
4. Evaluate Rimini Street and Spinnaker on a real RFP. Reference-check with enterprises running similar Database estates; negotiate price, annual increase caps, security response SLAs, and exit terms.
5. Give Oracle contractual notice and use the escalation call. Notify per your support schedule's notice period (typically 30–90 days) and document any retention discount Oracle offers as a comparison point.
6. Run a 60–90 day overlap. Keep both contracts live briefly so your DBAs build confidence in the provider's response before fully terminating Oracle support.

For the full menu of support-cost levers beyond third-party support, see our Oracle support cost reduction guide.

Frequently Asked Questions