Transitioning to Oracle Third-Party Support: A CIO’s Guide
Third-party support for Oracle software refers to maintenance and support services provided by independent vendors instead of Oracle itself. In recent years, this option has seen growing adoption among enterprises. Research by Gartner indicates that third-party support deals accounted for 45% of all enterprise software support contracts in 2021 – a jump from 27% the year prior.
This surge is driven by organizations seeking relief from high vendor maintenance fees and looking for more flexible support solutions, especially amid economic pressures (pandemic impacts, inflation, recession fears) that demand IT cost optimization.
Today, nearly 4,000 customers have embraced third-party support for Oracle and SAP products, signaling that it has evolved into a viable alternative to vendor support.
Why are CIOs considering third-party support for Oracle? The motivations typically include:
- Cost Savings: Oracle’s annual support fees are often ~22% of license costs with yearly uplifts. Third-party providers charge about 50% less for equivalent support, immediately cutting maintenance spend. Gartner notes this can offset the yearly price increases Oracle imposes, and help meet budget reduction goals.
- Extended Product Life: Organizations running legacy Oracle versions face end-of-support deadlines. Third-party support extends the lifespan of stable, mission-critical systems beyond Oracle’s support window. For example, when Oracle Database 12.1 fell out of Oracle’s support, many users turned to third-party support to avoid an urgent upgrade.
- Flexibility and Control: Independent support frees companies from Oracle’s upgrade cycle and vendor lock-in. CIOs can upgrade on their timeline (or not at all) since the third party will support older versions indefinitely. This avoids forced migrations driven by expiring support contracts and gives more negotiating leverage with software vendors.
- Better Service Quality: Many third-party providers tout a more personalized, responsive support model. Instead of navigating Oracle’s tiered ticket system, customers get direct access to senior engineers and dedicated support teams. This “direct-to-engineer” approach often leads to faster issue resolution and higher satisfaction.
- Support for Customizations: Oracle’s support policy typically doesn’t include custom code or tailored solutions, whereas third-party vendors will help troubleshoot and fix issues in customized Oracle environments. This is a big win for organizations that have heavily tailored their Oracle software.
In summary, CIOs turn to third-party Oracle support to reduce costs, extend the life of legacy systems, and improve the support experience.
The next sections of this article explore what third-party support entails, how it addresses security and compliance concerns, and best practices for a smooth transition. Industry examples and expert insights are provided throughout to inform a CIO’s decision-making.
What is Third-Party Support?
Third-party support is a service where an independent company (not Oracle) provides software support and maintenance for Oracle products. Instead of renewing support with Oracle, a customer can contract a certified third-party provider (such as Rimini Street, Spinnaker Support, or others) to receive help desk support, bug fixes, patches, and updates for regulatory compliance.
These third-party firms have teams of Oracle experts who take over the support role at a lower cost. Importantly, they operate without Oracle’s direct involvement, so they cannot access Oracle’s proprietary source code or official patch releases.
This difference underpins both the advantages and trade-offs of third-party support.
How does third-party support differ from Oracle’s support? The core services are similar – customers can report issues, troubleshoot, and receive bug patches or workarounds. However, there are key differences:
- Independent and Cost-Effective: Third-party providers are completely independent of Oracle and typically charge significantly less. Unlike Oracle’s one-size-fits-all support fees, They can often tailor pricing to the client’s needs. Many companies see 50–70% savings by switching to third-party support. For example, a mid-sized firm that moved from Oracle to a third party cut its support costs by 60%, freeing the budget for new analytics initiatives. Another company saved over $500,000 annually by switching, which was reinvested into IT upgrades. These savings are a primary driver for considering third-party support.
- Personalized Service: Oracle’s support is standardized and often criticized for slow, bureaucratic responses. In contrast, third-party vendors tend to offer dedicated support engineers and customized SLAs. Clients can get 24/7 support with direct access to experienced Oracle technicians rather than junior staff triaging tickets
- . Providers often assign a dedicated account manager to each customer, ensuring familiarity with the client’s environment and faster resolution times. This tailored approach means higher quality service and support aligned with the business’s priorities (e.g., guaranteeing response times for critical systems).
- Extended Support for Older Versions: Oracle has defined life cycles for each product (Premier Support, then Extended Support for a limited time, then Sustaining Support with no new fixes). Third-party support breaks this model by **continuing full support for legacy versions indefinitely. If your organization runs a stable old release of Oracle E-Business Suite or Oracle Database that Oracle no longer patches, a third-party provider will still support it with bug fixes and even security updates (via custom solutions). This allows you to avoid forced upgrades and maximize the ROI of existing systems. For example, companies that want to “run their stable Oracle 11i system for another 5 years” use third-party support without risking support gaps.
- Custom Code and Tailored Solutions: Third-party providers will address issues arising from customizations or integrations, which Oracle’s support typically declines to troubleshoot. They can develop custom bug fixes and workarounds when Oracle’s standard code doesn’t meet your needs. For instance, if a custom report or extension in your Oracle ERP is causing errors, a third-party support engineer will help identify the root cause and may craft a script or patch to fix it. Oracle’s support would likely tell the customer to revert the customization, offering no help. Thus, independent support is more flexible in supporting unique environments.
- No Access to Oracle’s New Updates: A crucial difference is that third-party support vendors cannot deliver Oracle’s proprietary patches or new features. Once off Oracle support, you lose the right to download official updates and fixes. Third-party providers compensate by delivering their fixes for known issues and implementing security measures (discussed next). Still, they do not provide version upgrades or the exact Oracle-released patches. Customers must accept that they won’t get the latest Oracle features or vendor-issued patches directly. In practice, many organizations that use third-party support run mature systems where new features aren’t needed, and stability is the priority.
Benefits Summary: Third-party support offers significant cost reduction, extended software life, and often improved support service quality at the cost of forgoing Oracle’s official patch stream. It’s an appealing trade-off for organizations with stable Oracle environments focused on cost efficiency and flexibility.
As one industry publication noted, switching to a third-party vendor brings “immediate cost savings, enhanced service quality, and the ability to avoid vendor lock-in” across a wide range of Oracle products.
The next section will address a common concern when leaving Oracle’s umbrella: security and compliance without Oracle’s updates.
How Third-Party Vendors Address Security & Compliance
CIOs’ biggest question is: “Without Oracle’s security patches, how do we keep our systems secure and compliant?” Indeed, moving to third-party support means Oracle is no longer receiving its official security patch updates (e.g., the quarterly Critical Patch Updates).
However, third-party support vendors have developed alternative strategies to protect customers’ systems. They employ a multi-layered approach to security that goes beyond just applying patches.
Security Patching Strategies: Top third-party providers mitigate vulnerabilities through techniques like virtual patching, custom fixes, and compensating controls. Instead of applying Oracle’s code patches (which they cannot access), they analyze the vulnerability and create their solution to block or fix the issue.
For example, a vulnerability in the Oracle Database might be addressed by a tailored code fix or a configuration change that closes the security gap without altering the Oracle source code.
This concept is often called virtual patching: putting protective measures in place (at the database, application, or network layer) to prevent exploitation of a known flaw. It might involve adding a trigger or constraint in the database, adjusting firewall rules, or deploying an intrusion detection rule that guards against the vulnerability’s signature.
According to an ERP Today guide, third-party support security relies on “full-stack intrusion detection, virtual patching, and compensating controls,” acknowledging that security is multi-layered and not addressed by software vendor patches alone.
In essence, these providers harden the environment and monitor it closely to guard against attacks, achieving a level of protection comparable to Oracle patches in many cases.
Proactive Monitoring and Response: Third-party support vendors often offer continuous security monitoring as part of their service. They will monitor the client’s Oracle systems for unusual activity or known attack patterns.
If a potential breach or anomaly is detected, their team can respond immediately – for instance, by isolating affected components or applying a quick configuration change to block an exploit. This proactive stance helps catch threats that might require waiting for the next Oracle patch cycle. Combined with the vendor’s regular vulnerability assessments and penetration testing, it creates a holistic security posture for the Oracle environment.
Many providers also issue security advisories to their clients, alerting them to new threats and recommending steps to mitigate risks (much like Oracle’s Critical Patch bulletins, but with vendor-neutral solutions).
Regulatory Compliance: Companies in regulated sectors (finance, healthcare, government) often have requirements to apply vendor patches or demonstrate that systems are secure. Third-party support can still meet compliance mandates but requires careful documentation and controls. Providers assist by implementing compensating controls when actual patches are not available.
For example, suppose a payment card industry (PCI) rule requires addressing a specific database CVE. In that case, the third-party support firm will document how their virtual patch or firewall rule mitigates that CVE to satisfy audit requirements.
They ensure an alternative safeguard for every Oracle patch you miss. Compliance is achievable, but organizations must be diligent.
If not managed, failure to apply vendor patches could raise compliance issues. For example, auditors will want evidence that known vulnerabilities were otherwise mitigated.
Leading third-party vendors are familiar with these obligations and help clients maintain necessary records and evidence.
Additionally, third-party providers continue to deliver tax, legal, and regulatory updates for Oracle applications (such as payroll tax tables, financial reporting changes, etc.) as part of their service offering to keep Oracle ERP systems compliant with changing laws.
For instance, if a new VAT rate or HR law comes out, a third-party support vendor will supply the needed updates or scripts for Oracle E-Business Suite customers, just as Oracle would during active support.
Security Track Record: It’s worth noting that, to date, there have been no widespread security incidents attributed to companies using third-party support. Thousands of organizations, including banks and government agencies, have successfully operated Oracle systems without Oracle’s direct patches by relying on third-party security measures.
Nonetheless, a prudent CIO will thoroughly vet a potential provider’s security capabilities and certifications. Ensure the vendor follows industry best practices (ISO 27001, SOC audits, etc.) and ask how they handle zero-day vulnerabilities.
A strong third-party support partner should be able to articulate a clear plan for emergency fixes (some have “zero-day” protection programs that deploy virtual patches immediately when new threats emerge).
In summary, while moving away from Oracle’s patch program is a significant consideration, third-party support vendors mitigate risk through custom fixes, vigilant monitoring, and layered defenses. They strive to keep environments secure and compliant with standards.
CIOs should still evaluate this area carefully, evaluating the provider’s security track record and possibly getting an independent security assessment. Enterprises can maintain a robust security posture under third-party supportwith the right precautions.
How to Transition to Third-Party Support
Switching from Oracle’s support to a third-party provider is a strategic move that requires planning.
Below are the key steps and best practices for a smooth transition process, from evaluating your current contracts to managing the cutover.
We also discuss potential challenges you might face and how to mitigate them.
1. Evaluate Current Oracle Support Contracts and Usage
Begin by reviewing all your existing Oracle support agreements and installed products. Key actions in this phase include:
- Assess Contract Renewal Dates: Determine when each Oracle support contract expires. Many Oracle support renewals align with Oracle’s fiscal year end (May 31). You’ll want to time your transition to coincide with contract end dates to avoid paying for overlapping support. If multiple contracts end at different times, note that this is manageable – you may transition some products later or negotiate co-termination. Don’t assume staggered dates are a blocker; it just requires coordination.
- Understand the “Matching Service Levels” Policy: Oracle contracts have a clause that prevents dropping support on only part of a license set. Under Oracle’s matching service level policy, you generally cannot support some licenses on Oracle and some on a third party for the same product set – it’s all or nothing for each “license set.” For example, suppose you have 100 Oracle Database licenses under one license set. In that case, Oracle may contractually require that either all 100 remain on Oracle support or you terminate those licenses you want to stop supporting. Violating this could breach your terms. This doesn’t mean you can’t move to third-party support; you will usually move the entire product’s support simultaneously (or negotiate with Oracle to carve out exceptions). Be aware of this when evaluating which products to switch. In practice, many companies simply transition the full environment of a given Oracle product to the third-party provider to avoid Oracle’s contractual traps.
- Inventory Your Oracle Footprint: Conduct a thorough IT audit of all Oracle products, versions, and customizations. Identify which of those are in scope for third-party support. Some might be better kept on Oracle support (for instance, if you plan to upgrade it in the next few months or if it’s a SaaS/cloud service where third-party support doesn’t apply). Document any known issues or pending patches you were expecting from Oracle. Discussing these with potential providers will be important to ensure they can address them.
- Evaluate Internal Support Capabilities: Determine how reliant your team is on the Oracle Metalink/MyOracleSupport knowledge base and whether you have the in-house expertise to manage without that. Once you leave Oracle support, you lose access to Oracle’s support portal and knowledge articles. Third-party vendors supply their knowledge and will handle issue resolution, but it’s wise to download any critical documentation or patches from Oracle before your support lapses. Some companies perform an archiving of Oracle patches and docs they are entitled to while still under Oracle support for future reference. Ensure this is done in line with your license rights (generally, you can keep using any patches released before your support ends).
2. Select a Third-Party Support Vendor
Choosing the right vendor is critical – not all third-party support providers have equal expertise or services. Key selection criteria to consider:
- Oracle Product Expertise: Ensure the provider has a proven track record supporting the specific Oracle products you use (Database, E-Business Suite, JD Edwards, WebLogic, etc.). Look for providers with deep Oracle knowledge and experienced staff, including former Oracle engineers or developers. Two leading vendors, Rimini Street, and Spinnaker Support, have 10+ years of Oracle support experience and teams well-versed in Oracle’s technology. Ask for case studies or references in your industry – e.g., if you run Oracle Retail, has the vendor supported other retail companies on that suite?
- Services Offered: Evaluate the vendor’s breadth of services under their support contract. At a minimum, they should cover break/fix support, troubleshooting, and tax/regulatory updates. Top vendors also include performance tuning, security monitoring, and advisory services as part of the package. Check if they will support customizations (most do) and their process for delivering fixes (do they develop custom patches, provide documentation, etc.). If you have global operations, ensure they offer 24/7 support and can handle multi-country regulatory requirements (for example, local payroll updates in various countries).
- Service Level Agreements (SLAs): Discuss SLA terms in detail. Third-party support can often offer more flexible and favorable SLAs than Oracle. For instance, you might negotiate a 30-minute response for Severity-1 issues or a dedicated engineer contact. Make sure the SLA covers your business needs (response times, resolution targets, etc.) and get clarity on what constitutes a critical issue. Also, clarify any deliverables (e.g., will they provide a root-cause analysis report for major incidents?). A well-defined SLA is crucial for accountability.
- Security and Compliance Measures: As noted earlier, security is a big part of support. In vendor selection, verify the provider’s security protocols and compliance standards. Do they have security certifications? What is their track record in your industry (especially if you’re in a regulated industry)? Ensure they have processes for handling sensitive data and comply with regulations like GDPR or HIPAA if applicable. A vendor should readily answer questions about keeping clients secure and provide references who can attest to their security posture.
- Contract Terms and Flexibility: Compare contract structures. Third-party providers often work on annual contracts, but some may do multi-year discounts or other terms. One benefit is you can negotiate out of Oracle’s yearly 3-4% fee increase – many third-party contracts have fixed pricing or more predictable costs over multiple years. Check if the contract allows you to scale support up or down (for instance, if you decommission some servers, can you reduce fees?). Also, legal counsel should be engaged to review the terms for any unusual clauses. Generally, ensure no restriction would lock you in beyond what you intend (ironically, you don’t want to escape Oracle lock-in only to be locked into a new vendor without flexibility).
- Reputation and Financial Stability: Pick a well-established, stable vendor since third-party support may be a long-term strategy. Rimini Street and Spinnaker Support are the two largest globally (with thousands of clients). There are smaller players like Support Revolution and niche firms but evaluate their viability. Also, consider the vendor’s customer retention and satisfaction rates – it’s a good sign if many customers renew their contracts annually.
- Proof of Concept: If feasible, consider a trial or phased engagement. Some companies start third-party support for a non-production environment or a subset of systems as a test, or they keep Oracle support for one minor product and compare the experience. While not always possible, a phased approach can reduce risk. At a minimum, having detailed discussions and perhaps workshops with the prospective vendor’s support team (before signing) can give insight into how they’ll handle your environment.
3. Plan the Migration Process
Create a migration plan once you’ve chosen a provider and decided which Oracle products will transition.
Key best practices during planning:
- Overlap Avoidance: Plan the cutover to avoid any gaps in support. Typically, you would end Oracle support and start third-party support the next day. You cannot have both simultaneously for the same licenses (Oracle doesn’t allow dual support), but you want zero downtime in coverage. Coordinate with the vendor to be on standby when Oracle support expires.
- Knowledge Transfer: You must share much information about your systems with the new provider. This often starts during onboarding. Prepare documentation on your architectures, customizations, interfaces, and recent support history (open issues, past Oracle SRs, etc.). Many providers send a detailed questionnaire or hold workshops to gather this knowledge. Be candid about any chronic problems or patches you’ve deferred – this helps them be ready with solutions. Consider giving the vendor read-only access to your systems or a clone environment in advance so they can familiarize themselves and even simulate issues.
- License Review and Archiving: Before the switch date, perform a final licensing review to ensure compliance (more on license considerations in the next section). Also, download any Oracle patches, updates, or documentation you are entitled to up to the end of your support period. For example, if Oracle issued a critical patch in the last quarter of your support, grab it and archive it. Third-party support will usually apply it or have their fix, but you want it for reference. Oracle’s support policies permit using any patches released during your active support term, even after support ends (since you have a perpetual license). Avoid downloading anything after you leave support, as that would violate licensing.
- Communication Plan: Inform your stakeholders and user base about the support change. Internally, your helpdesk and IT staff should know the new support contacts and procedures. You might keep Oracle’s support contact info for certain issues (like cloud services or products you didn’t switch), so clarity on who to call is important. Also, brief management on the plan so they are confident continuity will be maintained.
- Set Clear Expectations with the Vendor: Ensure the third-party provider understands your critical systems and priorities before going live. For example, identify your top 5 most critical Oracle workloads to them, and perhaps arrange for those to have extra attention. Confirm escalation paths: How do they respond if a P1 issue occurs at 2 AM? Having these details ironed out (and documented in the SLA) avoids surprises. Clear mutual expectations are key to a successful partnership.
4. Execute the Transition & Monitor
On the transition day, formally notify Oracle that you will not renew support (if you haven’t already) and begin the contract with your third-party provider. Typically, this is just an administrative step when the date arrives. Immediately following the cutover:
- Smoke-Test Support Processes: Engage the new support process within the first week, even if no major issues arise. For instance, log a low-priority ticket or ask a how-to question. This helps test responsiveness and lets your team familiarize themselves with the provider’s ticketing system. It’s better to shake out any procedural kinks early.
- Close Off Oracle Access: Ensure that nobody in your team tries to download patches or log new service requests with Oracle Support after the termination. Your Oracle MOS account may be restricted once support is gone. Attempting to access support services without entitlement could flag an audit. It’s best to communicate to all IT staff that Oracle support will no longer be used (some companies even change the MOS account password to prevent accidental use).
- Monitor Service Quality Closely: Treat the first 3-6 months as a probation period to carefully track how well the third-party support performs. Are they meeting SLAs? How is the turnaround on fixes? Gather feedback from your technical teams: are they satisfied with the expertise and solutions provided? This is the time to address any issues in the relationship. Schedule regular check-ins with the vendor’s account manager to review open cases and overall performance. Most providers will be eager to impress in the early period, so use that to establish a high support standard.
- Document Improvements and Savings: As the new support model stabilizes, document the benefits you’re observing – e.g., “We saved $X in support fees this quarter,” or “Issue Y that lingered under Oracle was resolved quickly by the new provider,” or “Our ERP stayed on the old version through year-end without incident, avoiding a costly upgrade.” These will be useful to demonstrate the value of the decision to stakeholders (and are handy if you ever need to justify continuing on third-party support in future budget cycles).
Potential Challenges and Mitigation Strategies:
Transitioning to third-party support isn’t without hurdles. CIOs should be aware of common challenges and how to address them:
- Resistance from Oracle: Be prepared for Oracle to push back when they learn you’re leaving their support. Oracle sales reps may try tactics such as warning about dire consequences or offering discounts to keep you. They may cite contract clauses (like matching service levels) or claim that third-party support is illegal (which is not true – Oracle’s license allows it as long as you remain compliant). Mitigation: Rely on what your contracts say, not verbal claims. Work with independent licensing experts if needed. Many companies have navigated this successfully – do not let fear, uncertainty, and doubt (FUD) derail a well-researched plan. Also, if Oracle offers a last-minute discount, evaluate it fairly, but remember that even a 10-15% discount likely won’t match the savings of third-party support (50%+).
- Loss of Oracle Patch Updates: As discussed, leaving Oracle means no new patches. This is often cited as the top concern. Mitigation: Ensure your third-party provider has a strong security program and custom patch capability. Prioritize any outstanding patches before you leave (apply them if possible while you can). Post-transition, if Oracle announces a new critical vulnerability, demand a timely response from your provider – they should either issue a fix or a shielding recommendation quickly. Having an internal security team or advisor double-checking the provider’s guidance for major vulnerabilities is wise. So long as you follow a robust process, the risk can be managed comparably to staying on Oracle support.
- Complex Future Upgrades: Over time, if you eventually decide to upgrade Oracle or move to a new platform, doing so without Oracle’s direct involvement could be complex. For example, if you stayed on E-Business Suite 12.1 for 5 years with third-party support and then choose to implement Oracle Cloud or upgrade to a later release, you may need to re-subscribe to Oracle support or self-upgrade. Oracle might charge back-support fees to allow an upgrade license. Mitigation: Plan your long-term IT roadmap. Some organizations use third-party support as a bridge strategy while they prepare to move to SaaS or another system. In that case, ensure the third-party vendor supports you in data extraction, integration, etc. If you think you might return to Oracle’s fold, be aware of reinstatement fees – Oracle may require paying all the support fees you missed plus a penalty to reinstate support. Many companies never go back, but if possible, factor that into cost calculations or negotiate upfront with Oracle for a smoother re-entry (though Oracle is often inflexible on this point).
- Oracle License Audits: There is a concern that leaving Oracle’s support could trigger a license audit by Oracle. In the past, Oracle audited customers to ensure they weren’t using more licenses than they had purchased or using support-only benefits without paying. The risk of an audit exists, but according to licensing experts, it is not significantly higher just because you switched to third-party support. Oracle audits occur for many reasons. Still, it’s wise to be prepared. Mitigation: Before transition, do a self-audit or independent audit of your Oracle deployments. Ensure you fully comply with license terms (no usage beyond entitlements). That way, even if Oracle audits, you have confidence in your compliance. Also, keep detailed records of your licenses, proofs of purchase, and deployment architecture – organizing can make any audit quicker and less painful. In short, proactively tighten license compliance to deprive Oracle of any leverage during or after the switch.
- Internal Cultural Change: Internal IT staff or executives are sometimes nervous about leaving the known quantity of Oracle Support. It can be a mindset shift (“We’ve always just renewed Oracle support; this is new territory.”). Mitigation: Educate stakeholders on the success stories of third-party support. Share case studies of similar companies that have made the switch and thrived (some examples are provided in the next sections). Run workshops with the chosen vendor before going live so your team can see their expertise first-hand. Over time, as the new support model proves itself, this concern will ease.
By anticipating and addressing these challenges with solid strategies, you greatly increase the likelihood of a smooth transition. Many companies have navigated this journey – planning and open communication are your allies.
Now that we’ve covered the transition process let’s drill down on a critical aspect that was touched on: Oracle licensing and compliance considerations when moving to third-party support.
License Compliance Considerations
Switching support providers does not change your underlying Oracle license agreements – you still must adhere to the terms of your Oracle license contract even when Oracle is not providing support. Thus, CIOs must pay special attention to license compliance during and after a move to third-party support to avoid legal pitfalls or unexpected costs.
Here are the key considerations:
Understand Your Oracle Licensing Terms: First and foremost, review what your Oracle license grants you. Most Oracle licenses (perpetual licenses) permit you to use the software indefinitely, regardless of support status. No clause forbids using a third party for support – Oracle cannot force you to buy support from them. Oracle’s standard agreements allow third-party support if you comply with the license metrics and usage rules.
This was confirmed in court rulings and Oracle’s statements. So, having a third party support your licensed Oracle softwareis legal.
However, you must ensure you’re not violating other terms: for instance, downloading Oracle’s patches after your support contract ends would violate the Oracle support agreement.
So, while using third-party support is legal, continuing to use Oracle’s support intellectual property without entitlement is not. The practical upshot is that once support is off, do not download new patches or updates from Oracle’s systems. Limit yourself to patches obtained while you were a customer or those provided by your new vendor.
“Matching Service Levels” and Partial Support Drops: As mentioned earlier, Oracle’s policies require that if you drop support on any licenses in a product family (license set), you must drop support on all licenses in that set.
Oracle does this to prevent customers from paying support on only a subset of licenses while benefiting from updates on all. In compliance terms, if you choose third-party support for a certain Oracle product, you’ll likely need to terminate Oracle support entirely for that product across your environment (or terminate the unused licenses). You cannot, for example, keep 10 Oracle Database licenses on Oracle support and 90 on third-party support if they’re under one agreement – Oracle would consider that non-compliant.
The solution is usually straightforward: move all 100 to third-party support, and Oracle’s rule is no longer relevant. But be careful during the transition; coordinate the timing so you don’t accidentally violate the matching service level rule. Consult your Oracle contract or a licensing expert to identify your “license sets” and ensure you properly terminate support for the whole set if needed.
Companies sometimes negotiate with Oracle to drop a subset by terminating the licenses they don’t want to support (reducing their license count). This can be done if you don’t need those extra licenses – you formally terminate (give up) some licenses to reduce support costs, then move the rest to a third. Just be very sure you won’t need those licenses later if you take that route.
Oracle Unlimited License Agreements (ULA): If your organization is under an Oracle ULA (an unlimited use agreement for a period), special care is needed. ULAs typically require certification at the end of the term to convert to perpetual licenses. You should not move to third-party support while a ULA is active; doing so could be a breach. The best practice is to certify your ULA with Oracle first (i.e., go through the process of fixing the number of licenses you have and exiting the ULA) before transitioning.
After certification, you’ll have specific quantities of licenses, like normal perpetual licenses, which you can support via a third party. Review the ULA contract or consult a licensing advisor to plan this properly. Failing to certify an active ULA and leaving Oracle support could leave you in a non-compliant state.
Staying Compliant Post-Switch: Once on third-party support, Oracle will no longer assist with license questions or give any leeway—compliance is entirely your responsibility. Maintaining vigilance is crucial: ensure you do not exceed your licensed counts or use Oracle features/modules you haven’t licensed (Oracle’s software may allow usage beyond licenses, which Oracle would normally true up at renewal or during audits).
For example, if you have an Oracle Database license without the Diagnostics Pack, you must be careful not to turn that pack on because Oracle could audit you and charge you for it later. Under Oracle support, some customers rely on Oracle reps or support to highlight such issues; without that, you should self-monitor usage. Conduct periodic internal audits of Oracle usage to verify you remain within bounds.
Another compliance aspect is to retain documentation of your licenses and past communications. If Oracle audits you years after leaving, you want a clear paper trail of what licenses you own and that you were compliant at the point of departure. Keep proofs of purchase, Oracle’s confirmation of support termination, and any correspondence. Also, keep evidence of what patches or software versions you had up to the support end date in case Oracle ever questions if you applied something afterward. Essentially, maintain a defensible position with solid records.
Audit Preparedness: While it’s not a given that Oracle will audit you after you leave, it is a possibility. Some experts note that Oracle sometimes initiates an audit when a large customer ends support, but others observe it’s not extremely common.
In any case, prepare as if an audit could happen. As noted, do your license review before the switch. Consider engaging an independent Oracle license consultant to do a compliance check.
They can identify areas where you might be out of compliance (e.g., using options you didn’t pay for or miscalculating processor counts). Discovering and addressing those proactively is better than during an Oracle audit. If any issues are found, you can purchase the necessary licenses or adjust usage before leaving Oracle support to exit in a fully compliant state.
Many organizations have done this “true-up then exit” approach, essentially parting on clean terms.
If an audit does occur post-switch, handle it as you would any Oracle audit: involve your legal team, carefully manage communications, and only provide data specifically required by the license agreement. Having the third-party support provider doesn’t directly help in an audit (they typically won’t get involved in licensing matters), so it’s on your organization to defend its compliance. The good news is if you’ve done the homework and kept it within your entitlements; an audit should not result in a penalty – you would simply demonstrate compliance and close it.
Legal Precedents: The Oracle vs. Rimini Street legal case is worth mentioning in brief since it often comes up in this context. In the early 2010s, Oracle sued Rimini Street (the largest third-party support firm) over intellectual property misuse. The courts ruled that third-party support is legal, but Rimini Street had to adjust some of its processes (specifically, how it accessed Oracle software on behalf of clients).
Today, reputable third-party providers operate in ways that comply with those rulings – for example, they won’t use one customer’s credentials to download patches for another or copy Oracle code unauthorizedly. As a customer, ensure your provider pledges to follow all licensing rules.
The responsibility also lies with you: do not share Oracle software or support materials with the provider beyond what the license permits (typically, the provider will ask you to send them any Oracle patch files you already have rather than obtaining them themselves, which is fine).
This way, both you and the provider stay on the right side of Oracle’s intellectual property rights.
Best Practices for License Compliance in Third-Party Support:
- Thorough Pre-Switch Audit: “Review your Oracle licenses and compliance before switching.” This cannot be overstated. An independent audit before leaving Oracle support can save you from major headaches. Resolve any identified compliance gaps. Suppose you’re under-licensed for a certain usage. In that case, you might purchase additional licenses from Oracle before ending the support relationship (yes, paying Oracle one last time) to cover yourself. It’s better than being found non-compliant later with heavier penalties.
- Contractual Check: Examine your Oracle contract for any peculiar clauses. Some custom agreements might have a notice period for termination or other obligations. Also, ensure there’s no clause tying discounts to maintaining support (in rare cases, Oracle grants a license discount on the condition of buying support for X years – unlikely, but check). Engage legal counsel if needed to interpret your rights. Also, review the third-party provider’s contract to ensure it doesn’t put you at odds with Oracle’s (legit providers usually include a clause that they won’t ask you to do anything that violates your Oracle license).
- Certify ULA or Subscriptions: If you have Oracle subscription licenses or a ULA, handle those properly. Don’t leave a subscription in the middle of a term; it would mean you no longer have the right to use the software once it expires (unlike perpetual licenses). Usually, third-party support is for perpetual licenses. If you have Oracle Cloud or subscription-based products, you generally cannot get third-party support for those – you’d need to convert them to on-premise or just let them go. So, third-party support should be limited to perpetual on-prem licenses or perhaps Oracle applications hosted on your infrastructure.
- Maintain Documentation: Keep an organized archive of all relevant documents (licenses, support termination letters, proof of patch downloads up to date X, etc.). Also maintain internal documentation of any changes in your deployment that could affect licenses (for instance, if you deploy additional servers, ensure you have the licenses and note it).
- Ongoing Compliance Management: Oracle license compliance will be treated as an ongoing governance topic post-transition. You might institute a policy that any changes to Oracle environments (new installs, enabling features, etc.) are reviewed internally by a licensed specialist. Your team is fully responsible since Oracle is not there to remind or warn you. Some companies engage license management services periodically to double-check usage. A small yearly compliance check costs are trivial compared to potential audit penalties.
In conclusion, license compliance is manageable with due diligence. Thousands of organizations have successfully navigated this aspect when moving to third-party support.
By thoroughly reviewing licenses, adhering to contract rules like matching service levels, and staying within usage bounds, you can avoid legal risks and enjoy the benefits of third-party support without entanglements. One CIO said, “We treated the licensing review as part of the project – after that, we were confident and moved forward.”
List of Major Third-Party Support Vendors
The third-party enterprise software support market has a few key players specializing in Oracle support.
Below is an overview of the major vendors offering Oracle third-party support services, along with their distinguishing features:
- Rimini Street: The market leader and pioneer in third-party ERP support. Rimini Street is known for its global presence and comprehensive services portfolio supporting Oracle, SAP, and other enterprise systems. They take a proactive approach to support and have a large engineering team with deep Oracle expertise. Rimini Street serves 2,800+ clients worldwide and often touts high client satisfaction ratings. A notable aspect is that Rimini has been involved in high-profile legal disputes with Oracle over the years, which they have largely navigated but which some risk-averse customers monitor. Despite that, Rimini Street remains dominant due to its scale and track record. They often position themselves as a premium provider (and maybe a bit less flexible on pricing negotiations, aiming for roughly 50% of Oracle’s fee).
- Spinnaker Support: A leading competitor to Rimini, Spinnaker Support focuses on Oracle and SAP third-party support, emphasizing technical expertise. Their team includes many former Oracle developers and DBAs, which allows them to delve into complex issues effectively. Spinnaker is praised for flexibility in contracts and a high-touch service model. They are slightly smaller in client base than Rimini but growing. Spinnaker offers support across Oracle Database, E-Business Suite, JD Edwards, Siebel, and more and provides related managed services. They have not faced the same legal entanglements as Rimini, which some customers find reassuring. Many mid-sized companies choose Spinnaker for what is often described as a more personalized support experience and sometimes more attractive pricing terms.
- Support Revolution: A UK-based third-party support provider that has gained recognition, especially in Europe and the Middle East. Support Revolution largely differentiates on competitive pricing – they often come in with lower fees and are supported by a cost-effective delivery model (they utilize support engineers and contractors based in India to lower costs). While smaller than Rimini and Spinnaker, they have a solid client roster and cover Oracle and SAP products. Support Revolution’s reliance on third-party contractors allows scalability but could be a consideration for customers who prefer dedicated in-house teams. They are a viable choice for budget-conscious organizations, including many in the public sector or those with smaller Oracle footprints. Clients should ensure that the slightly leaner model still meets their needs for responsiveness, especially for critical systems. Overall, Support Revolution is known as a cost-effective option in the third-party support market.
- Others: Besides the above three, there are a few other niche or regional players. For example, US Cloud (primarily known for Microsoft support) has started offering Oracle support in some capacity. Some system integrators and MSPs also claim to provide third-party support for Oracle as part of their services, though their focus may not be exclusively on Oracle. It’s worth noting that Gartner’s analysis of this market typically highlights Rimini Street and Spinnaker Support as the top two global providers, followed by players like Support Revolution and a handful of others. When evaluating options, ensure any vendor under consideration has a strong reputation, specifically in Oracle support.
In summary, most organizations will consider Rimini Street and Spinnaker Support the front-runners for third-party Oracle support, with Support Revolution as an alternative potentially lower in cost. They will then carefully vet any smaller firms that might suit specific needs.
Table 1 provides a quick comparison of the major vendors:
Table 1: Major Third-Party Oracle Support Providers – Strengths and Considerations
When engaging any third-party support vendor, perform due diligence – request customer case studies, talk to references, and perhaps start with a smaller scope before expanding. The good news is that the vendor landscape is well-established and competitive, which benefits customers.
CIOs should leverage this competition to negotiate the best deal and service terms (for example, some companies invite Rimini and Spinnaker to do assessments and quotes and play them against each other to get better pricing or terms).
Since independent support is a long-term partnership, choose a vendor you feel confident in for the life of your Oracle systems.
Cost Savings & Strategic Benefits
For most CIOs, the primary appeal of third-party support is the dramatic cost savings. Oracle’s maintenance fees are notoriously high – typically 22% of the annual license cost, which, over a decade, can exceed the original cost.
Third-party support promises to cut those fees roughly in half, yielding immediate budget relief. But beyond the raw savings, switching to third-party support can unlock several strategic benefits. This section examines the financial impact and the broader business advantages, including real-world examples and advice on building the business case.
Immediate Cost Relief: Organizations that switch to third-party support commonly report a 50% or more reduction in annual support expenses.
This is a significant reduction in IT operating costs. For example, a mid-size retail company found Oracle’s support too costly and moved to a third-party provider, saving about 40% of its yearly support spend.
Those freed funds were reinvested in upgrading its IT infrastructure – essentially turning maintenance dollars into innovation dollars. In another case, a large pharmaceutical company reduced support costs by 55% (saving $1.2 million per year) by transitioning its Oracle E-Business Suite and database support to Rimini Street.
These savings levels are typical; Gartner affirms that third-party support can “reduce [software] maintenance costs by 50%” while eliminating the annual price hikes vendors impose.
Over a multi-year period, the compounded savings (and avoidance of 3-5% yearly increases) can be even greater – some estimate that over 5 years, third-party support can cost 60–70% less cumulatively than staying on vendor support.
Return on Investment (ROI): The ROI from switching support providers is often realized in under a year because the cost reduction is immediate and there are minimal upfront costs. The main “investment” is the effort of transition.
Once switched, companies typically see an instant improvement in their IT budget. CIOs can redirect these savings toward strategic initiatives. For example, one company used the support savings to fund a new analytics project that had been budget-constrained. Another directed savings to critical R&D projects that drive competitive advantage.
In essence, third-party support can be a way to free up cash for innovation without asking for more budget – a powerful narrative for CIOs seeking to do more with less.
Case Studies: Beyond hypothetical savings, there are many published success stories:
- Global Energy Company (Oando PLC): Faced with oil price pressures, Oando’s CIO cut costs by replacing Oracle support with Spinnaker Support. Over five years, they saved over $4 million, which was reinvested in debt reduction and other strategic financial moves. The CIO also reported significantly faster response times and issue resolution under the third-party provider, improving IT service for less cost.
- Large Manufacturing Firm: Running an older Oracle JD Edwards system, this firm avoided a forced upgrade when Oracle’s support ended. By moving to third-party support, they extended the life of their stable system and saved millions in upgrade costs. The maintenance fees were cut in half, and the company could schedule an eventual migration to a new ERP on its timeline. In the interim, third-party support improves system performance via tuning and custom patches for long-standing bugs. This case illustrates saving support fees and deferring a capital project (upgrade) that wasn’t yet justifiable – a strategic win regarding capital allocation.
- Mid-Tier Bank: This financial services organization switched Oracle Database and middleware support to a third party to reduce OPEX. They achieved ~60% cost savings annually, directly contributing to meeting a corporate cost-to-income ratio target. More so, they leveraged the third-party’s support to maintain older versions of Oracle DB tightly integrated with legacy applications, buying time until those apps could be phased out. The CIO used Gartner’s endorsement of third-party support to assure the bank’s board that this was an industry-accepted practice, thus overcoming initial skepticism. The result was a smoother run for legacy systems and savings allocated to digital banking initiatives.
(Note: Specific company names are often confidential in case studies, but the scenarios above are drawn from reported outcomes.)
Extended System Life and Avoided Upgrade Costs: One often underestimated benefit is the ability to delay or avoid expensive upgrades. Oracle regularly ends support for older versions to push customers onto newer releases (and often new hardware or cloud services).
These upgrades can cost multiples of the annual project spend and disruption support. Third-party support lets you run a stable older version with full support for as long as it’s meeting your business needs.
The cost avoidance here can be huge: if you don’t need to spend $5M on an ERP upgrade for five more years, that’s $5M saved (or deferred). As Gartner noted, third-party support is an avenue to “extend the life of existing software investments when there’s no business reason to upgrade”.
This especially resonates with ERP systems or databases that work fine – why incur the cost and risk of change just because the vendor’s support timeline says so? Many CIOs use third-party support to align IT investments with business value, not vendor schedules.
When an upgrade eventually makes sense (e.g., to take advantage of genuinely beneficial new technology or because of a business process change), the organization can undertake it on its terms (potentially skipping intermediate versions since they weren’t forced to step through each Oracle upgrade).
Improved Focus and Service Quality: Paradoxically, some IT departments can focus more on strategic work by outsourcing support to a third party. With Oracle support, internal teams often had to justify issues (repeatedly proving to Oracle that a bug is real, collecting logs for weeks, etc., sometimes with Oracle ultimately not fixing it if it’s a known bug only resolved in a future upgrade).
Third-party support, on the other hand, tends to focus on quickly solving the issue at hand – whether via a workaround or a custom fix – rather than punting it to a future release. This means your internal staff spends less time as a go-between with the vendor and more time on productive tasks.
Some CIOs report that their teams became more efficient and happier because they weren’t fighting the support bureaucracy anymore. The third-party vendor augments your team with expert resources who take ownership of problems.
Faster problem resolution and fewer escalations can improve system uptime and performance, indirectly benefiting the business. Users notice when problems are resolved in hours instead of days. Thus, you get cheaper support and better support in many cases (as indicated by faster response and expertise).
Vendor Independence and Negotiation Leverage: Strategically, adopting third-party support can strengthen an organization’s position in dealing with software vendors. It signals to Oracle (and other vendors) that you are not afraid to step outside the box to optimize costs.
In some cases, just the credible option of third-party support can bring Oracle to the negotiating table for better terms on licenses or cloud subscriptions the company needs. This diversifies your risk—you are not 100% dependent on Oracle for everything, which can be useful if Oracle changes policies in the future.
Moreover, by freeing up a budget, you might invest in alternative technologies (for example, adopting an open-source database for new projects while keeping Oracle for legacy), thereby gradually reducing over-reliance on a single vendor.
Many experts list vendor independence as a strategic advantage; it gives the CIO more flexibility in long-term IT planning. Suppose Oracle’s direction doesn’t align with yours (e.g., they push cloud, but you want to stay on-prem or consider another cloud). In that case, you can make independent decisions more when you aren’t tied into their support ecosystem.
Building the Business Case: To justify the switch to stakeholders (CFO, CEO, IT governance board), CIOs should present both the tangible financial benefits and the mitigated risks:
- Start with the hard savings: “By switching support for X, Y, and Z Oracle systems to VendorABC, we will save $N million over the next 3 years.” Include the percentage reduction and what that money can fund instead (e.g., “This covers the cost of our digital transformation initiative”). Financial leaders respond to clear budget impacts, highlighting that third-party support turns a cost center into a source of funds for innovation. If possible, reference industry benchmarks (for instance, “Industry analysts note third-party support can halve maintenance costs”).
- Acknowledge what you lose (Oracle’s patches/upgrades) and then detail how to mitigate those risks. For security, explain the provider’s approach and note that many companies, including competitors or respected firms, successfully operate under this model (perhaps mention that Gartner actively recommends considering third-party support). For upgrades, note that you’re not ruling them out – you’re simply choosing the timing more judiciously.
- Include success examples: If you can cite a peer company or a case study in your vertical that did this and succeeded, it adds credibility. For instance, “Organization ABC (similar size in our industry) switched to third-party support in 2020 and saved 60% while maintaining 99.9% uptime. We have the opportunity to do the same.” Real-world validations ease stakeholder concerns.
- Emphasize that customer service will improve or at least remain high. Some execs might worry that leaving Oracle means second-class support. Explain the vendor’s support model, and possibly share any support guarantees or the fact that you’ll have former Oracle experts working on our systems. If you’ve done a pilot or reference call where someone praised the provider’s responsiveness, mention that. The goal is to ensure stakeholders that this is not a cut-costs-and-suffer decision but rather cut costs and potentially improve service.
- Address compliance and legal safety: Briefly mention that you have done due diligence to ensure this move is within legal boundaries (it is) and that you’ve planned for license compliance, so there’s no hidden risk of penalties. If you engaged a third-party license consultant or obtained an opinion, mention that to bolster confidence.
- Finally, consider the opportunity cost of staying with the status quo. If you keep paying Oracle, that money is gone, and you will still face an eventual forced upgrade (with more cost). By switching, you avoid the immediate upgrade spend and free budget. Essentially, staying on Oracle support has a high cost and limited value if your systems are stable – painting that picture helps justify the change (“we’re paying millions for what is effectively an insurance policy and patches that we don’t critically need; that money could be put to proactive use”).
CFOs and CEOs often appreciate that third-party support is a relatively low-risk cost reduction: you’re not discontinuing support; you’re substituting who provides it. The systems remain supported, users shouldn’t see any negative impact, and the company saves money.
When framed this way, many stakeholders see it as a smart business move rather than a risky experiment. Gartner’s endorsement and the growing adoption in the market have made it a mainstream strategy rather than an outlier.
In summary, third-party Oracle support can offer substantial and immediate cost savings. Strategic benefits include extended software life, improved support quality, and greater flexibility for the IT roadmap.
Organizations can accelerate other initiatives that drive competitive advantage by reinvesting savings and avoiding unnecessary upgrades. This aligns IT support spending with the business’s priorities – a key win for CIOs aiming to maximize value from every budget dollar.
Conclusion
Transitioning to third-party support for Oracle software is a strategic decision that can yield significant financial and operational benefits. As this article outlines, many organizations are turning to independent support providers to escape escalating Oracle maintenance fees, keep stable legacy systems running longer, and obtain a more customer-centric support experience.
Industry analysts and a growing community of successful adopters support this trend, indicating that third-party support has matured into a viable option for CIOs seeking cost optimization without sacrificing service.
However, the decision and transition require careful planning.
Key takeaways and final considerations for CIOs evaluating this path include:
- Weigh the Benefits vs. Trade-offs: Third-party support offers substantial cost savings (often 50% or more) and can deliver equal or better support quality, which is very attractive. On the trade-off side, your organization forgoes Oracle’s direct updates and must rely on the provider for security and bug fixes. Ensure your situation is one where this trade-off makes sense. Typically, the scale tips toward third-party support are beneficial if your Oracle environment is stable, mature, and does not need constant updates. If you plan to heavily adopt new Oracle cloud features or upgrade frequently, staying with Oracle support might be easier. Align the decision with your IT strategy and business needs.
- Do Your Homework (Licenses and Contracts): Conduct thorough due diligence on your Oracle licenses and contract obligations before committing. License compliance is paramount – confirm you can legally make the switch (in almost all cases, you can, with proper compliance) and won’t leave any license obligations hanging. Address any compliance gaps proactively. Also, review the third-party vendor contract carefully. In short, approach this as a significant vendor change, with involvement from your legal, procurement, and vendor management teams to dot the i’s and cross the t’s.
- Choose the Right Partner: The success of third-party support largely hinges on the capabilities of the provider you choose. Take the time to evaluate the major vendors (Rimini Street, Spinnaker Support, etc.) and select the one that best fits your organization’s culture and needs. Consider running a competitive bid or consulting references to gauge performance. A good third-party support provider will become a trusted extension of your IT team, so focus on quality and trustworthiness, not just cost. As one best practice, ensure the provider can support all the Oracle products you intend to cover – consolidation under one support provider is usually simpler than juggling multiple.
- Plan the Transition Meticulously: As detailed, have a solid transition plan. Avoid lapses in support coverage, involve all stakeholders, and communicate clearly. Leverage best practices from others who have done it – for example, conducting an IT audit and knowledge transfer upfront. The transition can be smooth if managed as a formal project with executive sponsorship and cross-functional coordination (IT, finance, compliance, etc., all playing a role).
- Monitor and Measure Post-Switch: Continuously measure the outcomes after moving to third-party support. Track realized cost savings and measure support performance (response times, issue resolution effectiveness). Report these back to stakeholders. This not only proves the value of the decision but also helps catch any issues early. Most organizations find that after an initial adjustment period, the new support model is as good as or better than the old – and the cost savings continue to accrue year over year. However, maintaining oversight ensures that any deviation in service quality is addressed via the SLA or account management with the vendor.
- Stay Informed and Flexible: The landscape of enterprise IT is always evolving. Keep abreast of updates from Oracle (for example, if Oracle changes its support policies or if new laws affect software support) and from the third-party support industry (new providers, new services, etc.). It’s wise to periodically revisit whether third-party support remains the best strategy as business conditions change. The good news is that with the money saved, CIOs have more flexibility to invest in modernization. Some use third-party support as a bridge to eventually replace the Oracle system with a next-generation solution. If that’s a goal, ensure your provider knows and supports your long-term plan.
In conclusion, moving to third-party support for Oracle can be a high-impact move for CIOs to reduce costs and gain flexibility. When executed with diligence, companies have maintained secure, compliant, and reliable Oracle systems under third-party care—all while unlocking funds for innovation and strategic projects. It shifts the balance of power back to the customer: You run your Oracle environment on your terms, not the vendor’s timeline.
For many, this is a refreshing change and a smart business decision. As you evaluate this option, use the insights and steps this paper outlines to guide your analysis. With proper planning, third-party support can become a cornerstone of your IT strategy, delivering value far beyond the bottom-line savings.
Please consider all the factors discussed – from security to license compliance – and make an informed choice that aligns with your organization’s goals.
Should you proceed, you will join a growing community of enterprises that have successfully navigated the transition and are reaping the rewards of a more cost-effective and agile support model for their Oracle investments.
