Oracle Third-Party Support Eligibility Checklist: Are You a Good Fit?

What Does Oracle Third-Party Support Eligibility Mean?

Oracle third-party support eligibility is the assessment of whether a given Oracle product estate is a sound candidate to move from Oracle's own Premier Support to an independent support provider such as Rimini Street or Spinnaker Support. It is a strategic and financial test, not a permission question — there is no Oracle approval required to switch.

Third-party support is the practice of replacing Oracle's annual maintenance contract with an independent provider who delivers functionally equivalent services — break-fix support, tax, regulatory, and legal (TRL) updates, security advisory, and interoperability guidance — at a substantially lower annual cost. Your Oracle perpetual licenses remain fully valid; you simply stop paying Oracle for support and pay a third-party provider instead. For the mechanics, provider comparison, and transition process, read our full Oracle third-party support guide.

Because perpetual use rights are not contingent on an active Oracle support contract, the eligibility question is never "can we legally do this?" — the answer is almost always yes. The eligibility question is "should we, for which products, and what do we lose?" That is what this checklist resolves. Getting it wrong in either direction is expensive: moving a product that still needs Oracle's roadmap strands you without patches, while keeping a stable legacy product on Oracle support burns 22% of net license value every year for support you barely use.

What Makes an Oracle Estate a Good Fit for Third-Party Support?

The strongest candidates share four characteristics, and the more of them apply, the cleaner the decision.

1. Version stability and maturity. The product runs a stable, well-understood version — Oracle Database 11g, 12c, or 19c on steady workloads; Oracle E-Business Suite 12.1 or 12.2; PeopleSoft, JD Edwards, or Siebel CRM in their mature, non-evolving states. These products have already received the functionality the business needs and are not on a Oracle-driven upgrade path. When you are not consuming new releases, you are paying Oracle's 22% maintenance fee almost entirely for the right to patches and upgrades you will never take.

2. Low appetite for new Oracle features. The business has no roadmap dependency on Oracle's product direction — no plans to adopt Database 23ai capabilities, no demand for new EBS modules, no interest in Oracle's latest middleware releases. Where the roadmap is irrelevant, the largest component of Oracle support's value disappears.

3. Heavy customisation. Counter-intuitively, the more customised the environment, the better the fit. Oracle's standard support explicitly excludes support for custom code; customers with heavily modified EBS or PeopleSoft instances already shoulder that burden in-house. Providers such as Spinnaker Support build support of customisations and break-fix on custom objects into their model — delivering more than Oracle does, for less.

4. Genuine cost pressure. There is a clear mandate to reduce IT operating cost, and the Oracle support line item is large enough to matter. For an estate paying $4M–$6M a year in Oracle maintenance, a 50% reduction is a board-level number. Our Oracle support reduction service exists precisely to convert that pressure into a defensible, modelled saving.

When Is Third-Party Support a Poor Fit?

The disqualifiers are as important as the qualifiers, and an honest eligibility assessment names them plainly.

Needing new Oracle patches or certifications. This is the single most decisive disqualifier. Oracle delivers official, source-level Critical Patch Updates (CPUs) every quarter; third-party providers cannot ship Oracle's patches and instead provide independent security advisory and workarounds. If your security or compliance posture — PCI-DSS, HIPAA, FedRAMP — mandates vendor-supplied patches, or you depend on Oracle certifying new OS, browser, or interoperability stacks, you should stay on Oracle support for those products.

Imminent upgrades. If a product is scheduled for a major version upgrade in the next 12–24 months, third-party support is the wrong move. Oracle's policy ties certain upgrade rights to active support, and you would likely have to reinstate Oracle support — paying back-support fees — to take the upgrade. Moving to third-party support and immediately needing to come back is the most expensive sequence possible.

Active cloud roadmap. Enterprises mid-flight on an Oracle-to-OCI migration should not move the affected products to third-party support. Oracle's cloud migration incentives — including Support Rewards, which return OCI credits against your support bill — require active Oracle Premier Support. Dropping support forfeits those credits and the commercial goodwill that lubricates a cloud negotiation.

Fast-moving or subscription products. Oracle Database 23ai (the current release, where the roadmap is genuinely valuable), Oracle Fusion Cloud SaaS (subscription-based, outside the third-party model), and Oracle Java SE (where licensing is shifting rapidly and Oracle's own position can be strategically relevant) are weak candidates. For Java specifically, our Java licensing advisory handles a different set of levers entirely.

The Oracle Third-Party Support Eligibility Checklist

Run this checklist product by product. Treat the first list as the qualifying signals and the second as the disqualifiers. A product that clears most of the first list and trips none of the second is a strong third-party support candidate.

Qualifying signals — you are likely a good fit if:

• The product runs a stable, mature version (Database 11g/12c/19c, EBS 12.1/12.2, PeopleSoft, JD Edwards, Siebel) on steady workloads.
• No major version upgrade is planned within the next 24 months.
• The business has no roadmap dependency on new Oracle features for this product.
• The environment is heavily customised, and Oracle already excludes that custom code from support.
• There is real, mandated pressure to reduce IT operating cost.
• Your security and regulatory obligations can be met with independent advisory plus your own patch governance, rather than Oracle-supplied CPUs.
• You have a clean, defensible Oracle license position with no open compliance gaps.

Disqualifiers — reconsider or stay on Oracle support if:

• You actively consume Oracle's quarterly Critical Patch Updates for compliance.
• A regulator or framework mandates vendor-supplied security patches specifically.
• You need Oracle to certify new OS, browser, or interoperability stacks.
• A major upgrade (for example, to Database 23ai or a new EBS release) is imminent.
• You are executing an Oracle-to-OCI migration and rely on Support Rewards.
• The product is Fusion Cloud SaaS or a fast-moving release where the roadmap is genuinely valuable.
• There is a realistic chance you will need to reinstate Oracle support within 3–5 years.

The last point on each list deserves emphasis: a clean compliance position is a prerequisite, and the reinstatement scenario must be priced in. We cover both below and in our Oracle third-party support advisory, which runs this checklist forensically across every product in the estate.

Good-Fit vs Poor-Fit: The Eligibility Signals Side by Side

The table below condenses the checklist into the decision signals our analysts weigh most heavily when scoring a product for third-party support eligibility.

No single row decides it. A product can sit on a perfect legacy version and still be a poor fit if a regulator mandates Oracle-supplied patches. The scoring weighs every row together — but in practice, the patching, upgrade, and cloud-roadmap rows carry the most weight, because they represent capabilities third-party support cannot replicate.

Does Heavy Customisation Help or Hurt Eligibility?

This is one of the most misunderstood eligibility factors. Buyers often assume that a complex, heavily customised Oracle environment is too risky to move off Oracle support. The opposite is usually true. Oracle's support contract covers Oracle-shipped code; the moment you modify a form, extend a table, or build custom interfaces, that work falls outside Oracle's support scope. Enterprises with mature EBS or PeopleSoft instances have typically accumulated years of customisation that Oracle would never touch in a support ticket.

Third-party providers compete precisely on this gap. Both Rimini Street and Spinnaker Support offer support of customisations and the surrounding stack, and Spinnaker in particular markets a consultative, senior-engineer model suited to complex environments. For a customised estate, the practical value of Oracle's 22% maintenance fee is even lower than the headline suggests — and the third-party value proposition is correspondingly stronger.

This is also where our proprietary engagement data is most striking. Across 600+ Oracle advisory engagements, Oracle Licensing Experts finds that roughly 40% of total Oracle support spend in a typical enterprise sits on products that score as strong third-party support candidates — overwhelmingly mature, customised application estates (Oracle Licensing Experts benchmark, 2026). In one 2026 insurance-sector eligibility review, scoring the estate product by product surfaced $3.4M in addressable annual support spend that the client had assumed was untouchable, anchored by a heavily customised EBS instance.

What Is the Support Reinstatement-Fee Risk If You Return to Oracle?

Eligibility is not only about today — it is about the realistic five-year path. The most expensive mistake in third-party support is moving a product, then being forced back onto Oracle support a few years later to take an upgrade or qualify for a cloud deal. Oracle's reinstatement policy is designed to punish exactly that sequence.

When you reinstate Oracle support after a lapse, Oracle generally requires payment of back-support — the fees you would have paid during the lapsed period — plus a reinstatement penalty. The combined cost can reach roughly 150% of the fees that went unpaid while you were on third-party support. The longer you were away and the larger the estate, the more punitive the bill. This is the single factor most often left out of a vendor's third-party support pitch, and it is the one that most often changes the answer.

The practical rule: if there is a realistic probability of needing Oracle support back within 3–5 years — for example, an EBS-to-Fusion Cloud migration that is likely but not yet committed — the expected reinstatement cost should be weighted against the annual third-party saving to find the true net benefit. We model this explicitly, and we cover the mechanics in depth in our dedicated Oracle support reinstatement fees analysis. Where reinstatement is a live risk, our insurance third-party support case study shows how we structure the decision to preserve a return path without forfeiting the savings.

Frequently Asked Questions