Global CIOs and IT procurement leaders increasingly evaluate third-party support as an alternative to Oracle’s Premier Support. Oracle’s support model is known for its high costs and rigid policies, prompting some organizations to explore independent providers. This blog-style guide compares Oracle Premier Support with third-party Oracle support across key dimensions – from cost and scope of coverage to SLAs, security, upgrade rights, contract terms, legal considerations, and product suitability. Each section ends with recommendations to help CIOs and sourcing teams make an informed choice.
Annual Cost Comparison (Oracle Premier vs. Third-Party)
Oracle Premier Support is notoriously expensive. Oracle typically charges ~22% of the software license value per year for support, often raising this fee by 3-8% annually. This means if you paid $1 million in licenses, you might pay about $220,000 in support the first year, and that cost will climb each year due to contractual uplifts. Over time, the compounding increases (and extra surcharges if your product moves into “Extended Support”) can dramatically inflate costs. For example, a scenario with Oracle Database licenses showed annual support fees more than tripling over 10 years (a 206% increase), rising from £401k in year one to £1.23M by year ten as the product moved past Premier into Extended and Sustaining support. Crucially, these price hikes often occur even as Oracle’s support services for older versions diminish (no new patches on Sustaining Support) – essentially “paying more for less”.
Third-party support offers a stark cost contrast. Independent support providers charge about 50% of Oracle’s fee for equivalent coverage. In practice, this translates to immediate savings of ~50% or more on annual maintenance. If you were paying $220k to Oracle, a third-party might charge around $110k for support of the same product, locking in a much lower run-rate. Moreover, third-party contracts often avoid the yearly hikes that Oracle imposes. Some third-party vendors even give multi-year fixed pricing or discounts for longer commitments. Over a multi-year period, organizations can save 50–70% cumulatively by switching, once you factor in avoided Oracle increases. For example, a large pharmaceutical company cut its Oracle E-Business Suite and Database support costs by 55% (saving $1.2 million per year) by moving to a third-party provider. Another company saved about 40% on Oracle support and reinvested those funds into IT upgrades. These real-world cases highlight the budget impact: millions freed up for other priorities.
Recommendations: Third-party support can deliver significant relief for CIOs focused on cost optimization. Calculate your annual Oracle support spend and project it over 5+ years; then compare a third-party quote at ~50% of that cost. The savings are often compelling, typically freeing funds to be redirected to innovation or debt reduction, as seen in case studies (e.g., one energy company saved $4M over five years by switching). When budgeting, account for any one-time transition costs (usually minimal) and the potential cost if you ever need to resubscribe to Oracle later. Ensure these savings align with corporate cost-cutting goals. If reducing OPEX is a priority and your Oracle systems are stable, third-party support is a financially attractive option. Leverage the cost difference in vendor negotiations as well – even if you stay with Oracle, knowing about third-party alternatives can provide bargaining power to seek discounts or concessions on your Premier Support renewal.
Scope of Support (Coverage of Custom Code and Older Versions)
One of the biggest differences between Oracle Premier Support and third-party support is what they will support. Oracle’s Premier Support has a defined scope: it covers assistance and patches for Oracle’s standard software as delivered, running on certified configurations. Critically, Oracle does not support customizations or modifications to their code – if you’ve tailored the application, Oracle may require you to reproduce issues in an uncustomized environment. Oracle eventually stops releasing new fixes for older product versions once they fall out of Premier/Extended Support (entering Sustaining Support). At that point, you no longer receive bug fixes, new updates, or regulatory patches for that product from Oracle. The result is a gap: customers on heavily customized or older Oracle systems often get limited help beyond basic usage questions or workarounds. Oracle’s message is essentially “upgrade to a supported version if you want full support”.
Third-party support providers, on the other hand, emphasize comprehensive coverage, effectively picking up where Oracle leaves off. Custom code support is a hallmark of third-party services: vendors will troubleshoot and fix issues in your customizations and integrations, not just the base Oracle product. This is a major win for clients with heavily tailored Oracle environments, who normally get “sorry, not our problem” from Oracle. Additionally, third-party providers support older versions indefinitely. Even if Oracle has long stopped providing patches for, say, Oracle E-Business Suite 11i or an Oracle Database version from 10 years ago, a third-party firm will still fully support it, including developing new bug fixes or workarounds. They effectively extend the lifespan of Oracle products. For example, a third-party provider can still resolve defects and address security issues via custom solutions if you’re running a stable Oracle E-Business Suite or Database release that Oracle no longer patches. This allows you to avoid forced upgrades and continue using the system if it meets business needs.
Third-party support also often includes help with interoperability (making your Oracle software work with other systems, OS, or browsers) even if Oracle doesn’t officially support those combinations. And for Oracle’s ERP products (like EBS, PeopleSoft, JD Edwards), independent support vendors deliver ongoing tax, legal, and regulatory updates to keep the software compliant with changing laws – something Oracle provides only to current versions under Premier Support. In other words, third parties strive to provide “full coverage” support: any issue that affects your Oracle system (including custom extensions, integrations, or localization changes) is in-scope for them to help, regardless of version. Oracle’s Premier Support is narrower: it’s limited to standard product issues on current versions and explicitly excludes customizations or anything Oracle deems outside its responsibility.
Oracle vs. Third-Party Support scope and model differences. Oracle’s support model is standardized and tends to exclude custom solutions or older versions. In contrast, third-party support offers dedicated, concierge-style service that includes custom code, broader interoperability, and support for legacy releases.
Recommendations: Evaluate how much of your Oracle environment falls outside the “vanilla” scope of Oracle Premier Support. If you have significant custom code and integrations, or are running an older version that still meets your needs, third-party support can provide far more value. It will cover areas that Oracle’s support won’t touch, ensuring you’re not left alone for custom-driven issues. CIOs should inventory their Oracle customizations and the versions in use. Suppose many systems are on stable, older releases (e.g., Oracle EBS 12.1 or Oracle Database 11g) that you prefer to keep running. In that case, third-party support can keep them fully supported without upgrade pressure.
On the other hand, if your implementation is relatively standard and you plan to stay current with Oracle’s releases, the scope gap is less of a concern—Oracle Premier Support may suffice if you don’t need help beyond the base software. Match your support model to your environment’s needs: Choose third-party support to cover custom and legacy scenarios. Be cautious about leaving Oracle support if you rely on features of the latest releases or frequent patch updates (those require staying on Oracle’s maintenance to access).
SLAs and Responsiveness
Support experience can be just as important as cost. Oracle is a massive organization, and its Premier Support, while global, is often criticized for being slow or impersonal. Logging a ticket with Oracle Support (via the My Oracle Support portal) typically goes through a tiered system. Initial responses might come from front-line support staff following scripted diagnostics. Complex issues can require multiple escalations before reaching an expert. Oracle has severity levels and targets. For a Severity 1 (critical) issue, Oracle’s policy is to respond quickly (often within an hour) and work 24×7 until it is resolved. However, many CIOs report that non-critical issues languish, and even critical ones can involve navigating bureaucracy. Additionally, Oracle’s support may sometimes default to “apply the latest patch or upgrade” as a solution, rather than providing an immediate fix, especially if the issue is resolved in a later release. The responsiveness and quality of Oracle’s standard support can vary, and customers often desire more personalized attention.
Third-party support providers build their reputation on superior service. They typically offer tighter SLAs and more personalized support for all issues, not just the highest severity. For example, many third-party vendors guarantee a 15- or 30-minute response time for critical (Priority 1) cases, with 24×7 availability. In practice, some report even faster average response – one provider cites an 8-minute average response time for all critical issues, vastly quicker than typical vendor support. More importantly, third-party support is usually engineer-led. When you call for support, you get direct access to a seasoned Oracle expert (often a dedicated engineer or a small team assigned to your account) rather than a call-center triage. These engineers often have 10- 15+ years of experience on Oracle systems and can start troubleshooting immediately. The support model is high-touch and concierge-like, focusing on quickly solving the problem rather than routing you through layers of support. Providers often assign an account manager and make proactive check-ins, essentially becoming an extension of your IT team. This contrasts with Oracle’s one-size-fits-all approach, where you are one of thousands of customers in a queue.
The result is often higher customer satisfaction with third-party support. For instance, one third-party vendor reports a 96%+ annual customer satisfaction rating, reflecting the responsiveness and quality of service. Real-world examples underscore the difference: the CIO of Oando PLC (a global energy company) switched from Oracle to third-party support and noted significantly faster response times and issue resolution, all while cutting costs. Many IT teams find that with independent support, they spend less time following up on tickets or arguing about whether something is “in scope,” and more time getting actual solutions. Issues that might have taken weeks of back-and-forth with Oracle can often be resolved in days or hours by an expert third-party engineer intimately familiar with the product and your environment.
Recommendations: If support responsiveness and quality are pain points for your organization, carefully compare SLAs. Ask Oracle (or peers) about the’ realistic response and resolution times for your critical issues. Then evaluate third-party providers’ SLA guarantees – many will offer aggressive response times (e.g., 30 minutes for P1 issues) and direct access to senior staff. For CIOs, the value of faster issue resolution can be huge (less downtime, less frustration for your IT team). Consider pilot discussions with third-party vendors to gauge their expertise – do they understand your Oracle stack well? Also, Oracle offers premium support add-ons (like Oracle Advanced Customer Services) for a fee if you need dedicated support; third-party support often includes that personalized service by default. In RFPs or evaluations, look beyond cost: scrutinize the support model. Speak with references of the third party to verify their responsiveness claims. If you stick with Oracle Premier Support, ensure a clear escalation path within Oracle for critical systems (and maybe negotiate that in your contract). But if you’re unsatisfied with Oracle’s service or need more hand-holding (common for complex ERP environments), third-party support could dramatically improve your support experience. Choose the model that aligns with your business’s tolerance for downtime and the level of attention you require.
Security Patching and Compliance Risks
One of the most sensitive considerations when leaving Oracle support is security. Every quarter, Oracle regularly releases official security patches (Critical Patch Updates, or CPUs) to fix product vulnerabilities. If you are on Premier Support, you have access to these patches and are expected to apply them to stay secure. By contrast, if you switch to third-party support, Oracle will cut off your access to these vendor patches and updates. Naturally, CIOs ask: “Without Oracle’s patches, how do we keep our systems secure and compliant?”. It’s a valid concern – moving away from Oracle’s patch program means you rely on the third-party provider to address new security threats.
Leading third-party support vendors have developed robust strategies to handle this. They typically implement “virtual patching” and other compensating controls to protect your systems. Instead of applying Oracle’s binary patch, the third-party team analyzes each reported vulnerability and finds a way to close the security gap via other means. For example, suppose a vulnerability is discovered in Oracle Database. In that case, the provider might create a custom code fix or a configuration change that neutralizes the issue without altering Oracle’s proprietary code. This could involve adding a database trigger, adjusting a configuration parameter, or deploying a specialized firewall rule to block the attack vector. This approach is often called “virtual patching” – putting a shield in place to prevent exploitation of a known flaw. In practice, it might mean the third-party provider writes a script or uses a security tool to intercept malicious requests, achieving a result comparable to the Oracle patch’s effect.
Third-party providers also tend to harden the environment and monitor it closely. Many include continuous security monitoring and intrusion detection as part of their service. They monitor your Oracle systems for any signs of attack, which can provide more proactive security than waiting for the next quarterly patch cycle. If a suspicious event occurs, the third-party support team can respond immediately, isolating a component or applying a quick mitigation, rather than you having to wait for Oracle’s next patch and schedule a downtime to apply it. Additionally, reputable providers run their own vulnerability research and penetration testing, so they’re aware of emerging threats and can craft defenses. They often issue their security advisories to clients (like Oracle does) with guidance on protecting against new vulnerabilities.
From a compliance standpoint, some industry regulations or internal policies expect you to apply vendor-supplied patches. However, third-party support can still meet security compliance requirements with proper documentation and controls. Providers will assist in showing auditors that even though you didn’t apply Oracle’s patch, you put alternative mitigations in place that address the vulnerability. For example, if a compliance rule (PCI, HIPAA, etc.) asks whether you’ve fixed a certain CVE, the third-party vendor will document how their virtual patch or firewall rule covers that CVE to satisfy the audit. In essence, they ensure there’s no gap in protection even without Oracle’s direct patch. To date, the track record has been reassuring. No widespread security incidents have been attributed to companies using third-party support, even among banks and governments that rely on these providers. Thousands of organizations have operated safely without Oracle’s patches using the third party’s security measures. Security is a shared responsibility – a third party can provide the tools and guidance, but the customer must implement recommended controls and remain vigilant.
One area third-party support also covers is regulatory updates for applications. For ERP systems (EBS, PeopleSoft, JD Edwards), staying compliant isn’t just about security patches – it’s about new tax rates, payroll law changes, or financial regulations. Oracle delivers those updates only if you are on support (usually on the latest release). Third-party providers also step in here: they commit to providing any necessary tax and legal updates to keep your system compliant with laws. For instance, if a new VAT rate is introduced or a labor law change affects payroll calculations, your third-party support vendor will create and supply the needed update for your Oracle system, just as Oracle would have during active support. This ensures companies in heavily regulated environments can stay on an older software version without falling afoul of the law.
Recommendations: Security is often the make-or-break factor when considering third-party support, so address it head-on. Involve your CISO or security team early and have in-depth discussions with potential third-party providers about how they handle vulnerabilities. Demand detailed explanations of their security program: Do they have certified processes (ISO 27001, SOC 2)? How do they develop and test custom patches? How quickly do they respond to zero-day threats? A strong provider should articulate a clear plan and even have “zero-day protection” programs. Ask for case examples of how they handled a major vulnerability in Oracle software without Oracle’s patch. Also consider an independent security assessment – you might have your security team or a third-party auditor review the provider’s approach. From a compliance perspective, ensure that switching to third-party support does not violate any explicit policy or requirement to use vendor support. It usually doesn’t, as long as you can demonstrate equivalently effective controls. Just be prepared to document everything: maintain evidence of each security fix or workaround applied, in case auditors ask.
In summary, you can maintain a strong security posture with the right third-party provider, but it requires due diligence. If your organization is extremely risk-averse and only trusts vendor patches, sticking with Oracle might be the safer choice. Otherwise, with careful vetting and collaboration, third-party support can keep you secure and compliant while you enjoy the other benefits.
Upgrade and Update Rights
Oracle Premier Support doesn’t just help you with your current software but also entitles you to upgrade to new versions. As long as you pay support, Oracle allows you to download and migrate to the latest releases of that product (for example, moving from Oracle Database 12c to 19c) without buying a new license. This “right to upgrades” is a key part of the value for some: you invest in Oracle’s roadmap and can take advantage of new features and enhancements when ready. Oracle’s support fees essentially fund their R&D for new versions; in return, you get those updates included. However, Oracle also times its support periods to push upgrades; a version might only have Premier Support for 5 years, so you’re expected to upgrade to continue getting full support. If you stay on an older version, Oracle will eventually only offer Sustaining Support (no new fixes) until you upgrade.
With third-party support, the dynamic flips. When you leave Oracle support, you lose the automatic right to upgrade to Oracle’s newest versions. Third-party providers will support the version you’re on (and even help you apply any updates you already have rights to). Still, they cannot provide you with Oracle’s proprietary new software releases. You enter a “steady state” – the provider will fully maintain and patch your system. Still, it will not receive official new features or major version upgrades from Oracle. Many organizations choosing a third-party are intentionally deciding to skip or defer upgrades. They often run mature systems where the current functionality meets business needs, and the next Oracle version doesn’t provide a compelling ROI compared to the cost and disruption of upgrading. Third-party support enables a “stay on this version indefinitely” strategy for such cases. You can even skip multiple Oracle release cycles. For example, a company on Oracle E-Business Suite 12.1 (for which Oracle has ended Premier Support) can have a third-party support it for, say, five more years, during which time they do not upgrade. Later, if they choose to move to a new platform (or even eventually jump to Oracle’s cloud applications), they do so on their timeline, not Oracle’s forced schedule.
It’s important to understand the trade-off: by using third-party support, you forgo access to Oracle’s updates. You won’t get new Oracle features, and if Oracle releases, say, a revolutionary new version with must-have capabilities, your current contract wouldn’t cover it. To get that, you’d need to resubscribe to Oracle support (or purchase new licenses), which can be expensive. Oracle generally requires you to pay back support fees for the period you were out, plus potential penalties, before allowing you to upgrade to a new version. This can sometimes cost as much as buying the licenses again, depending on how long you’ve been off support. Many third-party organizations don’t foresee a need to upgrade shortly. They might be planning to eventually replace the system with a different solution (like moving from JD Edwards to a cloud ERP), or they determine that their version is “good enough” for the next 5-10 years. The cost savings from third-party support can even help fund a future replacement, as seen in case studies where saved support dollars were set aside for an eventual migration project.
There are ways to mitigate the upgrade limitation. Before leaving Oracle support, Savvy customers will often download the latest available patches and versions from Oracle’s support portal as a contingency. Third-party providers sometimes guide clients in building this archive (“in case we ever need to upgrade later, we have the software bits”). While you legally shouldn’t deploy a new Oracle version without active support, having those files can simplify things if you negotiate re-support or need to demonstrate what you’re entitled to. Also, some customers adopt a “hybrid” strategy: keep Oracle support for products they plan to upgrade soon, but use third-party support for stable products they intend to keep as-is. This way, you allocate Oracle support budget only to the systems where new versions matter. However, be cautious with Oracle’s rules (see next section on contractual issues) if attempting a mix-and-match.
Recommendations: Align your support choice with your IT roadmap. If your business requires constant innovation from Oracle’s products – e.g., you need the latest database features or plan to upgrade Oracle EBS in a year – then staying on Oracle Premier Support is advisable. You don’t want to save support costs at the expense of falling behind on technology you truly need. On the other hand, if your Oracle systems are feature-complete for your purposes and you see no compelling reason to upgrade for several years, that’s when third-party support makes a lot of sense. It lets you maximize the ROI of your current software by using it longer without pressure. Many CIOs use third-party support as a bridge strategy: it buys them time to evaluate alternatives (maybe migrating to a cloud SaaS or consolidating systems) while avoiding disruptive upgrades that Oracle’s schedule would have forced. Just be sure to plan. If you think you might need to return to Oracle support to upgrade in the future, understand Oracle’s reinstatement policies and budget for that. Sometimes the savings from 3-4 years of third-party support still outweigh the one-time cost of rejoining Oracle for an upgrade later, but do the math for your case. One approach is to funnel a portion of the annual savings into an “upgrade fund” for the future.
Before leaving Oracle, download any available updates and document the system thoroughly. In summary, choose third-party support when you are comfortable staying on your current software release for the foreseeable future. Suppose you anticipate continuously needing Oracle’s latest advancements. In that case, you’re better off sticking with Premier Support (or re-evaluating whether that Oracle product is right for your needs if its upgrade cadence is too demanding).
Vendor Lock-In and Contractual Risks
Oracle’s support contracts are notoriously sticky. When discussing “vendor lock-in,” Oracle Support is often a prime example: once you’re on it, the policies and terms make it difficult to leave or reduce scope without pain. Under Oracle’s standard contracts, you generally must keep all licenses of a given product on the same support level, known as the “Matching Service Levels” clause. In practice, it means you cannot decide to put half your Oracle Database licenses on third-party support and keep half with Oracle; Oracle will require that if you drop support on any licenses in a product family, you must drop it for all of them (or terminate those licenses). This prevents partial switching and is intended to discourage leaving at all. Oracle also typically sells support as an annual subscription paid upfront – if you want to cancel mid-term, you likely won’t get a refund for unused months. These terms create a contractual lock-in: you face timing constraints (you can only switch at renewal time to avoid paying twice) and all-or-nothing decisions per product line.
Organizations aim to break free of some of this lock-in by moving to third-party support. You no longer have to follow Oracle’s upgrade timelines or policies; you can choose which products to support and which to retire on your schedule. However, it’s worth noting that you are still “locked in” to your Oracle software license itself (since third-party or not, you’re using Oracle’s IP). You remain an Oracle customer regarding the license agreement; you are just not a support customer. Oracle has used its sales and renewal processes to exert pressure. For example, suppose you stop support for a certain product. In that case, Oracle’s sales team may be less inclined to offer discounts on other products or cloud services you want to buy, effectively using their broader relationship as leverage.
Additionally, if you later decide to return to Oracle support, as mentioned, they may charge back-support fees for the lapsed period, which can be a significant financial barrier. Companies sometimes purchase new licenses for a product rather than pay for support, to avoid that penalty. Still, either way, it’s a cost that underscores the one-way nature of leaving Oracle support.
There’s also a perceived audit risk when leaving Oracle. Many in the industry suspect (and some evidence suggests) that Oracle may increase license audit scrutiny on customers who cancel support, since it’s a revenue loss for Oracle. Oracle audits are contractual: Oracle can audit your software usage to ensure you’re not exceeding your licensed rights. While audits happen to customers on support as well, those who depart might get flagged because Oracle wants to ensure you’re not, for instance, downloading patches without entitlement or using extra licenses to self-support. Third-party providers are aware of this and often advise clients to stay tightly compliant and prepared for an audit. It’s wise to conduct an internal license audit (or hire a license specialist) before leaving Oracle support to ensure your deployments and usage are 100% within the bounds of your license agreement. That way, if Oracle does an audit, you won’t get hit with a non-compliance bill that eats up all your savings. In reality, while the risk of an audit exists, it’s not a given that leaving support triggers one. Oracle audits customers both on and off support for various reasons. But you should be prepared and not give Oracle any easy excuses.
From the third-party provider side, contracts are often more flexible. Many third-party vendors will allow annual termination or scaling down of support as your needs change (for example, if you decommission some servers, you can reduce the support scope in the next term – something Oracle might not allow easily due to their repricing policies). Some even offer on-demand support models or tailored terms to fit your business. You typically sign a contract with the third-party firm for a set of products; ensure it has provisions that suit you (like the ability to cancel if service is poor, etc.). You should also verify that your contract with Oracle has no sneaky clauses prohibiting using third-party support – by law (in many jurisdictions), a vendor can’t stop you from outsourcing support, but always double-check the language or have legal counsel review it.
Recommendations: Before making any switch, review your Oracle license and support agreements in detail. Look at the “Matching Service Levels” and any termination or reinstatement clauses. Plan your third-party transition to coincide with support renewal anniversaries to avoid overlap payments. If you have multiple Oracle products with different end dates, coordinate with the vendor or consider co-termination to simplify switching. Engage a licensing expert or legal advisor to understand the ramifications of cancelling support for each product – for example, what rights you lose (like upgrade rights), and how long you can remain off support before reinstatement is impractical. Mitigate lock-in by preparing: as mentioned, do an internal audit to ensure compliance and document all your licenses. This way, Oracle has little leverage in an audit scenario. Communicate internally that Oracle support will end, even change or restrict access to Oracle’s support portal (MOS) for your admins to prevent accidental downloads that violate terms. In negotiations, you can also use the possibility of third-party support to push Oracle to reach a better deal. Some organizations have gotten Oracle to offer discounts or extra perks to keep them on support – it may or may not work, but it’s worth a try. Finally, negotiate flexibility when contracting with a third-party provider: ensure you aren’t locking yourself into a long-term contract without escape. A one or two-year contract to start, with the ability to extend, is prudent. If you are keeping some Oracle products on Premier and others on third-party, double-check with legal that you’re not violating Oracle’s policies (generally, you can’t split support within the same product, but you can split by product line if contracts are separate). In summary, go in with eyes open about Oracle’s contractual hooks. With careful planning, you can navigate away from Oracle’s lock-in and enjoy more freedom, but it requires diligence in contract management.
Indemnity, Legal Coverage, and Audit Protection
A common question is the legality of third-party support and what legal protections customers have. Let’s be clear: third-party support for Oracle is legal – your Oracle license allows you to seek support from other sources, as long as you aren’t violating intellectual property rules. The long-running Oracle v. Rimini Street court battle reinforced this. While Rimini (a third-party provider) was found to have used some illegal methods in the past, the courts affirmed that Oracle customers do have the right to third-party support options. Oracle’s executives testified that third parties can offer support services to Oracle licensees, as long as they don’t infringe Oracle’s copyrights. Today’s reputable third-party vendors have adjusted their processes to comply with the legal rulings. For example, they no longer download patches from Oracle’s site on your behalf using Oracle credentials (one of the issues in the Rimini case). Instead, they develop fixes independently or work with permission within the customer’s environment. As a customer, you should not be at legal risk using third-party support, provided the provider follows the rules. The onus is on the support provider not to infringe Oracle’s IP. Top providers often state in their contract that they will indemnify the customer if Oracle were to sue over how support is being delivered. In practice, Oracle has pursued third-party vendors in court, not customers. No Oracle customer has been found in breach just for using third-party support – it’s allowed under your license to choose who maintains your software.
That said, it’s wise to include some legal safeguards. When evaluating a third-party support contract, consider an indemnification clause where the provider pledges to defend you if their services cause an Oracle IP infringement claim. For example, if the provider supplied a patch that Oracle claims is an unauthorized derivative work, the provider should take responsibility. Reputable firms have this covered (and it’s rarely needed, as they design solutions to avoid copying Oracle code). It’s also worth noting that your original Oracle license typically includes Oracle’s indemnity for intellectual property (Oracle promises to defend you if the Oracle software infringes someone else’s patent or copyright). That indemnity remains in force regardless of support status, since it’s tied to the license, not support. So you don’t lose Oracle’s IP indemnification just by leaving support – you’re still legally licensed to use the software. You lose Oracle’s warranty and assurances that come with active support. Still, Oracle’s standard support contract disclaims many warranties anyway (Oracle support is provided “as is” in many agreements).
Audit protection is another angle. As discussed, Oracle can audit your software usage. Third-party support providers can’t stop Oracle from exercising that right, but they often help customers prepare and respond. Some third-party vendors have license advisory services to ensure you stay compliant (since it’s in both your interests to avoid an Oracle compliance issue). They may guide you on properly documenting usage or even assist with data collection during an audit. Proactive compliance is the best “protection”: know your entitlements and stick to them. If you do that, an audit should not scare you. It’s also worth being mindful not to inadvertently use Oracle support resources after you’ve left – for instance, do not download patches from Oracle’s support site or log SRs, as that would breach terms and could trigger penalties if discovered. Once you leave, keep a clean break with Oracle support systems.
Recommendations: In any transition to third-party support, loop in your legal counsel and procurement team early. Have them closely review the third-party provider’s contract, paying special attention to indemnity, liability, and termination clauses. You want to be protected if the vendor fails to deliver or any IP questions arise. Ask the provider directly about the Oracle v. Rimini case. What they learned – a serious vendor will explain how they operate within legal boundaries (for example, doing all development on the client’s licensed systems or using publicly available info). Getting a statement that they will handle any Oracle challenges can also be reassuring, so your company isn’t in the middle. Internally, ensure everyone understands the rules: no one should call Oracle for support or download Oracle’s patches once you switch (it sounds obvious, but large organizations have many administrators). Changing the Support Identifier password or locking that account is a good practice to prevent accidental violations.
Regarding audits, stay vigilant. Conduct a self-audit or use a third-party license expert to double-check your compliance before leaving Oracle support. Fix issues (e.g., uninstall unused software or procure licenses for any over-deployment) so you’re audit-ready. Suppose Oracle sends an audit notice, engages a licensing specialist to respond, and informs your third-party support provider. In that case, they’ve likely seen it before and can advise.
In summary, protect yourself legally, but don’t be overly fearful: thousands of companies use third-party support without legal trouble. Just choose a vendor with a solid track record, get the right contractual assurances, and maintain compliance discipline. With that, the legal risks remain low and manageable.
Suitability for Different Oracle Products (EBS, PeopleSoft, JD Edwards, Database, etc.)
Not every Oracle product is equally suited to third-party support. Generally, third-party support is most popular for Oracle’s mature, stable product lines, especially those where Oracle is no longer innovating heavily or pushing aggressive upgrades. Here’s a breakdown of how third-party support fits for various Oracle software families:
- Oracle E-Business Suite (EBS): Oracle EBS (the on-premise ERP suite) is a prime candidate. Many organizations run older EBS versions (12.0 or 12.1) that Oracle has desupported or moved to Sustaining Support. Third-party providers have strong EBS offerings, including patches for known issues and updates for regulatory changes (tax, HR, etc.). If you’re on EBS 12.1, for example, Oracle’s Premier Support ended in 2021, but a third-party can fully support you for as many years as needed. Even EBS 12.2 (the latest release) can be supported by third parties if you choose, though Oracle is still actively supporting 12.2 through at least 2032. Companies that are stable on EBS and not planning to move to Oracle’s Cloud ERP often use third-party support to avoid forced migration. Real-world example: A large manufacturer running an older J.D. Edwards ERP (part of the Oracle EBS/JD Edwards family) switched to third-party support and avoided an expensive, forced upgrade, extending the life of a stable system. They saved on support fees and deferred a costly migration until it made business sense.
- PeopleSoft: PeopleSoft (Oracle’s HR/Finance applications) is another popular area. Oracle has committed to supporting PeopleSoft through at least 2034, but minimal new features are in maintenance mode. Organizations with PeopleSoft working well for their needs (especially heavily customized HR systems) sometimes move to third-party support to cut costs while receiving necessary tax and regulatory updates. Third-party providers cover PeopleSoft Payroll updates, benefits regulatory changes, etc., just like Oracle would. This can be attractive for public sector or education clients who plan to keep PeopleSoft long and can’t justify Oracle’s high support fees. The key is if you’re not looking to adopt Oracle’s newer cloud HCM products and are content with PeopleSoft’s functionality, third-party support can maintain it indefinitely. Many government agencies and companies have done this, seeing savings without disruption.
- JD Edwards and Siebel: These are Oracle’s legacy ERP/CRM systems (acquired from PeopleSoft/JD Edwards and Siebel). Both have loyal customer bases but limited new development from Oracle. JD Edwards (EnterpriseOne and World) users often are on older releases that Oracle has phased out of Premier Support. Third-party support is common here – it allows JD Edwards customers to keep their systems (manufacturing, finance, etc.) running with full support and patches, instead of undergoing a reimplementation. Similarly, Siebel CRM is used in industries like financial services and the public sector; Oracle still supports Siebel, but many Siebel deployments are mature. Third-party vendors offer support for Siebel so that companies can avoid migrating to Oracle’s Cloud CX or another CRM until they’re ready. Essentially, if you have Oracle-acquired products (EBS, PeopleSoft, JDE, Siebel, Hyperion, etc.) that are stable in production, third-party support is a viable and often used option. Providers have deep expertise in these (often hiring former Oracle/PeopleSoft/JDE engineers).
- Oracle Database and Middleware: Third-party support for Oracle Database (and related tech like Oracle Fusion Middleware, WebLogic, Oracle Business Intelligence, etc.) is also available, though considerations differ. Databases are the infrastructure backbone – many organizations update them for security/performance. However, if you’re running an older Oracle Database (say 11g or 12c) that works fine, third-party support can cover it and let you avoid an upgrade to 19c or 21c. This is common in cases where the database supports a legacy application that won’t certify a newer DB, or where upgrading hundreds of databases is prohibitive. A mid-tier bank, for example, moved its Oracle Database and middleware support to a third party and saved ~60% annually, while maintaining older DB versions until legacy apps were phased out. The bank’s CIO used Gartner’s endorsement of third-party support to assure stakeholders that this was a safe move. One must weigh security more heavily (as discussed earlier) for databases. Third-party support is suitable if the databases are in controlled environments and you trust the provider’s security updates. Suppose you run mission-critical databases exposed to the internet. In that case, you’ll need to be very confident in the third party’s ability to secure them, or you might keep Oracle support for those. Middleware and BI tools (WebLogic server, OBIEE, etc.) are often stable products where third-party support can extend their usable life again, especially if you’re not ready to adopt Oracle’s next-generation analytics or cloud middleware.
- Oracle Cloud and SaaS products: It’s worth noting that if you use Oracle’s cloud services (e.g., Oracle Fusion Cloud applications, Oracle Autonomous Database cloud service, etc.), third-party support does not apply. Those are subscription services where Oracle alone provides support (since the software is in Oracle’s cloud). Third-party support is for on-premises or customer-controlled software with a perpetual license. So the strategy is relevant for Oracle Database, Oracle applications, and middleware that you run yourself (on your servers or even on IaaS cloud infrastructure). If you have a mix of on-prem and cloud, you might consider a third-party for the on-prem portion while continuing Oracle’s support for the SaaS parts.
In summary, third-party support is most suited for mature, on-premises Oracle products you intend to run “as is.” Virtually all major Oracle on-prem products have some customers using third-party support: E-Business Suite, PeopleSoft, JD Edwards, Siebel, Oracle Database, Oracle Middleware, Hyperion, Oracle Retail applications, etc. The common thread is that these customers are looking to save money and avoid disruptions (like forced upgrades or migrations), and their systems’ day-to-day needs can be met without Oracle’s direct involvement.
Recommendations: Take an inventory of your Oracle portfolio and assess each product’s future path. For each system, ask: “Is this something we plan to significantly upgrade or transform in the next few years, or is it largely in maintenance mode?” Target the latter category for third-party support consideration. Ideal candidates are older versions of ERP/CRM systems or databases that are stable and meet current business needs (especially if Oracle’s support is nearing end-of-life). For those, third-party support can yield big savings and buy you time.
On the other hand, for any Oracle products that are strategic and evolving (for example, maybe you heavily rely on Oracle Database 19c and look forward to adopting Oracle’s future 23c release for new features), you might keep those on Oracle Premier Support to retain full upgrade rights. It doesn’t have to be an all-or-nothing across your entire Oracle estate. Many enterprises adopt a hybrid model, e.g., they use third-party support for their legacy ERP instances and some databases, but stay with Oracle for a few cutting-edge deployments or where they want Oracle’s latest updates. Just ensure you’re not breaking Oracle’s contractual rules by splitting support within a product license set (recall the matching service level policy). Communicate your strategy to stakeholders: for each system moving to third-party, outline why it’s suitable (e.g. “Oracle Hyperion – no new features needed, just maintenance, so third-party will suffice and save $X”), and for each staying on Oracle, explain that too (e.g. “Oracle Database for our analytics platform – will upgrade to new version next year, so need to stay on Oracle support”). This product-by-product analysis will help you maximize value – you could even transition in phases, starting with one or two systems as a pilot. Finally, choose a third-party provider with proven expertise in the specific Oracle products you are targeting (ask for their case studies or reference clients in those areas). A provider might be very strong in E-Business Suite and PeopleSoft, but less experienced in Oracle Retail – you want to match their strengths to your needs. With the right mapping of products to support models, you can reduce costs where it makes sense while maintaining Oracle support where it truly matters, achieving an optimal balance for your portfolio.
Recommendations (Strategic Guidance for CIOs and Sourcing Teams)
Deciding between Oracle Premier Support and a third-party alternative is a strategic choice that requires weighing cost, risk, and long-term IT strategy. Here is a summary of key advice and steps to guide your evaluation and potential transition:
- Assess Business Needs vs. Vendor Roadmap: Determine which of your Oracle systems are in “maintenance mode” versus those requiring innovation. If a system’s requirements are stable and the business isn’t demanding new features, it’s a strong candidate for third-party support (cost savings, extended life). If the business expects ongoing new capabilities from Oracle (or if the product is tied to Oracle’s cloud strategy, you plan to adopt), staying on Premier Support might be justified.
- Build the Financial Case: Calculate the multi-year TCO difference. Factor in Oracle’s 22% yearly fees plus anticipated 3-5% annual increases (and even higher if extended support fees loom), versus a third-party quote at roughly half the cost with little or no inflation. Most organizations see an immediate OPEX reduction of>50%. Project these savings over five years – it often amounts to millions, which can be reallocated to strategic projects. Be sure to include any one-time transition costs (usually minor, like consulting or internal effort) and the “risk cost” of things like potential back-support fees if you had to return to Oracle (though you can decide if that risk is acceptable or needs a contingency budget). Present this financial analysis to executive stakeholders – CIOs have successfully won board approval by showing that third-party support can “turn maintenance dollars into innovation dollars”.
- Evaluate Providers Rigorously: Not all third-party support vendors are equal. Look at the big players with long track records (e.g., Rimini Street, Spinnaker Support, Support Revolution, etc., each with 10+ years in this market). Check their expertise in your specific Oracle products and industries. Issue an RFP or conduct workshops: ask about their SLA commitments, how they handle security (request detailed process info), how they deliver regulatory updates, and their staffing model (will you get named engineers?). Ask for reference customers, ideally in your region or industry, and call those references. Also, inquire about any legal assurances, such as how they ensure their support is legally compliant and what indemnification they provide. A little due diligence goes a long way to ensure you pick a solid partner.
- Plan the Transition Meticulously: Switching support providers is unlike flipping a switch daily. Coordinate it with your Oracle support renewal dates to avoid overlap or gaps. Inform Oracle of non-renewal per contract requirements (typically 30-90 days’ notice). Before the cut-off, download all Oracle documentation, patches, and knowledge base articles you might need in the future (since your access to Oracle’s support portal will be revoked). Communicate internally to application owners and admins about the new support process (e.g., new ticketing procedure with the third-party). Have a kickoff with the third-party provider to ensure they have all the documentation about your environment. Ideally, run a short parallel period: for the first few weeks, both Oracle and the third-party may assist (some companies overlap support for a month for peace of mind, though it does incur extra cost). In reality, many have a clean cutover without overlap, but make sure your critical patches due from Oracle (like quarter-end payroll updates) are applied before switching, or have the third-party ready to handle them. Also, educate your users that they’ll call the new provider for issues in the future – it can be seamless, but people need to know the change.
- Monitor and Measure Outcomes: Treat the first 6-12 months with the third party as a proving period. Closely track support metrics – response times, time to resolve issues, system stability, etc. – and compare against your past Oracle support performance. Collect feedback from your IT staff: are they satisfied with the new support? You’ll most likely find equal or better service quality if you choose a reputable vendor, but if any issues arise, address them early with the provider. Regular service reviews (monthly/quarterly) with the third-party account manager help keep things on track. By measuring the outcomes, you can validate the decision to your management with data (e.g., “We cut costs 50% and our average ticket resolution time improved by 30%”). This also builds confidence to expand third-party support to other areas or, conversely, to know if a course correction is needed.
- Have a Long-Term Application Strategy: Third-party support is a tool that gives you flexibility. Use the breathing room (and budget savings) it provides to plan for the future of each application. Maybe in 5 years, you will replace that old ERP with a modern cloud system – the third-party support saved money to fund that project and kept the old system running till you were ready. Or perhaps you’ll find that the system can run indefinitely; you might stay on third-party support for 10+ years if it continues to deliver. Keep an eye on Oracle’s moves, too – if Oracle dramatically changes its policies or new offerings become compelling, you may reconsider the support model. Stay informed: Gartner and other analyst firms regularly publish on third-party support trends (for instance, noting that it’s a growing market and increasingly accepted practice). Explaining your strategy to stakeholders can arm you with external validation (“We’re not an outlier; many companies, including peers, are doing this”).
In conclusion, Oracle Premier Support vs. third-party support is not an all-or-nothing, good-vs-bad choice – it’s about what fits your organization’s needs and priorities. Oracle’s support brings the comfort of the OEM backing and guaranteed access to new updates, but at a high price and with certain limitations. Third-party support offers freedom from Oracle’s schedule and significant cost savings, with a potentially superior service experience, but requires a bit of extra diligence on security and future upgrade planning. Many CIOs have successfully navigated this decision and achieved immediate cost benefits, extended the life of legacy systems, and maintained compliance by leveraging third-party support. The key is to do so deliberately: pick the right systems, partner with the right provider, and manage the change carefully. By following the recommendations above, IT leaders and procurement can confidently determine whether third-party Oracle support is a viable and advantageous path for their enterprise, and if so, execute the switch with minimal risk and maximum reward.
