TPS Risks Are Real — and Manageable

Oracle third-party support is legal, commercially proven, and delivers genuine savings for organisations that approach the transition with appropriate preparation. The risks associated with TPS are real, but they are not prohibitive — they are manageable through structured pre-transition work. The organisations that experience the worst outcomes from TPS transitions are those that switch without completing a compliance review, without resolving ULA or PULA certification issues, or without understanding Oracle's reinstatement penalty structure. Each of these preparation failures is avoidable.

This article maps the five principal risk categories — compliance, audit, security, reinstatement, and provider dependency — and provides specific mitigation steps for each. Reading it before initiating a TPS evaluation is the first mitigation step.

"The organisations that regret TPS decisions are not those who switched — they're those who switched without completing the compliance review first. Oracle's audit team targets the low-hanging fruit."

Risk 1: Oracle Licence Compliance Exposure

Oracle licence agreements give Oracle the right to audit software usage regardless of support status. Ending Oracle support does not end Oracle's audit rights — it applies for as long as you use Oracle software. The compliance risk is that unresolved licence gaps that existed before the TPS transition become audit targets after the transition.

Oracle's audit team monitors for support cancellations and treats them as commercial signals. Organisations that cancel Oracle support are more likely to receive an Oracle Licence Management Services (LMS) audit notification within 12 to 24 months of cancellation. If your Oracle estate has unresolved compliance issues — under-licensed processor counts in virtualised environments, Named User Plus minimum calculation shortfalls, unlicensed options or packs deployed in Oracle Database — Oracle will find them in an audit.

Mitigation

Complete a thorough internal licence compliance review before cancelling Oracle support. The review must cover processor licensing for all virtualised Oracle Database environments (VMware, KVM, Hyper-V, Oracle VM), Named User Plus and Processor minimum calculations for all Oracle Database instances, Technology Options and Packs deployed in Oracle Database (Advanced Security, Partitioning, Diagnostics Pack, Tuning Pack, Real Application Clusters), application user counts against purchased Named User Plus entitlements for Oracle EBS, JD Edwards, and other Oracle applications, and any Oracle software deployed beyond its licensed scope.

Where compliance gaps are identified, resolve them before cancelling Oracle support. Resolving gaps while still on Oracle support is significantly less costly than resolving them after Oracle initiates an audit. A clean compliance position at the time of TPS transition removes Oracle's most effective weapon against customers who have exited support.

Evaluating TPS and need a compliance review first?

Our Oracle compliance team identifies and resolves licence gaps before your TPS transition.
Request a Compliance Review →

Risk 2: Oracle Audit Retaliation

Even with a clean compliance position, Oracle may initiate a licence audit after TPS transition as a commercial retention or retaliation tactic. Oracle's standard Customer Support Identifier agreement includes broad audit rights, and Oracle exercises them selectively based on commercial dynamics. A customer cancelling 500,000 USD in annual support is a high-priority audit target.

The audit itself — even one that results in a clean finding — consumes internal resources. Oracle LMS audits require IT, legal, and procurement bandwidth to manage, typically over a period of three to six months. For organisations that have not previously been through an Oracle audit, the process is disruptive and sometimes intimidating by design.

Mitigation

Maintain current, accurate licence records at all times. This means keeping inventory of all Oracle software deployments updated, retaining purchase documentation for all Oracle licences, and documenting the licence compliance methodology for each Oracle product. An organisation with well-documented licence records is significantly better positioned to respond to an Oracle audit efficiently and to challenge findings that do not align with the documented licence position. Engage an independent Oracle licence advisory firm — not Oracle LMS — to manage any audit that Oracle initiates post-TPS. Oracle LMS audits conducted without independent advisory support produce findings that are systematically less favourable to the customer.

Risk 3: Security Coverage Gap

Oracle issues quarterly Critical Patch Updates (CPUs) covering known security vulnerabilities across its product portfolio. Under Oracle Premier Support, customers receive access to these patches through My Oracle Support. Under TPS, Oracle-issued patches are no longer available — the TPS provider delivers alternative security coverage through virtual patching, configuration hardening, and custom-developed fixes.

The security coverage gap risk is the most technically complex TPS risk to evaluate. Virtual patching and compensating controls can address many CVEs effectively — but the effectiveness depends on the specific vulnerability, the deployment environment, and the TPS provider's security team capability. Not all CVEs can be fully mitigated without the Oracle-issued patch, particularly for vulnerabilities in Oracle Database core functionality.

Mitigation

Before transitioning Oracle Database to TPS, review the CVEs in the most recent two to four Oracle quarterly CPU updates. Assess which CVEs are relevant to your Oracle versions and deployment environment and ask your TPS provider to confirm how each relevant CVE is addressed in their security coverage model. Engage your information security team in this assessment — the TPS security coverage question is a technical security evaluation, not just a licensing evaluation, and the decision should involve your security team's risk assessment alongside the financial case.

For Oracle applications (EBS, JD Edwards, PeopleSoft), the security risk from CPU patches is generally lower than for Oracle Database, because application-layer vulnerabilities typically require authenticated access and the TPS provider's custom fix capability is well-suited to the application security advisory cadence. The Oracle Database security risk evaluation is the more critical one.

Risk 4: Reinstatement Penalty

Oracle's reinstatement fee policy creates a financial trap for organisations that switch to TPS and later need to return to Oracle support — whether due to a failed TPS provider, a new Oracle product purchase requiring active support status, or a regulatory requirement for vendor-supported software. Oracle charges backdated support fees for the entire period off support, plus a 50% surcharge on that accumulated amount.

The calculation is severe. An organisation that cancels 400,000 USD in Oracle annual support, is off support for three years with Oracle's 8% annual uplift compounding, and then needs to reinstate would face approximately: Year 1 fee of 400,000 USD, Year 2 fee of 432,000 USD, Year 3 fee of 466,560 USD — total 1,298,560 USD in backdated fees, plus the 50% surcharge of 649,280 USD — a reinstatement cost of approximately 1,947,840 USD. Compared to the three years of TPS savings at 200,000 USD per year (1,400 USD saved), the economics are catastrophically negative if reinstatement occurs.

Mitigation

The reinstatement risk is eliminated in two scenarios: the organisation never needs to return to Oracle support (the expected scenario for stable run-and-maintain environments), or the organisation intends to decommission the Oracle software before any reinstatement would be required (the exit scenario). Model the reinstatement scenario formally as part of your TPS business case. Ask: Under what circumstances would we need to reinstate Oracle support? How likely is each scenario? What is the financial impact if that scenario occurs? Only proceed with TPS if the reinstatement scenario is either unlikely, financially manageable, or eliminated by the planned decommission of the Oracle software within the TPS contract period.

Risk 5: Provider Dependency and Continuity

TPS introduces a dependency on a commercial third-party organisation. If your TPS provider experiences financial difficulty, is acquired by a company that changes its support model, or faces legal challenges that disrupt its operations, your Oracle support continuity is at risk. This provider dependency risk is distinct from Oracle's own continuity risk — but it is real for smaller TPS providers and was a concern for Rimini Street during its peak litigation period.

In practice, the three major TPS providers (Rimini Street, Spinnaker Support, and Support Revolution) are all established businesses with multi-year track records. Rimini Street's 2025 settlement with Oracle has resolved the principal legal uncertainty around its business continuity. However, the provider dependency risk should be evaluated as part of provider selection — particularly the financial stability of the provider and the contractual protections available if the provider is unable to fulfil its support obligations.

Mitigation

Evaluate TPS provider financial stability as part of the selection process. For publicly traded providers (Rimini Street is publicly listed), review annual financial filings. For privately held providers, request financial references and assess the organisation's scale relative to your Oracle environment's support complexity. Review the TPS contract for provisions covering service failure, provider exit, and customer rights if the provider cannot deliver contracted services. Ensure that the contract includes provisions for knowledge transfer and data portability if the provider relationship ends prematurely.

Additionally, consider a hybrid support approach for very high-criticality Oracle systems: retain Oracle Premier Support for mission-critical Database or application instances where provider dependency risk is unacceptable, and deploy TPS for stable, lower-criticality systems where the savings are material and the dependency risk is manageable.

The Risk Summary: Pre-Transition Checklist

Before proceeding with any Oracle TPS transition, complete the following risk mitigation steps. Each step corresponds to one of the five risk categories above.

  • Compliance review completed: All Oracle products in TPS scope have been reviewed for licence compliance. All gaps resolved or formally accepted with documented risk assessment.
  • Audit readiness established: Licence records are current, documented, and accessible. Audit response process established, with independent advisory firm identified.
  • Security gap assessed: CPU CVE relevance reviewed for Oracle Database versions in scope. TPS provider's security coverage methodology assessed against relevant CVEs. Information security team has approved the TPS security risk posture.
  • Reinstatement scenario modelled: Five-year reinstatement cost calculated. Reinstatement trigger scenarios assessed and either mitigated or accepted as unlikely. Decommission timeline confirmed for exit scenarios.
  • Provider due diligence completed: TPS provider financial stability evaluated. Contract reviewed for service failure and provider exit provisions. Hybrid support approach evaluated for high-criticality systems.

For organisations that have completed these steps, the TPS risk profile is manageable and the 50% savings against Oracle's compounding 8% annual support uplift create a compelling financial case. For organisations that have not completed these steps, the risks can negate the savings. Use the Oracle TPS Decision Framework to structure the full evaluation before committing to a transition. The Redress Compliance Oracle team supports clients through compliance reviews, TPS evaluation, provider selection, and transition management.