Oracle ULA Post-Certification Strategy for Support Cost Management

Oracle ULA Post-Certification Strategy for Support Cost Management

Executive Summary

Exiting an Oracle Unlimited License Agreement (ULA) through certification requires a smart post-ULA strategy.

CIOs and CTOs should maximize license deployments before the ULA ends to lock in a large perpetual entitlement (creating a future license buffer), and then manage ongoing support costs, potentially by switching to independent third-party support to save 50% or more on annual fees.

This article provides an advisory roadmap for Oracle ULA post-certification success, focusing on license count maximization and maintenance cost reduction.

The ULA Post-Certification Decision

When an Oracle ULA’s term ends (typically after 3-5 years), enterprises must choose to certify and exit or renew. Assuming you plan to certify, this means conducting a final count of all Oracle deployments under the ULA.

The number of installations (e.g., processor cores running Oracle software) you report becomes your fixed perpetual license entitlement in the future.

For CIOs, the post-certification phase brings two key challenges:

• License Coverage for Future Growth: Ensuring you have enough licenses to cover current and anticipated usage (so you’re not caught short later).
• Support Cost Management: Controlling the high ongoing support fees for those licenses.

Exiting a ULA fixes your Oracle license inventory on certification day. A misstep – under-counting usage or lacking a cost plan – can expose you to compliance audits or inflated expenses later. The following sections explore maximizing your license position and minimizing support costs after ULA certification.

Maximize ULA Deployments to Build a License Buffer

A ULA grants unlimited deployment rights during its term, so it is crucial to deploy as much Oracle software as possible before the ULA expires.

The goal is to maximize your license count at certification, effectively creating a license buffer for future needs:

• Strategic Last-Minute Deployments: In the ULA’s final 6-12 months, accelerate Oracle deployments on all feasible infrastructure. For example, if you use Oracle Database or WebLogic, install and run them on any underutilized servers or VMs across the enterprise. Ensure these instances are actively running (not just installed) so they count toward your usage.
• Leverage Virtualization to Inflate Counts: Oracle’s licensing rules often count all physical cores in a virtualized cluster where Oracle runs. Use this to your advantage. Even if the workload is small, you might certify hundreds of processor licenses by deploying an Oracle instance in a large VMware or cloud cluster. Oracle may initially push back on counting virtual deployments, but they often accept them during certification if negotiated. This tactic can dramatically boost your final license tally.
• Include Cloud Environments if Allowed: Check your ULA contract’s clause on cloud deployments. If public cloud (OCI, AWS, Azure) usage is permitted, Oracle instances can also be spun up there. If cloud deployments aren’t automatically counted, consider shifting them on-premise temporarily or negotiate an amendment so you don’t miss those licenses in the count.
• Don’t Underutilize – “Use It or Lose It”: The worst outcome is deploying far fewer licenses than you paid for. Oracle ULAs are priced based on an expected usage forecast. If you certify a lower number, you’ll be stuck paying support on a higher hypothetical value than you use. For example, if you negotiated a ULA expecting 1000 processor licenses but only deployed 500, you still pay the same support fee, doubling the cost per license. Avoid this scenario by ramping up deployments to meet or exceed the forecast that your ULA pricing was based on.

Real-World Example: A global retailer negotiated a 3-year Oracle ULA for $3 million (covering unlimited Databases and Middleware). By the end of the term, they aggressively deployed Oracle across every possible server, certifying 3,000 processor licenses—an equivalent of about $15 million at list value.

Because their support costs were locked at ~$660,000 per year (22% of $3M), the company now enjoys a huge pool of licenses at a fraction of the usual cost. In contrast, a less prepared firm paid a similar $3M ULA fee but only certified 500 processors.

Both firms pay roughly the same annual support, but the second firm’s cost per license is six times higher due to under-deployment. The lesson is clear: use the ULA’s “all-you-can-eat” nature to your full advantage so you exit with a comfortable surplus of licenses.

Oracle Support Costs After Certification

Misperception: Oracle support costs will skyrocket after a ULA. In reality, they remain at the contracted level with standard annual adjustments. After certifying out of a ULA, many IT leaders worry that Oracle will recalculate their support fees based on the massive number of licenses just certified.

Fortunately, this is a myth – Oracle does not retroactively increase support costs when you exit a ULA. The annual support fee was set in your ULA contract (typically 22% of the upfront license fee you paid) and remains fixed going forward, only subject to modest annual inflation (usually 0–4% or as specified in the contract).

Whether you exit with 50 or 50,000 licenses, your support payments post-ULA stay the same as what you paid during the ULA term (aside from standard yearly index uplifts).

This predictable support structure is key to maximizing deployments: You can keep vastly more licenses without paying more for support.

However, note that once you’re out of the ULA, you are back on Oracle’s standard support program:

• You must continue paying that annual support to receive patches, upgrades, and Oracle’s technical assistance. The support fee is now effectively “in perpetuity” for those perpetual licenses.
• Oracle typically will not let you reduce support costs by dropping some certified licenses. Support is an all-or-nothing proposition – if you stop paying for a product’s support, you lose access to updates for all product licenses. There’s no partial reduction for unused licenses under Oracle’s policies.
• If possible, negotiating a support increase cap during your ULA negotiation or exit is wise. For instance, some customers seek a clause that limits annual support fee increases to a small percentage or keeps the support base tied to the initial ULA fee, even if many licenses are certified. Oracle may resist such concessions, but if you managed to certify vastly more licenses than anticipated, you already effectively lowered your per-license support cost. Just be prepared that Oracle will set your post-ULA support renewal quote equal to the last ULA support fee (plus any standard uplift).

The bottom line is that you shouldn’t fear a support cost spike after the ULA exit. If you played your cards right, you’ll be paying the same annual fee for a much larger estate of Oracle software, giving you a far better return on investment.

The main challenge is whether to continue paying Oracle for support or consider alternatives to reduce the ongoing maintenance spend.

Using Third-Party Support to Slash Maintenance Costs

Once you have certified your licenses, you can choose who supports your Oracle environment. Many enterprises, especially those focused on cost optimization, consider third-party support providers as an alternative to Oracle’s support.

Third-party support means an independent company (not Oracle) provides software maintenance, bug fixes, and technical help for your Oracle products.

This approach can cut annual support fees by 50% or more while keeping your systems running smoothly.

Vendor Support vs. Third-Party Support: independent providers can maintain Oracle systems at lower cost, but without Oracle’s direct involvement. Why switch to third-party support? The primary driver is cost savings. Oracle’s Premier Support is expensive – roughly 22% of your yearly license value.

By contrast, third-party support vendors (like Rimini Street, Spinnaker Support, and others) typically charge around 50% of Oracle’s fee for comparable support services.

For example, if you pay Oracle $1M/year, a third party might charge about $500K for support, freeing up half a million annually. Over a five-year period, the savings can be in the millions, which CFOs love to redirect to innovation or other IT projects.

Key considerations and benefits of third-party support:

• Cost Savings and Budget Relief: Companies report a 50 %+ reduction in support costs when they move off Oracle support. This money can be reallocated to digital transformation, cloud initiatives, or simply to relieve budget pressure. A real-world case study noted a European firm that saved over €10M in five years by switching its Oracle databases to third-party support.
• No Forced Upgrades: Third-party providers will support your current software versions indefinitely, even if Oracle de-supports them. You won’t be pressured into costly upgrades or migrations just to stay “supported.” This is ideal if your Oracle systems are stable and meeting business needs on older versions – you can run them for as long as you want without Oracle pushing for an upgrade cycle.
• Personalized Service Levels: Independent support vendors often provide more flexible and responsive service. You can negotiate custom SLAs – for example, 24/7 support or 30-minute critical issue response, support for custom code, etc., which might be hard or costly to get from Oracle. Third-party support teams often assign dedicated engineers who become familiar with your environment, providing a high-touch support experience.
• Support for Broad Oracle Stack: Reputable third-party firms cover databases, middleware, and Oracle applications (E-Business Suite, PeopleSoft, JD Edwards, etc.). This means you can consolidate support for multiple Oracle products under one vendor, often at a discount. They handle routine break-fix support, troubleshooting, and even create custom patches or workarounds for bugs (since they don’t have Oracle source code, they reverse-engineer solutions or provide scripts to fix issues). For security vulnerabilities, they’ll suggest mitigations since they cannot deliver Oracle’s official patches, but they work to keep you secure via configuration changes or custom fixes.

Of course, there are trade-offs to weigh:

• No New Oracle Patches or Features: When you leave Oracle’s support, you lose access to Oracle’s official updates, patches, and product upgrades. Third-party support will keep your existing system stable and can address many issues, but it cannot give you new software versions or proprietary patches from Oracle. If a brand-new critical vulnerability in Oracle Database is discovered, an independent support provider can mitigate it but not provide Oracle’s own patch. Organizations must be comfortable running without Oracle’s updates (or plan to self-manage critical patches via workarounds).
• Compliance and License Management is On You: Oracle’s own support occasionally guides on staying compliant (and Oracle won’t audit you while you’re a support-paying customer in good standing, generally). With third-party support, you have no contractual relationship with Oracle anymore, which means Oracle could audit your deployment to ensure you’re not using more licenses than you are certified for. You must ensure you do not exceed your certified license counts or use Oracle programs to which you’re not entitled. Third-party vendors do not take on license compliance responsibility – they assume you’re properly licensed. Before switching, perform an independent license review to ensure everything you plan to use is fully licensed to avoid audit penalties.
• Mission-Critical Risk: In highly critical systems, some companies feel more secure knowing they can escalate issues directly to Oracle (since Oracle has the source code and deepest expertise). With third-party support, Oracle’s engineers are not on call – if a severe issue arises that the third-party cannot fix, the fallback would be to recontract with Oracle (often at a premium) in an emergency. This scenario is rare, but it’s a risk to consider. Many CIOs mitigate it by thoroughly evaluating the third party’s track record and perhaps keeping a small subset of systems on Oracle support if they are ultra-sensitive.

Comparing Oracle vs. Third-Party Support:

In summary, third-party support can dramatically lower costs and is a viable option if your Oracle environment is steady, you don’t need immediate upgrades, and you have a good handle on license compliance. Many CIOs pursue this path after certifying out of a ULA to harvest savings.

On the other hand, if you plan to continue using Oracle’s latest features heavily or foresee needing Oracle’s direct development support, you might stick with Oracle’s support despite the cost.

Some organizations even adopt a hybrid approach – keeping Oracle support for mission-critical systems they plan to upgrade, while moving mature, stable systems to third-party maintenance to save money.

Post-Certification Compliance and Audit Considerations

Exiting the ULA and owning a big pile of perpetual licenses is empowering, but it also means normal compliance rules return.

During your ULA, Oracle could not audit you for using in-scope products, but now that you’re certified, you possess a finite number of licenses and must stay within those bounds.

CIOs should immediately instill strong software asset management practices post-certification:

• Document Your Entitlements: Ensure you have official confirmation of the certified license counts from Oracle. This certification letter is your new “proof of license.” Distribute these entitlements internally to all relevant IT teams so they know the limits.
• Monitor Usage Against License Counts: Implement monitoring to track Oracle software deployment across all environments (including cloud, if applicable). If you start consuming more than the certified number of processors or users, stop – you’ll either need to purchase additional licenses or re-enter a new ULA, or you’ll be in violation. Creating a license buffer accommodates growth; use that buffer wisely and don’t exceed it unintentionally.
• Keep Evidence of Deployments at Certification: It’s smart to archive the data collected during the ULA certification process (server lists, processor core counts, user counts, etc.). If Oracle questions your counts later or initiates an audit, you can demonstrate exactly how you arrived at the certified numbers. This helps avoid any dispute if Oracle thinks you under-reported.
• Be Audit-Ready: Now that you’re off ULA, Oracle License Management Services (LMS) can audit your company again. Audits are even more likely if you switch to third-party support (since Oracle knows you’re trying to save costs). Ensure you have internal or external licensing experts periodically double-checking compliance. Perform self-audits on Oracle usage every 6-12 months and immediately address any over-deployment (either by allocating unused licenses from your buffer or withdrawing the excess deployment).
• Plan for the Future: If your business grows beyond the license buffer you obtained, plan your next move well in advance. If needed, you could negotiate a small license purchase or another ULA, but you want to avoid a last-minute scramble where Oracle has all the leverage. With sufficient buffer and good planning, some companies avoid buying new Oracle licenses for years after a ULA.

Staying compliant protects you from hefty penalties and preserves the value of your investment in the ULA. It also ensures that the cost-saving strategies (license maximization and support reduction) truly pay off without backfiring via an audit.

Recommendations

Practical Steps for CIOs and CTOs post-ULA:

• Start Early—Begin planning your ULA exit 6-12 months in advance. Inventory all Oracle deployments and identify opportunities to expand usage meaningfully.
• Maximize Deployments—Aggressively deploy on all possible systems before the ULA ends. Utilize virtualization and large hardware to boost your processor count, ensuring you certify a high license count that meets future needs.
• Verify Everything—Use Oracle’s audit scripts or license management tools to gather precise data on usage. Correctly count every instance of ULA-covered software to avoid under-certifying. It’s better to slightly overcount (including spares and disaster recovery servers where allowed) than to undercount and be short later.
• Negotiate Terms if Possible – If you’re still in discussions, try negotiating favorable exit terms (e.g., cloud usage rights, a cap on support increase, and clarity on how license metrics will be counted). Ensure any ambiguity is resolved in writing now rather than argued during certification.
• Budget for Support—Plan your IT budget assuming Oracle’s annual support will continue at the ULA rate (plus inflation). If you do it right, there will be no surprise increase but also no decrease. If that support number is too high, evaluate alternatives.
• Evaluate Third-Party Support – Analyze the trade-offs of dropping Oracle support in favor of a third-party provider. If your systems are stable and you can tolerate not getting the newest updates, obtaining a quote from third-party support can reveal huge savings. Many organizations run an RFP to compare staying with Oracle vs. switching.
• Ensure License Compliance – Upon exit, implement strict compliance governance. Train your teams that unlimited deployment is over – any new installation now must be within entitlement limits. Keep a cushion of “shelf” licenses for growth, and track usage closely.
• Consider a Hybrid Approach—You don’t have to choose a single support strategy for all Oracle products. Segment your portfolio: perhaps keep Oracle support for critical databases you’ll upgrade, but move older, steady applications to third-party support. Tailor the plan to each system’s business role and upgrade roadmap.
• Use Saved Costs Wisely—If you do cut costs via third-party support or avoid new licenses, channel those savings into modernization. For example, fund an Oracle-to-PostgreSQL migration pilot or invest in cloud services. This reduces future dependence on Oracle and validates that the cost-saving strategy fuels innovation.
• Consult Experts if Needed – Oracle licensing and contracts are complex. Don’t hesitate to bring in independent licensing advisors or spend analysts to help with the ULA exit process. They can identify hidden compliance gaps, negotiate with Oracle on your behalf, and ensure you maximize value (and avoid costly mistakes).

FAQ

Q1: What does it mean to “certify” an Oracle ULA?
A1: Certification is the process at the end of a ULA where you report to Oracle how many licenses you have deployed. That number becomes your fixed perpetual license entitlement going forward. Essentially, based on what was deployed during the ULA term, you’re locking in the quantity of each Oracle product that you can legally use after the ULA ends.

Q2: How can we maximize our Oracle license entitlements before the ULA ends?
A2: Begin planning several months in advance. Deploy Oracle software on every server or environment where it could be useful (or potentially needed in the future). Use virtualization to your advantage to count as many processors as possible. Ensure the software is running so it counts. The more installations you have at certification, the more licenses you get – all for the same fixed ULA cost.

Q3: Will Oracle increase our support fees after we exit the ULA with many licenses?
A3: Oracle will not raise your support fees because you have certified many licenses. The support fee is determined by your original contract (usually calculated as 22% of the upfront ULA price) and remains the same after exit, aside from standard yearly increases. If you certify far more licenses than anticipated, you’re effectively getting a great deal – more licenses but paying the same support, which means a lower cost per license.

Q4: What is a “license buffer,” and why do we need one?
A4: A license buffer is an extra cushion of license capacity that you won’t immediately use but expect to need in the future. Maximizing deployments during the ULA creates a buffer of certified licenses beyond current usage. This protects you against growth or new projects – you can expand Oracle usage later without buying more licenses or risking non-compliance. It’s essentially future-proofing your Oracle estate.

Q5: Can we drop some of our Oracle support to save costs now that we have many licenses?
A5: Oracle’s policy doesn’t allow you to easily cherry-pick licenses for support reductions. If you stop paying for a product, technically, you lose support for all product licenses. You’d also forfeit the right to update those licenses. Oracle expects you to continue paying the same support fee for many certified licenses. The practical option to save costs on support is to consider third-party support instead of Oracle, rather than trying to only support a subset of licenses through Oracle.

Q6: What is third-party support, and is it legal for Oracle products?
A6: Third-party support means hiring an independent firm (not Oracle) to support and maintain your Oracle software. It’s perfectly legal as long as you adhere to your license terms. You still own your licenses; you’re just outsourcing support. Court cases (like Oracle vs. Rimini Street) have confirmed that customers can use third-party support. Just ensure the provider doesn’t use Oracle’s intellectual property beyond what your license allows. Reputable third-party providers operate within legal boundaries.

Q7: How much money can third-party support save us, and what’s the catch?
A7: Typically, third-party support can cut your annual maintenance costs by 50% or more. For example, if you pay Oracle $2M/year now, a third-party might charge around $1M for equivalent support services. The trade-offs are that you won’t get new updates or upgrades from Oracle, and need to be comfortable running on existing software versions. Also, you must manage license compliance and any potential security patch needs largely independently (with the third party’s help for workarounds).

Q8: Should we consider renewing the ULA instead of certifying?
A8: Renewing a ULA might make sense if your organization anticipates explosive growth in Oracle usage that a fixed license pool couldn’t cover, or if you prefer the simplicity of unlimited usage for a bit longer (perhaps while migrating systems). However, renewing means paying Oracle another large sum and continuing the 22% support on that new sum, with no ownership if you keep renewing. If you already have plenty of licenses (or are trying to cut costs), certifying and exiting is often the better move. It gives you ownership of licenses and the ability to drop Oracle support if desired. Always weigh the cost of renewal versus the value of the additional usage you expect.

Q9: What if we need more Oracle licenses after we’ve certified and exited the ULA?
A9: If you exhaust your certified licenses (i.e., your usage grows beyond what you locked in), you have a few options. Ideally, you planned a buffer so this doesn’t happen for a while. But if it does, you could negotiate a normal license purchase from Oracle for the extra needed licenses (which could be expensive), or consider signing a new ULA for a few years if more growth is coming. Another creative approach is to optimize your current deployment – are all those certified licenses actually in use? If not, repurpose them to the growth areas (since licenses are typically transferable within the company). Important: Do not exceed your entitlement without a plan – that will put you out of compliance and open to an audit finding. It’s better to proactively talk to Oracle (or get expert negotiators) to arrange additional licenses or another ULA before you go over.

Q10: Who are the main third-party support providers, and how do we switch to them?
A10: Some well-known third-party Oracle support providers include Rimini Street, Spinnaker Support, and Support Revolution, among others. To switch, you generally wait until your current Oracle support period is about to expire (e.g., end of your annual support term). You give Oracle notice that you will not renew support for those licenses. Then you sign a contract with the third-party provider to begin support immediately after Oracle’s support ends, so there’s no gap in coverage. Before doing this, it’s critical to ensure you have the necessary Oracle software downloads, documentation, and any last patches you want, since you won’t be able to download these from Oracle once support is terminated. Engage with the third-party vendor a few months ahead to plan a smooth transition, and have your internal team or an advisor do a license compliance check. Once switched, inform your stakeholders that Oracle will no longer provide support – all tickets go to the new provider. Oracle may reach out to confirm your cancellation and offer discounts to retain you – that’s something you can factor in. Still, if cost savings is the priority, third-party support is usually hard to beat.

Contact our Oracle Licensing Consulting Team

Please enable JavaScript in your browser to complete this form.

Name *

First

Last

Email *

Company

Message *

Submit