FAQs Reducing Oracle Support Costs
How can we identify unused Oracle licenses (“shelfware”)?
- Conduct regular internal audits: Review all Oracle licenses you own and compare them to what is in use. Many companies discover they are paying support on products or features no one is using.
- Use usage tracking tools: Implement monitoring to pinpoint underused or inactive licenses. These tools (or Oracle’s usage reports) help reveal which database instances, middleware components, or application modules are idle as “shelfware”.
- Document and take action: List all licenses and modules not being utilized and flag them for potential removal or reallocation. One firm found that 20% of its Oracle licenses were inactive and saved money immediately by canceling support for those unused licenses.
- Engage stakeholders: Work with IT and finance teams to verify that certain Oracle systems or modules are truly retired. This ensures you won’t accidentally cancel something still needed, and it builds a business case for terminating support on the true shelfware.
Read about strategies for reducing Oracle support costs.
Does Oracle allow partial termination of support for some licenses?
- Oracle’s “all or nothing” policy: Oracle generally does not allow dropping support on just a subset of licenses. Their Matching Service Levels policy requires that all licenses of a given product family stay on the same support plan, so you can’t simply cancel support for a few and keep the rest.
- Repricing kicks in: If you manage to remove some licenses, Oracle will reprice the support on your remaining licenses at current list prices (losing any volume discount). In practice, the support cost for the licenses you keep will go up, wiping out most savings from dropping a few licenses.
- Effectively not permitted: Because of these rules, partial termination usually isn’t feasible or beneficial – it becomes an all-or-nothing choice for each product set. If you have 100 Oracle Database licenses under one contract, you can’t drop support on 20 without Oracle charging more for the other 80.
- Rare exceptions: Some companies have tried creative workarounds (e.g., assigning surplus licenses to a divested subsidiary and terminating that unit’s support contract), but Oracle has tightened its policies to prevent abuse of such loopholes. Generally, you are expected to keep paying support on all product licenses unless you terminate the entire set.
How can we safely remove unused Oracle options, packs, or modules?
- Identify unused add-ons: Inventory your Oracle environments (database and applications) to find extra-cost options or modules you’re paying for but not using. Common culprits are database options (Advanced Security, Partitioning, etc.) or application modules in suites like E-Business Suite or PeopleSoft that were purchased but never deployed.
- Disable them in the system: Have your technical team turn off or uninstall any unused features to prevent accidental usage. For example, if an Oracle Database option was enabled by default but not needed, ensure it’s disabled so it doesn’t trigger licensing fees.
- Remove from the support contract: Once you’ve confirmed an option or module isn’t used, formally request Oracle to remove it from your support agreement. By de-supporting that feature, you stop paying its annual maintenance fee. Make sure to get written confirmation from Oracle that it’s been removed.
- Realize the savings: Eliminating unnecessary options can significantly cut costs. For instance, one company turned off two unused Oracle Database options (Advanced Compression and Partitioning) and saved approximately $100,000 per year in support fees. Similar opportunities may exist with middleware components or ERP modules your business doesn’t utilize.
- Maintain documentation: Keep an internal record of when and why you removed a product or feature from support. This helps avoid confusion later and is useful evidence if Oracle questions the change.
When and how should we negotiate with Oracle for lower support costs?
- Pick the right timing: Align your support renewal discussions with Oracle’s sales cycles. Oracle’s fiscal year-end (May 31st) and quarter-ends are when sales reps are pressured to close deals. Engaging in negotiations just before these milestones can make Oracle more amenable to discounts or concessions to secure your renewal.
- Address the annual uplift: By default, Oracle adds about a 3–8% annual increase to support fees. You can negotiate this down or even to 0% by committing to a multi-year renewal. For example, some customers agree to a 3-year support term in exchange for no yearly increase, locking the rate in. This directly stops the compounded cost growth.
- Bundle and leverage volume: If you have multiple Oracle support contracts across databases, middleware, and applications, negotiate them together. Consolidating contracts into one renewal gives you a larger spend to bargain with, which can help ask for an overall discount or better terms. Oracle might offer a better deal on a big renewal rather than risk losing pieces of it.
- Use alternatives as leverage: Let Oracle know (tactfully) that you are exploring other options – for instance, evaluating third-party support or considering migrating workloads off Oracle. The mere possibility of losing your support business can prompt Oracle to be more flexible, typically by reducing the annual increase or offering short-term discounts. (Oracle often won’t slash the base price deeply, but they may negotiate on peripherals like the uplift or throw in extra support services.)
- Prepare a clear ask: Go into negotiations with a well-defined goal (e.g., “reduce next year’s support by 10%” or “freeze increases for two years”). Back it up with justification: budget constraints, usage reductions, or competitive quotes. Also, start the conversation early – don’t wait until a week before renewal. Early, proactive negotiation shows Oracle that you are serious about managing costs and gives you time to escalate if needed.
- Consider long-term trade-offs: In some cases, Oracle might offer a concession if you agree to something in return (like committing to a cloud transition or buying additional licenses). Weigh these offers carefully – a short-term support saving could come with new spending. As an executive, ensure any deal aligns with your broader IT strategy, not just the immediate budget fix.
What is third-party support for Oracle products, and when does it make sense to use it?
- Third-party support defined: Instead of getting support directly from Oracle, you can contract an independent provider (such as Rimini Street or Spinnaker Support) to maintain your Oracle software. They offer help with issues, bug fixes, and regulatory updates for Oracle products without you paying Oracle for annual support.
- Major cost savings: Third-party support providers typically charge significantly less. Many companies see about 50% lower annual support fees by switching to third-party support. For example, if you currently pay Oracle $1 million annually, a third party might charge around $500k for support on those same products , immediately cutting maintenance costs in half.
- Extended life for older systems: These providers will support older versions of Oracle software for as long as you need. This is a big advantage if you’re running an Oracle Database or application version that Oracle no longer fully supports or is pressuring you to upgrade. Third-party support lets you avoid forced upgrades and keep your stable systems running with ongoing fixes.
- When it makes sense: Third-party support is ideal when your Oracle environment is stable and you don’t require new features or updates from Oracle every year. Examples include Oracle E-Business Suite, PeopleSoft, or JD Edwards systems that meet your needs in their current version or database platforms that you aren’t planning to upgrade soon. In these cases, you primarily need break-fix support and legal/regulatory updates, which a third party can provide at a much lower cost.
- Considerations: Executives choose third-party support to save money and often report getting more personalized service. However, you won’t get new software patches from Oracle or direct Oracle expertise. It’s best utilized when cost reduction is a priority and the risk of not having Oracle’s team on call is acceptable. Many organizations have successfully used third-party support for years to cut costs while still keeping their Oracle systems running smoothly.
What are the risks or trade-offs if we leave Oracle’s official support?
- No access to Oracle patches and upgrades: Once you leave Oracle support (either by dropping it or moving to a third party), you lose the right to download new patches, bug fixes, and version upgrades from Oracle. Over time, this could expose you to security vulnerabilities or compatibility issues since you won’t automatically get Oracle’s security updates.
- Self-reliance for problem fixes: Without an Oracle support contract, Oracle’s support line will not assist you if something goes wrong. You must rely on your in-house IT team or a third-party support provider to troubleshoot issues. This is a trade-off: you save money but need confidence that you have the expertise (internal or external) to handle technical problems and maintain the system’s health.
- Reinstatement costs if you return: If you leave Oracle support now and later decide you need Oracle’s support again, be prepared for hefty fees. Oracle typically charges a reinstatement penalty of 150% of the last annual support fee, requiring you to pay all the back support fees for the period you were off support. In short, getting back on Oracle support can cost more than if you had never left, so the decision to leave should be a longer-term commitment.
- Potential audit and compliance concerns: Some customers worry that Oracle may pay closer attention to license compliance after they stop paying support. Oracle can audit your use of its software at any time. While going off support doesn’t violate any rules, you want to ensure you adhere to your license limits. Without an active support contract, if an audit finds you’re out of compliance, you won’t have much goodwill credit – you’d likely face full-price license fees or penalties.
- Loss of new product features: You also forego any enhancements or features Oracle releases. For example, if Oracle releases a useful new module or an improved software version, you won’t have automatic access without a support contract. You might need to purchase licenses anew or re-subscribe to support to get those down the line. This is usually acceptable if your current system meets business needs, but it’s a strategic consideration.
- Bottom line: Leaving Oracle support can yield substantial savings and work out fine for stable environments, but it comes with increased responsibility. You should have a plan for maintaining system security (e.g., doing your patches or using third-party patches), supporting the software internally or via a third party, and clearly understanding that re-engaging with Oracle later will be costly. Weigh these trade-offs carefully against the budget benefits.
How should we approach exiting an Oracle ULA (Unlimited License Agreement) or certifying at its end?
- Start planning early: Don’t wait until your ULA is about to expire. Begin your exit strategy 6–12 months before the ULA end date. Early planning gives you time to fully understand your usage, fix compliance gaps, and decide whether to certify (end the ULA) or negotiate an extension.
- Measure your current usage thoroughly: Conduct a comprehensive internal audit of all Oracle deployments covered by the ULA. Use Oracle’s measurement scripts or license management tools to collect accurate data on the number of installations, users, or processors you have in use. This is critical because at ULA’s end, you must declare your usage to Oracle for certification, and you want those numbers to be complete and correct.
- Maximize deployment under the ULA: If you’re nearing the end of an Oracle ULA, ensure you have deployed everything your business needs while still having unlimited rights. Many companies deliberately increase deployments before ULA expiry – not in a wasteful way, but to make sure all required systems are stood up so they’ll be covered in the final count. (For example, if you plan to roll out a new Oracle-based application next year, it might be wise to deploy it before the ULA expires so that its usage can be included in your certification.) This avoids underutilizing the ULA and then later having to buy new licenses that could have been free under the ULA.
- Engage experts ahead of time: ULA exits and the certification process can be complex, so it’s often worth involving a licensing specialist well in advance. Ensure you understand how to formally certify, such as what format of report or affidavit Oracle requires, the deadline for submission, etc. Sometimes negotiating the certification process (for example, agreeing on how to count certain cloud deployments) can save headaches; clarify any ambiguities with Oracle before the ULA ends.
- Certify your usage in a structured way: When the ULA period ends, you will typically provide Oracle with a certification letter that documents your usage of each included product. Approach this like an audit: have all the evidence ready to back up the numbers. Once Oracle accepts it, they will convert your deployed usage into perpetual licenses. It’s important to get confirmation of those perpetual license quantities in writing. That documentation is your protection, proving what licenses you own after the ULA.
- Plan for post-ULA license management: After exit, you’ll be on standard Oracle licenses (with support at the normal annual rate for those licenses). Make sure you budget for the support on the now-fixed number of licenses. Also, consider negotiating a favorable support rate for those licenses as part of your ULA exit talks, if possible. And, if your business might grow beyond the certified numbers soon, weigh the cost of another ULA or additional licenses versus trying to live within the certified counts. Have a forward-looking licensing plan so you don’t immediately run into a shortfall.
- Avoid last-minute surprises: One common mistake is engaging Oracle too late, which can lead to pressure to renew the ULA because you ran out of time to sort out certification. By starting early, you retain control. You can confidently certify your usage and exit, or if you need more time or more licenses, you can negotiate from a position of knowledge rather than panic.
What are common mistakes to avoid when trying to reduce Oracle support costs?
- Paying for “shelfware” indefinitely: A major mistake is not tracking usage and thus continuing to renew support on unused licenses. Always identify what you’re not using – those unused databases, middleware instances, or app modules – and remove them from support. Ignoring this is essentially donating money to Oracle for zero benefit.
- Skipping negotiation or planning: Simply accepting Oracle’s renewal quote each year without question is an error. Many organizations fail to prepare for support negotiations and end up paying the automatic 3–8% uplift annually. Avoid this by reviewing your contracts in advance, setting a negotiation strategy, and engaging Oracle with clear requests. Another aspect is timing – waiting until the last minute to address your renewal can weaken your position.
- Ignoring third-party support options: Dismissing third-party support due to fear of the unknown can be a costly oversight. Some companies stay on Oracle support out of habit and endure continual price hikes, even though a third-party provider could cut those fees by half and still meet their needs. Don’t let misconceptions (e.g., “Oracle will audit us if we leave” or “Third-party can’t handle our systems”) stop you from evaluating alternatives that might be safe and financially smart.
- Assuming you can cut licenses freely: A common pitfall is not understanding Oracle’s support policies. For instance, trying to drop 20% of your licenses and expecting a 20% cost reduction will backfire due to Oracle’s matching service level and repricing rules. Always check how Oracle’s policies will affect any reduction plan. Many have learned that you can’t partially terminate support without consequences – you must approach it strategically or not at all.
- Poor ULA exit planning: If your company has an Oracle ULA, failing to plan the exit well in advance is a mistake that can lead to panic renewals or compliance issues. Some firms underestimate how much work is needed to count deployments accurately and end up extending a ULA because they weren’t ready to certify on time. Start early and treat ULA management as a project; otherwise, you might forfeit potential savings or get locked into another expensive term.
- Buying new licenses unnecessarily: Another error is purchasing additional Oracle licenses without reviewing existing entitlements. It’s not uncommon for companies to order more licenses for a new project while simultaneously paying support on old, unused licenses in another area. This can be avoided by internal governance – always reassess your current license inventory (and any shelfware) before acquiring more. You might be able to reallocate licenses or avoid a purchase altogether.
- Overestimating achievable discounts: Don’t go into negotiations expecting Oracle to slash support costs dramatically (e.g., a 30% reduction off the top) – that rarely happens. A more realistic goal is to stop increases or get single-digit percentage breaks. Thinking you can easily negotiate huge cuts can lead to disappointment or a failed strategy. Instead, combine moderate asks (like removing the uplift or a small discount for multi-year commitment) with structural changes (like dropping unneeded products or using third-party support) to achieve significant savings.
- Not getting terms in writing: Avoid relying on verbal promises or assumptions. Oracle’s licensing and support terms can be complex and are always governed by the contract documents. If an Oracle rep offers a concession, ensure it’s written into your agreement. If you negotiate something (a waived fee, an extra discount, rights to an upgrade), double-check that the paperwork reflects it. Never assume Oracle will “do the right thing” out of goodwill – protect your organization by having all terms documented.
