How to Reduce Oracle Support Fees
- Audit Licenses: Identify unused or underutilized licenses and terminate them.
- Negotiate Renewals: Push for discounts, freeze annual uplifts, and leverage quarter-end timing.
- Switch to Third-Party Support: Save up to 50% with providers like Rimini Street.
- Optimize Licensing: Use Named User Plus instead of Processor where possible.
- Leverage ULAs Strategically: Maximize deployments before certification to avoid wasted costs.
Reducing Oracle On-Premise Support Fees: A CIO’s Guide
Oracle’s support fees for on-premise software are a significant recurring cost that can strain IT budgets.
Oracle typically charges an annual support fee of 22% of the original license purchase price. These fees often increase by 8% per year as a standard uplift, meaning costs can compound over time.
For CIOs managing a portfolio of Oracle databases, middleware, or applications on-premises, the challenge is to rein in these escalating support expenses without compromising critical support and updates.
Common Challenges:
CIOs face complex contracts and policies that make cost reduction difficult. Oracle’s agreements may include clauses like the “Matching Service Levels” policy, which requires all product licenses to be on the same support level.
This all-or-nothing approach prevents dropping support for only some licenses.
Additionally, many organizations pay maintenance for unused or underutilized licenses (“shelfware”) that no longer deliver value.
In one case, a financial institution discovered that $2 million in annual Oracle support fees were tied to software it wasn’t using.
Such scenarios illustrate how a lack of visibility and flexibility in Oracle contracts can result in wasted spending.
CIOs also worry about Oracle’s periodic audits and the risk of compliance issues, which Oracle can use as leverage to drive new sales or maintain high support spending.
This guide provides a structured approach to tackling these challenges and reducing on-premise Oracle support fees. It covers licensing fundamentals, negotiation tactics, third-party support alternatives, and a real-world case study.
Oracle Licensing Models
Effective cost management begins with a solid understanding of Oracle’s on-premise licensing models.
How your Oracle software is licensed directly impacts support fees and opportunities for savings.
Key concepts include the distinction between perpetual and term licenses, how Oracle charges for Named User Plus versus Processor metrics, the implications of an Oracle ULA (Unlimited License Agreement), and common pitfalls in licensing agreements that can lead to inflated costs.
Perpetual vs. Term Licensing
Oracle historically offered two main licensing types for on-premise software: perpetual licenses and term licenses.
A perpetual license grants the right to use the software indefinitely (a one-time upfront fee) with a separate annual support contract.
In contrast, a term license allows the use of the software for a limited period (e.g., 1-5 years) for a lower upfront cost. However, as of 2020, Oracle has phased out most term licenses for on-premise products, except for certain one-year term options on specific technology products.
Today, most on-premise Oracle deployments use perpetual licensing, meaning customers pay once for the license and then 22% per year of the cost for support going forward.
For CIOs, the key difference is in flexibility and long-term cost. Perpetual licenses require a larger upfront investment but can be more cost-effective over the long term. In contrast, term licenses (where still available) spread costs over the term but must be renewed or replaced when they expire.
Remember that support fees for term licenses are still calculated based on the equivalent perpetual price (Oracle uses 22% of the license list price even for one-year term deals), so there is no support discount for shorter terms.
Understanding your license type is crucial: With perpetual licenses, you can drop support (and stop paying) if you decide the software is no longer needed—though doing so comes with other consequences, as discussed later.
Named User Plus vs. Processor Licensing
Oracle’s pricing metrics determine how licenses (and thus support fees) are quantified.
The primary metrics for on-premise Oracle software are Named User Plus (NUP) and Processor licenses.
- User Plus licensing is based on the number of distinct users (or devices) authorized to use the Oracle software. It’s suitable for environments with a finite, countable user population. Oracle defines a Named User Plus as an individual authorized to use the programs, regardless of whether the person is actively using them at any given time. Importantly, Oracle requires a minimum number of NUP licenses per processor to meet a base level. For example, the rule for Oracle Database Enterprise Edition is typically 25 Named User Plus per processor as a minimum. This means that even if you have only 10 actual users on a server with one processor, Oracle would still require you to purchase 25 NUP licenses (and pay support for all 25). NUP licensing can be cost-effective if you have a limited number of users on a given system. CIOs may leverage NUP licensing in scenarios such as internal systems with a small user base to avoid the higher cost of processor-based licensing.
- Processor licensing is based on the processing power of the servers where the software runs, measured in the number of processor cores (with core-specific multipliers). This model allows an unlimited number of users. You must license all processors on the machines running the Oracle software, applying Oracle’s core factor table to account for different CPU types. For instance, if a server has eight cores and Oracle’s core factor for that CPU model is 0.5, it would require 4 Processor licenses. Processor licensing is often used for applications where the user count is unknown or very large (e.g., public-facing web services), or simply when it yields a lower cost than counting users.
Impact on Support Costs:
The choice between NUP and Processor affects support fees since support is a percentage of the license cost. Choosing the model that fits your usage pattern is important to avoid over-licensing.
Pitfall: If an organization initially licenses by Processor but has a small user count, it might be overpaying; conversely, if it licenses by NUP but user counts grow (or it hits Oracle’s minimums), costs could spike unexpectedly.
As a best practice, organizations should periodically review usage metrics. If you have far fewer users than a Processor license would imply, there might be an opportunity to re-negotiate metrics (for example, switching to NUP on a contained system to reduce support fees).
Remember that changing metrics might require Oracle’s approval and possibly new licenses, but it’s a conversation worth having during renewals or True-up negotiations.
Oracle ULA (Unlimited License Agreement) Considerations
An Unlimited License Agreement (ULA) is a time-bound contract (typically 3 years) in which Oracle grants customers unlimited use of specified products.
ULAs can be attractive to organizations anticipating significant growth in Oracle usage, as they provide flexibility to deploy without counting licenses, usually for a one-time negotiated fee.
However, ULAs carry specific considerations for support costs:
- You pay a fixed annual support fee during the ULA term, often pegged to the upfront ULA cost. Oracle calculates the ULA price (licenses plus support) based on your forecasted needs, plus a growth buffer. This means you’re paying for expected future usage; if your actual deployments stay below the forecast, you’re effectively overpaying.
- When the ULA expires, you must certify usage – i.e., count how many licenses you have deployed – and that number becomes your perpetual entitlement. The crucial point is that the annual support fees do not decrease once the ULA ends, even if your actual usage is lower than the contracted amount. The support cost is locked in at the level determined during the ULA, “regardless of the number of licenses deployed” afterward. In other words, if you overestimated your needs or your business downsized, you could be stuck paying for shelfware at an unlimited scale. Oracle will still apply the standard yearly uplift (e.g., 8%), so the support cost can only increase, not decrease.
- Pitfalls: Failing to maximize usage during the ULA means higher unit costs. Also, any products included in the ULA that you don’t use become shelfware but cannot be removed from the support bill – Oracle doesn’t allow dropping unused ULA components during the term. CIOs considering a ULA should carefully assess if anticipated growth justifies it. ULAs work best when you fully deploy as much of the covered software as possible so that when you exit the ULA, your certified license count (and corresponding support fee) aligns with real needs. If your deployments fall short, you’ll be locked into paying expensive support fees in perpetuity for licenses you’re not using.
In summary, ULAs can yield value in the right scenarios (massive growth and need for deployment flexibility) but require diligent planning and execution.
Always model the break-even point: compare the 3-year ULA cost (license + support) versus a non-ULA scenario of buying only what you use.
Ensure you have a strategy in place for the end of the ULA—either certify high usage or be prepared to negotiate a follow-on deal if necessary.
Potential Pitfalls in Oracle Licensing Agreements
Beyond the licensing models, Oracle’s contracts contain clauses and policies that can inadvertently increase costs.
CIOs should be aware of these common pitfalls to avoid unpleasant surprises:
- Matching Service Levels Policy: Oracle generally requires that if you want support on any program licenses, you must maintain support on all program licenses at the same level of support. This “all or nothing” rule prevents cherry-picking of licenses to support. For example, you cannot drop support on half of your Oracle Database licenses while keeping support on the rest unless you fully terminate (and de-license) those instances. This policy makes it difficult to selectively reduce support costs. CIOs facing budget pressure might consider cutting support on non-production systems, only to learn that Oracle’s policy disallows it unless those licenses are completely removed. The workaround is often to terminate licenses (with possible penalties) or move certain systems entirely off Oracle support (e.g., via third-party support, discussed later).
- Reinstatement Fees: If you let an Oracle support contract lapse (intentionally or by accident) and later decide to re-enroll, Oracle will impose hefty penalties. Reinstatement typically requires paying all backdated support fees for the lapsed period, plus a 50% penalty. For instance, if you skipped two years of support on a $ 100,000/year contract to reinstate, Oracle could demand $ 200,000 (the missed years) plus 150% as a penalty, totaling $ 300,000 before you can resume support. This policy is designed to deter customers from dropping support to save money in the short term and returning later only when needed. The implication for CIOs is that dropping Oracle support is usually a one-way decision – you should plan to either stay off Oracle support or switch to an alternative support model for those licenses, as reverting will be cost-prohibitive.
- Support Repricing on Partial Termination: Even if you identify unused licenses and want to terminate them to save on support, Oracle may reprice your remaining support. When you reduce the number of licenses under support, Oracle often removes any volume discount that was applied to the original, larger quantity. The support fee for the remaining licenses then reverts to the list price (22% of the list cost each) with a smaller or no discount, meaning the total support bill doesn’t drop linearly with the license reduction. For example, you might drop 20% of your licenses but see only a 5% decrease in fees because your discount tier has been reduced. Oracle’s standard policy is that if you terminate licenses, the support for what remains is calculated as if those were new licenses – this is known as the repricing policy. The pitfall is that organizations expecting to save significantly by scrapping unused licenses often find that the savings are much smaller unless they negotiate an exception.
- Compliance and Audit Clauses: Oracle’s license agreements give them the right to audit your usage. A common mistake is not reading the fine print on how products can be used (e.g., virtualization limitations or using features that weren’t licensed) – which can lead to compliance gaps. Unplanned compliance issues can lead to unbudgeted purchases if an audit occurs, and sometimes Oracle will bundle an “audit resolution” with a new license deal, locking you into additional support. To avoid this, ensure your team strictly follows Oracle’s licensing rules (for example, using only Oracle-approved hard partitioning technologies if licensing by sub-capacity, etc.). Being proactive about compliance helps remove the fear of audits as a negotiation weapon.
Bottom Line:
Understanding these contractual pitfalls arms CIOs with the knowledge to avoid or negotiate around them.
Always review your Oracle contract terms (or have licensing experts do so) before changing your support coverage.
It is sometimes possible to negotiate contract amendments or get waivers (for example, negotiating away a support uplift or securing a cap on annual increases), but you must address those upfront. The next section will explore strategies for negotiating effectively with Oracle.
Negotiation Strategies with Oracle
Negotiating with Oracle for lower support fees requires careful preparation, strategic timing, and effective tactics.
Oracle is known for its rigorous sales and contract management processes, but CIOs can achieve meaningful concessions with the right strategies.
This section covers how to time your negotiations, utilize bundling or multi-year agreements to your advantage, employ specific tactics to negotiate lower fees, and strategies for handling Oracle audits to prevent them from derailing your cost optimization efforts.
Timing Contract Renewals for Leverage
When you negotiate with Oracle, it can be just as important as how. Oracle’s sales teams have quotas and revenue targets, and they may be more flexible at certain times.
A key tip is to plan renewal discussions around Oracle’s fiscal calendar. Oracle’s fiscal year ends in May, and Q4 (March to May) is typically its largest sales quarter.
This means Oracle representatives may be extra motivated to close deals before year-end.
By initiating your support renewal or license negotiations a few months ahead of that (e.g., in Q3 or early Q4 of Oracle’s year), you can leverage their push to meet targets.
Companies have succeeded by approaching Oracle near quarter-end or year-end to request better terms.
Oracle might be willing to offer a discount, a fee waiver, or other incentives to book the renewal in their critical quarter.
Another timing aspect is starting early. Don’t wait until your support contract is about to expire.
Begin talks 3-6 months before renewal (or even earlier for large contracts). Early engagement signals that you have time to consider alternatives, which increases your leverage.
It also gives you time to escalate within Oracle or seek internal approvals for any new deal structure.
They have the upper hand if Oracle knows you are up against a tight deadline. Starting negotiations well in advance allows you to play multiple options and even delay decisions if the offers aren’t satisfactory.
Bundling Strategies to Maximize Value
Consider the deal’s scope when negotiating – sometimes, bundling multiple elements can yield a better overall outcome.
Oracle’s goal is to maximize its share of your IT spending, so it might be more amenable to reducing support fees if you also invest in other Oracle products or services.
For example, bundling new license purchases or cloud services with your support renewal can create a win-win situation: you receive a discount or a freeze on support costs, and Oracle can sell additional products.
One strategy is to negotiate a multi-year renewal: if you commit to, say, three years of support upfront, you could ask for a price hold (no annual uplift) or a discounted rate.
Some organizations have negotiated multi-year support deals with a 0% increase cap for the duration, protecting them from inflation and saving money in the out-years. Oracle may consider this, as it secures your business in the long term.
Another bundling approach is the “cancellation and replacement” tactic. In some cases, Oracle might not directly cut the support price on existing licenses.
Still, they might allow you to buy new licenses (for something else) at a high discount and then cancel equivalent old licenses – effectively trading old support-heavy licenses for new ones with a lower support base.
Oracle officially doesn’t endorse swapping licenses to reduce support (“migration” programs have largely been discontinued).
Still, creative deal structures, such as purchasing new software or cloud credits, can sometimes indirectly offset support costs. The key is to work with Oracle to find a scenario where they can justify a concession.
Bundling support with cloud: If your company is considering Oracle Cloud (OCI or Oracle SaaS offerings), Oracle might be willing to be flexible on on-prem support fees to encourage cloud adoption.
For instance, Oracle has offered customers the ability to transfer on-prem support spending into cloud credits in certain programs (like Oracle Support Rewards).
While those programs are outside the scope of on-premise, they highlight that Oracle views your total spend holistically.
Use that to your advantage by discussing all your Oracle needs together rather than treating support renewal in isolation.
Expanding the negotiation beyond “support renewal” to include other transactions can create more leverage.
However, be cautious about evaluating the total cost—the goal is not to buy something unnecessary for a small support discount.
Rather, focus on investments you might already consider and see if Oracle can improve the support terms as part of a larger deal.
Tactics for Negotiating Lower Support Fees
Apart from timing and bundling, there are specific tactics CIOs have used to successfully negotiate reductions or limits on Oracle support costs:
- Leverage Alternatives: Oracle sales reps know their biggest competition for support dollars is not another vendor but the possibility that you might leave Oracle support. Subtly let Oracle know you are exploring third-party support providers or other strategies. Even if you ultimately stay with Oracle, showing that you have a credible alternative quote that could cut your support bill by 50% can be a powerful bargaining chip. Oracle might respond with a discount or one-time credit to keep you. (Be tactful with this approach; you don’t want to sour the relationship, but it’s fair to mention that you have budget pressures, and everything is on the table, including third-party support.)
- Negotiate the Annual Uplift: As discussed, Oracle typically applies a yearly increase (commonly around 3%). During negotiation, explicitly ask for a cap or waiver on support uplifts. Some customers have negotiated a freeze for 1-2 years or a reduced increase (e.g., 0% for two years or capped at 1-2% instead of 3-4%). For example, a company reduced its annual uplift rate from 8% to 3% through negotiation (8% is higher than typical, but this case shows even high uplifts can be negotiated down). Oracle might agree to no increase if you sign a longer contract or make a concession elsewhere. The result is immediate and compounding savings.
- Rightsize Your Support Scope: Use Data to Drive the Conversation. Audit your current usage of Oracle licenses before the negotiation. If you have 100 licenses but only 70 in use, you have a case to terminate 30. Even though Oracle’s repricing policy may diminish the savings, you can use this to negotiate: “We are prepared to terminate these unused licenses. We understand support on the remainder might be repriced, but perhaps you (Oracle) can allow us to drop them without repricing or give a one-time discount on the renewal.” Essentially, try to get Oracle to waive the harshest part of the policy. Sometimes, Oracle would prefer to keep you as a happy customer (paying something) rather than have you eliminate licenses – use that as leverage to seek special approval. Come with a clear list of what you don’t need; Oracle might offer a creative solution, such as converting those licenses to a different product you might use or a reduced support line item.
- Play Hardball (when needed): If support costs are unsustainable, CIOs may consider a more aggressive posture – for example, not renewing and moving to a third-party solution or consolidating Oracle systems to significantly reduce licenses. Being willing to walk away is a classic negotiation tenet (know your BATNA – Best Alternative To a Negotiated Agreement). If Oracle believes you will seriously cancel support for a substantial part of your deployment, they will likely make concessions to keep at least some of your business. Of course, this must be handled carefully and only if you have a viable plan B. Ensure that any critical systems have coverage (either through internal expertise, a third-party arrangement, or your comfort in running without Oracle support for a while).
- Use Executive Relationships: Engage Oracle at multiple levels. High support fees can sometimes be discussed in an executive-to-executive conversation (CIO to Oracle account executive or even Oracle support leadership). Framing it as a partnership issue – “We want to remain a long-term Oracle customer, but these support costs are forcing us to consider alternatives” – can prompt Oracle to find a compromise. Oracle does offer discretionary discount programs, but they often require approval from senior management. If you can persuade Oracle’s management to see the bigger picture (i.e., retaining a strategic customer), they may be more likely to approve a special discount or credit.
Throughout negotiations, avoid common pitfalls: don’t wait until the last minute (as mentioned), and ensure you fully understand your contracts.
Surprises in terms (like auto-renewals or notice periods) can undermine your strategy. Also, document everything—if Oracle verbally offers a concession, ensure it is confirmed in writing in the contract or amendment.
Exploring Third-Party Support Options
One of the most powerful strategies to reduce Oracle support fees is to consider third-party support providers. These independent companies offer support for Oracle software (and other enterprise software) as an alternative to Oracle’s support.
For on-premise Oracle products that are stable and not in need of constant updates, third-party support can slash costs while still keeping systems running smoothly.
This section provides an overview of third-party support, discusses potential cost savings versus risks, and addresses compliance considerations when transitioning off Oracle’s support.
Overview of Third-Party Oracle Support Providers
Several reputable third-party companies specialize in supporting Oracle products, ranging from databases and middleware to Oracle applications (E-Business Suite, JD Edwards, PeopleSoft, etc.).
The leading players in this market include Rimini Street, Spinnaker Support, and Support Revolution.
These providers typically offer services independent of Oracle, such as break/fix troubleshooting, tax and regulatory patches for Oracle apps, performance tuning assistance, and even security patches or workarounds.
Third-party support originated as a response to the high maintenance fees of vendors like Oracle and SAP. Gartner defines independent third-party software support as a lower-cost alternative to vendor maintenance, and many Fortune 500 companies and public sector organizations have at least evaluated this option.
Rimini Street, for example, has been in business since 2005 and supports thousands of Oracle customers worldwide.
These companies employ experts (often former Oracle engineers) who can provide support for versions of Oracle software long after Oracle has ended its official support (e.g., older releases that are now on Oracle’s “Sustaining Support” only).
Scope of Service:
Third-party support generally covers maintenance and troubleshooting. If your Oracle system encounters an issue, the third party will help diagnose and provide a fix or workaround. They also often support customizations better than Oracle (Oracle support tends to focus only on standard code issues, whereas third parties will help with issues in your custom code or integrations).
However, they do not provide Oracle’s product upgrades or new patches. They can’t give you a new database version or an official patch released by Oracle (since that’s Oracle’s intellectual property). Instead, they might deliver their fixes or guide you in configuring the system to avoid the bug.
CIOs should note that third-party support is best suited for stable environments that do not require upgrading to newer versions. Many organizations use third-party support to prolong the life of an older Oracle release. For example, staying on Oracle Database 11g or 12c beyond Oracle’s support timelines because the system works fine, and upgrading would be costly/disruptive.
Third-party providers will continue to support the product and address new regulatory requirements (for ERP systems) or security vulnerabilities via custom patches.
Cost Savings and Risk Factors
The primary driver for third-party support is cost savings. Third-party providers typically charge 50% or less of Oracle’s support fees for equivalent coverage.
For instance, if you pay Oracle $1 million annually, a provider like Spinnaker or Rimini might offer support for $500k or even less.
These savings can be immediate and substantial, freeing up hundreds of thousands or millions of dollars in IT budgets. In some cases, organizations have reported savings of up to 50% or more by moving to third-party support.
Moreover, third-party contracts often lock the annual fee without inflation, so you avoid the yearly 3% increases, compounding the savings over time.
Aside from the cost, companies often find that service quality benefits from a third party: you may receive more personalized attention, dedicated support engineers, and faster response times.
Since these providers compete on service (not being the OEM), customer service is a selling point – many clients report better support experiences and more flexibility, such as support for custom configurations that Oracle’s support would decline to assist with.
However, CIOs must weigh the risks and trade-offs:
- No Oracle Patches/Upgrades: As mentioned, you will not receive official patches, bug fixes, or version upgrades from Oracle. Suppose Oracle releases a critical security patch for a newly discovered vulnerability. In that case, your third-party provider must either create a fix or advise on mitigation, which could take some time. This can potentially leave systems vulnerable if not managed well. Third-party firms develop security updates (Rimini Street, for example, touts its security solutions for Oracle products). Still, some risk exists if a novel issue arises that only Oracle has the fix for. Many issues can be mitigated through configuration or network security, but this is particularly important for databases.
- Compliance with Oracle Contract: You must maintain proper licensing to use Oracle software legally, even if Oracle is not providing support. Switching to third-party support does not terminate your license agreement with Oracle; it just means Oracle is no longer obligated to provide support (and you stop paying them). Ensure you fully comply with licenses when switching because you don’t want Oracle to initiate an audit and claim you owe licenses. The good news is that third-party support is legal if you are a valid license holder; Oracle cannot cancel your licenses just because you left their support. There have been lawsuits (Oracle vs. third-party support firms), but those targeted the providers for how they accessed Oracle’s materials. As a customer, you’re generally within your rights to hire an outside firm for support. Caution: Do not attempt to download Oracle patches or updates via Oracle’s support site once you leave Oracle support – that would violate Oracle’s terms. The third-party provider will have their methods to support you without infringing IP (the reputable ones are careful about this post-litigation).
- Losing Future Upgrade Path: If your strategy involves upgrading to a new Oracle version in a few years, leaving Oracle support might complicate that. Oracle only allows customers to download new versions with active support. A common approach is to download any software/media you might need before your support lapses (since the licenses are perpetual, it’s lawful to use the version you had rights to). But any brand-new releases after you leave would not be legally accessible. So, many companies with third-party support plan to stay on their current version for the foreseeable future. If you eventually decide to upgrade, you might rejoin Oracle support or purchase new licenses for the new product version (costing some of the money saved). In short, third-party support is best suited if you intend to avoid major upgrades and run your existing Oracle products as is for several years.
- Oracle’s Stance and Support for New Issues: Oracle will warn you about third-party support. Oracle often claims that only they can provide the latest security patches and that third-party providers may leave you at risk of security or compliance issues. They highlight that third parties cannot fix source code issues in Oracle’s proprietary code. While there is truth in not getting official patches, third-party clients have used mitigations and custom fixes for years. It becomes a risk management question: Are you running an app that needs constant patching, or is it stable? Many older ERP or database systems may not require new patches – they’ve been working for a decade and can continue to do so. Some third-party firms even indemnify clients or provide insurance for custom security needs. Nonetheless, CIOs should conduct a thorough assessment: identify any mission-critical security or regulatory requirements and ask the third-party provider how they address these requirements.
In practice, many companies use third-party support as a temporary strategy to save costs for 3-5 years, then either invest those savings into migrating off Oracle or re-negotiate with Oracle from a stronger financial position. Others use it indefinitely for legacy systems that will eventually be retired.
Compliance Considerations and Contractual Obligations
Before switching to a third-party support vendor, it’s crucial to review contractual obligations and ensure a clean break from Oracle support:
- Notice Period: Please refer to your Oracle support contract for termination notice requirements. Oracle renewals are often annual and may auto-renew. To cancel support for a given CSI (Customer Support Identifier), you might need to give 30 or 60 days’ notice (in writing) before the renewal date. Missing this window could lock you in for another year.
- License Compliance: As mentioned, perform a thorough license review before discontinuing Oracle support. Ensure all usage is covered by licenses to avoid giving Oracle any reason to claim a breach of contract. If you find any shortfall, you could quietly purchase the needed licenses before leaving support (so that Oracle cannot use that against you later). Note that once off Oracle support, if an audit happens, Oracle can still require proof of licenses, and any non-compliance would be a separate issue from support status. Redress Compliance (a licensing advisory firm) suggests that 90-100% of compliance issues can be resolved without new purchases if addressed proactively – meaning with the right adjustments or by canceling the use of unlicensed features, etc., you can often fix compliance. Do this homework to avoid drama later.
- Contractual Access: When you leave Oracle support, you lose access to Oracle’s support portal, updates, and sometimes certain licensed perks like the right to use Oracle’s Advanced Customer Support services. Ensure you download any documentation, software, or patches to which you are entitled while you can. After support lapses, you should not download Oracle’s intellectual property (that would violate agreements).
- Third-Party Contract Terms: Carefully negotiate the contract with the third-party provider. Key things to clarify include: what happens if you need to scale up or down (can you easily add or remove coverage?), how they guarantee support levels (SLAs), and their liability in the event of an issue. Also, check if they require multi-year commitments or if they are annual. Many third-party providers are flexible to win business – you might get favorable terms like the ability to cancel with short notice, etc., but read the fine print.
- Exit Strategy: Plan your “exit” from third-party support, if applicable. For example, if you decide to migrate to the cloud or upgrade in two years and thus want Oracle’s support again, understand what that entails (likely purchasing new licenses or paying reinstatement as discussed). Some organizations negotiate with third-party providers for assistance during the transition back. While they can’t influence Oracle’s fees, they might help with the process or ensure continuity until you’re fully onto Oracle (or a new system).
In summary, third-party support can be a highly effective tool for reducing costs—often saving 50% or more on support fees with minimal downside for the right workloads. Just maintain compliance and clearly understand what you give up (Oracle updates) versus what you gain (major cost savings and often better support service for day-to-day issues).
Many CIOs use third-party support as leverage even if they don’t ultimately switch. Still, those who do switch can redirect the budget to innovation and comfortably extend the life of existing systems.
Read more about our Third Party Transition Service.
