Oracle Unlimited License Agreements (Oracle ULA)

Q: What are the most common mistakes companies make with Oracle ULA?

Companies often do not over-deploy Oracle software. The support fees are fixed regardless of whether you certify 50 processors or 50,000. Secondly, every organization is non-compliant and has mistakenly used non-ULA software.

Q: Where can I find information on the certification process?

The certification process is described in the certification clause of your agreement, also known as the ordering document. This clause outlines the requirements for reporting your exit numbers, sharing data with Oracle, and cooperating with the Oracle audit team during the exit phase.

Q: Will my support costs increase once I exit my ULA?

No, support costs will not increase after you have been certified. However, running older versions of Oracle software may result in additional costs for extended support and a 4-8% year-over-year increase in technical support fees.

Q: How does ULA certification work with cloud deployments?

Older ULA agreements did not allow for counting deployments in a public cloud. However, newer deals have a standard clause allowing calculating an average deployment over 12 months. Planning and managing your contract is essential to avoid any risks with this clause.

Q: Can I deploy Oracle on VMware while in a ULA?

Yes, deploying Oracle on VMware allows you to count all physical hosts in virtual environments, maximizing your ULA. The best practice is to deploy ULA software on VMware and then calculate all clusters toward your exit number.

Q: Is deploying Oracle on VMware the best way to maximize my ULA?

Yes, it is a recommended strategy to maximize your ULA

Q: Will Oracle be upset if we exit our ULA with 5000-15000 processor licenses?

Oracle may have difficulty explaining the numbers to upper management, but this is not the customer's concern. Standing your ground and declaring all physical hosts in virtual environments is essential.

Q: Can we negotiate to add more products to our ULA contract without a full renewal?

Yes, you can add additional products to your active ULA contract. However, you must be strategic about which products to add, as sharing too much information with Oracle can increase ULA pricing.

Q: How can I minimize financial risk during the ULA certification process?

One way to minimize financial risk is to perform an independent Oracle license audit 6-9 months before the agreement expires. This will allow you to review your current deployments and remove license compliance risks. In the last months, you have maximized your agreement by deploying more ULA software before the certification begins.

Q: How can I use my existing SAM tooling during the certification process?

We recommend only using it for discovery purposes; all verified SAM tools are only 90% accurate. The 10% where they are wrong equals millions in software risk.

An Oracle ULA (Oracle Unlimited License Agreement) is:

A contractual agreement allowing unlimited licenses for specific Oracle products.
Involves a one-time fee for a fixed period, usually three years.
Enables unlimited deployment rights for a subset of Oracle products.
Requires no reporting until the agreement expires.
Includes a process for renewal or certification before expiration.
Support costs remain constant regardless of certification quantities.

Additional resources:

We have a blog post dealing with Oracle ULA Certification.
Is your Oracle ULA expiring in 2025? Read our quick five-step guide to certification.
Request our Oracle ULA white paper, which explains the four major risks with Oracle ULAs.

Read our Oracle ULA case study where we saved a global professional services company 7m USD in renewal fees.

Table of Contents

What is an Oracle ULA?

An Oracle Unlimited License Agreement (ULA) is a contract with Oracle that grants an organization the right to deploy an unlimited quantity of specific Oracle software products for a fixed period, typically around three years.

During the ULA term, the customer can install as many instances of the covered products as needed without counting individual licenses, a major difference from traditional per-license or per-processor Oracle licensing.

In a traditional license model, a company must purchase a set number of licenses (often based on CPU cores or users) and remain compliant with those limits. In contrast, a ULA offers a one-time, up-front license fee for unlimited use of specified products during the term.

This model is designed to support enterprises that expect significant growth in Oracle usage or have variable demand by providing cost predictability and deployment flexibility in the short term.

At the end of the ULA period, the agreement doesn’t simply continue indefinitely – it requires a certification process. During certification, the customer reports to Oracle how many deployments of the covered products exist, and those counts become the number of perpetual licenses the company retains going forward.

In essence, the ULA is an “all-you-can-eat” license for the term, after which you lock in the quantity in use as your perpetual entitlement. ULAs are not automatically all-encompassing; they apply only to the products specifically listed in the contract and for the defined duration.

A common misconception is that a ULA covers any Oracle software. ULAs grant “unlimited” rights within defined boundaries—limited to certain product titles, certain legal entities, and the contract timeframe.

For example, an Oracle ULA might allow unlimited use of Oracle Database Enterprise Edition and a few options. However, it would not cover other products like Oracle CRM unless they were explicitly included.

Some ULAs even set caps on particular options or features (e.g., a ULA could limit core database usage but cap a specific option like Advanced Security for a certain number of users).

Oracle ULA – How does it work?

Understanding how an Oracle ULA works is key to utilizing it effectively and avoiding common pitfalls. (Also read our Oracle ULA FAQ on the topic)

Here’s how an Oracle ULA operates:

Key Features of an Oracle ULA

One-Time License Fee for Unlimited Deployment: The Oracle ULA agreement involves a one-time license fee that gives the organization unlimited deployment rights for a subset of Oracle products. This period is typically three years but can range from one to five years, depending on the agreed-upon terms. During this time, the organization can freely use the specified Oracle products without worrying about licensing limits.
No Reporting Requirements During the Agreement: One major advantage of a ULA is that there are no formal reporting requirements during the agreement term. Organizations are not required to provide deployment updates to Oracle until the ULA period is nearing its expiration. This simplifies license management for the organization, as it can deploy Oracle products without worrying about mid-term audits.

Options When the ULA Nears Expiration

Six months before the expiration date of the ULA, Oracle will contact the organization to determine the next steps.

At this point, there are three primary options:

Renew the ULA: If the organization finds value in the flexibility of unlimited deployments, it can choose to renew the ULA. However, the renewal terms will need to be renegotiated, which may involve adjustments in pricing or changes to the product list covered under the agreement.
Migrate to a Perpetual ULA (PULA): Alternatively, the organization can migrate to a Perpetual ULA (PULA). This option allows the organization to retain the right to use the Oracle products indefinitely without future renewals. However, the PULA has a significant upfront cost and does not provide ongoing unlimited deployment rights.
Certify the Agreement: If the organization opts not to renew, it must proceed with certification, similar to an Oracle license audit. The organization must report the number of deployments made during the ULA term. This report will determine how many perpetual licenses it retains going forward.

The Certification Process

Certification is a crucial step at the end of a ULA, and it involves the following:

Reporting Deployment Numbers: The organization must conduct a thorough self-audit to report all instances of Oracle software deployed during the ULA term. This includes gathering detailed information about all deployments, the systems involved, and the specific Oracle products used.
Oracle’s Role: Oracle reviews the reported deployment numbers and determines the number of perpetual licenses that will be granted. Once certified, these licenses become the organization’s perpetual entitlements, meaning they can be used indefinitely.

Technical Support Costs

One of the most significant benefits of the ULA certification process is the stability of technical support fees. The support costs will not increase based on the number of licenses certified, even if the organization has deployed significantly more than initially anticipated.

This means that the support fees remain fixed at the same rate as during the ULA term, which can provide financial predictability and cost benefits if the organization has maximized deployments.

Common Mistakes to Avoid

While an Oracle ULA offers considerable benefits, organizations must avoid certain common pitfalls to ensure compliance and avoid unnecessary costs:

Deploying Non-ULA Software: A common mistake companies make is deploying Oracle products that the ULA does not cover. Since the ULA only applies to the specific products listed in the agreement, deploying other Oracle software could lead to compliance issues during certification.
- Compliance Issues: If Oracle finds that non-ULA software has been deployed, the organization could be forced to renew the ULA rather than certify it, often at a higher cost. It is crucial to strictly manage which products are deployed during the ULA term.
Failing to Maximize Deployment: Another mistake is underutilizing the unlimited deployment rights. The value of a ULA is best realized when the organization maximizes the deployment of covered products, ensuring the highest possible number of perpetual licenses at the end of the term. Failing to fully deploy the covered products can result in fewer licenses than the organization could have otherwise retained.

Read how to manage Oracle ULAs.

Oracle ULA Pros and Cons

Oracle ULAs come with notable advantages and disadvantages that enterprises must weigh carefully.

Below is an overview of the key pros and cons, followed by a comparison table:

Pros (Advantages):

Cost Predictability: A ULA locks in a fixed up-front license cost (plus a fixed annual support fee) for the term, making budgeting easier. No matter how much you deploy, your costs during the ULA period remain the same. This predictability can protect against the surprise expenses of buying additional licenses mid-project.
Unlimited Deployment Flexibility: ULAs allow the unrestricted deployment of the covered Oracle products across the organization without separate purchase orders or approvals for each installation. This means teams can quickly build new Oracle-based systems, scale out applications, or expand into new geographies without worrying about exceeding license counts. It’s especially useful for rapidly growing businesses or those undertaking big IT initiatives.
Reduced Audit/Compliance Risk (for Included Products): During the ULA term, the fear of an Oracle license audit for the specified products is essentially off the table, as you’re contractually allowed unlimited use. Companies don’t need to constantly track the usage of those products against entitlements, which lowers the compliance burden and risk of penalties (as long as they stay within the ULA’s scope).
Simplified License Management: With a ULA, many prior separate license agreements can be consolidated into one. Instead of juggling multiple contracts, you deal with a single expiration date and a unified support renewal. This can simplify management and potentially streamline support negotiations.
Support Cost Stability: The annual support fee in a ULA is typically fixed (often based on your pre-ULA support spend) and does not increase even if you deploy many more licenses during the termr. For example, if you certify a much higher usage at the end, your support costs remain at the agreed level, yielding a better support-per-license ratior. Additionally, Oracle offers programs like Support Rewards (for Oracle Cloud usage) that can reduce support costs by a certain percentage when you leverage Oracle Cloud services with your ULA.
Agility for IT Initiatives: Organizations can be more agile because licensing is no longer a bottleneck during the ULA. Projects that require spinning up numerous Oracle databases or middleware instances (such as new applications, testing environments, or expansions) can proceed faster. There’s no need to delay procuring extra licenses, which can be a boon for time-to-market.

Cons (Downsides):

Vendor Lock-In: A ULA is a long-term commitment to Oracle technology. Once signed, the company is tied to paying Oracle’s support for the duration and potentially beyond (since the deployed software becomes mission-critical). This can make it difficult to pivot away from Oracle products; if your strategy changes (e.g., a move to open-source databases), you still owe the fixed costs for the ULA term.
High Upfront and Ongoing Costs: While a ULA can save money if you deploy a lot, it often requires a substantial one-time fee and a significant support commitment. In many cases, Oracle uses ULAs to increase customer support spending. For example, Oracle might calculate the ULA price at roughly 50–70% of what your license compliance gap would have cost, but require you to roll your existing support into one stream that ends up doubling your annual support payments in the future. You may overpay significantly if your actual usage doesn’t grow as expected.
Not Truly “Unlimited”: The “unlimited” rights only apply to the products and entities specified in the contract. Deploying anything outside those bounds (e.g., a different Oracle product not in the ULA or used by a subsidiary not named in the agreement) is not covered and can trigger compliance issues. This false sense of unlimited freedom can be dangerous if companies accidentally install non-included options or software.
Complex Exit (Certification) Process: At the end of the ULA, the customer must go through a certification audit to count all deployments. This can be complex and resource-intensive – companies must have accurate deployment data and coordinate with Oracle’s auditors. If mistakes are made or deployments are missed in tracking, the company could be under-licensed after the ULA, leading to hefty fees or a forced renewal. In other words, the compliance risk is deferred, not eliminated – it reappears at ULA’s end if not managed well.
Potential for Wasted Spend: If the business circumstances change (growth slows, projects get canceled, or there is a divestiture), a ULA can become “too much license.” You cannot scale down the costs if you use far less than anticipated. The support fees are fixed at a high-water mark, so even if you no longer need a product, you keep paying for it throughout the term. Many companies have found themselves stuck with an unnecessarily high support bill after a ULA, without the flexibility to reduce it due to the contract’s terms.
Limited Flexibility for New Needs: If new Oracle products not in your ULA are needed mid-term, you must either purchase them separately (defeating the “unlimited” idea) or negotiate an amendment. Similarly, ULAs typically don’t automatically cover new acquisitions or newly formed subsidiaries unless explicitly negotiated, which can limit agility in corporate changes (more on that in limitations).

Read Top 10 Questions To Ask Before Entering an Oracle ULA.

Oracle ULA – Pros vs. Cons Comparison:

Pros (ULA Advantages)	Cons (ULA Disadvantages)
Unlimited Deployments: No counting licenses during the term.	Lock-In: Long-term commitment to Oracle; hard to pivot technologies.
High Cost of Underutilized: Pay big fees even if usage doesn’t grow.	High Cost if Underutilized: Pay big fees even if usage doesn’t grow.
Unlimited Deployments: No counting of licenses during the term.	No Audit Worries (In-Scope): Compliance assured for included products during the term.
No Audit Worries (In-Scope): Compliance is assured for included products during the term.	Scope Boundaries: Only covers specified products/entities – anything outside triggers compliance issues.
Flexible Scaling: Enable rapid growth and easy spin-up of new instances.	Can’t Reduce Support: Locked into fixed support payments even if needs drop.

The Key Contract Terms of an Oracle ULA

When entering an Oracle ULA, it’s critical to understand the contractual terms and conditions that define the agreement’s scope.

Key terms include:

Term Duration: ULAs are time-limited. The contract will specify a term (often 3 years, though it can range from 1 to 5 years) during which the unlimited deployment rights apply. After this term, the ULA ends and triggers the certification process. It’s important to align the term with your business roadmap – too short might not cover your growth, and too long could lock you in beyond your needs.
Product Scope: The ULA contract explicitly lists which Oracle products (and sometimes specific product versions or options) are covered under the unlimited use rights. Any Oracle software that is not listed is not included. If you deploy a product outside the scope, you’ll be out of compliance despite being “in a ULA”. A major pitfall is assuming the ULA covers everything; it is only “unlimited” for the named products. Core products (like Oracle Database, WebLogic, etc.) are often included, but certain add-ons or less common products might be excluded or capped. Always review the list carefully and ensure it covers all the Oracle software you plan to use extensively.
Geographical/Territory Scope: The contract may include a clause defining the territory or geographic scope in which the ULA applies. Ideally, a global company will negotiate worldwide usage rights. If the ULA’s territory is limited (say, “North America” or specific countries), deploying the software in a data center or cloud region outside that territory would breach the agreement. For example, if a server is moved to a European data center that is not covered by the ULA, that deployment might need separate licensing. It’s a common oversight to miss this – companies should negotiate global rights if there’s any chance of international use.
Customer Definition (Entities Covered): Oracle ULAs typically contain a “customer definition” listing the legal entities (company, subsidiaries, affiliates) that can make use of the ULA licenses. Only those named entities can legally deploy the software under the ULA. If your company acquires a new subsidiary or if there is a merger, that new entity is not automatically covered unless the contract allows adding entities. A pitfall here is failing to include all relevant subsidiaries at the start or not securing a clause to add newly acquired companies. Without that, you might need Oracle’s approval or a contract amendment to extend ULA rights to a new entity.
Certification Requirements: The contract will outline how the end-of-term certification works. This usually includes obligations like providing Oracle with a formal certification letter declaring the number of deployments of each product, possibly within a certain time frame (e.g., within 30 days of ULA expiration). It may also specify cooperation with Oracle’s audit team – in essence, Oracle often treats certification like an audit, where you run Oracle’s measurement tools and report the data. Understanding this clause is vital: it tells you what evidence Oracle can request and how the process will unfold when you exit the ULA.
Support Fees and Merger of Existing Licenses: When signing a ULA, Oracle typically consolidates your existing license support contracts into the ULA. All previous licenses that the ULA covers merge, and you start paying a single support fee (often equal to your total support at the time or with an uplift) . This support fee remains due annually. A key term to watch is what happens to that support fee after the ULA. Some contracts fix the support during the term and then allow Oracle’s standard support inflation (for example, an 8% increase per year) after certification. Also, ensure you understand if any support increase is baked in each year of the ULA or if it stays flat during the term.
Product Cap Exceptions: Even though ULAs are “unlimited,” some contracts include specific limits for certain products or options. For instance, an agreement might allow unlimited Oracle Database deployments but cap something like Oracle Real Application Clusters (RAC) to certain licenses. These nuances should be negotiated and documented to avoid surprises. Any products capped or treated differently should be highlighted in the ordering document.
Cancellation and Renewal Terms: ULAs are generally non-cancellable – once you’re in, you cannot terminate early except under extreme conditions (like Oracle’s breach) that are usually not invoked. However, the contract might outline the process if you wish to renew the ULA at the end of the term or the notice period required to inform Oracle of your intent not to renew. Some ULAs auto-renew to a standard license list if you don’t certify or renew explicitly, which could be disastrous, so ensure the contract is clear on what happens if you take no action at expiration (usually, you’d lose rights to anything not certified).
Cloud Usage Rights: Modern ULAs often address whether cloud deployments (e.g., running Oracle on AWS/Azure) count under the ULA. Many older agreements did not allow those in the final certification to be counted, excluding public cloud usage. Newer ULAs might include language that allows it, albeit with conditions (see the section on cloud). If you plan to use cloud infrastructure, negotiating explicit rights for public cloud deployments in the ULA contract is a crucial term to include.

Negotiation pitfalls:

When negotiating a ULA, companies should be cautious of a few common pitfalls. One is not including all needed products – if you leave out a product you later deploy, you’ll face licensing trouble (for example, a company might sign a ULA for databases but forget a needed option like Diagnostics Pack, then inadvertently install it – such use isn’t covered and will be chargeable).

Another pitfall is insufficient territory or entity scope, as mentioned above, which can leave parts of your organization or infrastructure unlicensed.

Also, be wary of contract language regarding virtualization or certain hardware—ensure the ULA doesn’t restrict deployments to certain server types or on-premises only unless you’ve accounted for that.

It’s often wise to negotiate flexibility for mergers and acquisitions, meaning if your company grows or restructures, the ULA can accommodate that change

. Lastly, clarify the support terms: since you can’t reduce support during the ULA, some companies negotiate the ability to drop unused products at renewal, or a cap on support increases. Understanding and negotiating these terms up front can save a lot of pain later.

Read CIO Playbook: Managing Oracle Unlimited License Agreements (ULAs).

Oracle ULA Limitations

Despite the attractive “unlimited” label, Oracle ULAs have important limitations.

These constraints define where the ULA’s benefits end and where normal licensing rules resume:

Product Exclusions: A ULA only covers the specific products listed. Any Oracle product not in the agreement is excluded and would require separate licensing. For instance, if your ULA is for Oracle Database and Middleware, it won’t cover Oracle applications (like E-Business Suite or Oracle CRM) unless they are explicitly added. Deploying excluded software (even by accident) is a violation and can lead to big compliance penalties at certification. Real-world scenario: A company once assumed its ULA covered all database options and started using Oracle Advanced Security, which was not in its contract. At ULA’s end, Oracle discovered this and had to either pay for those licenses or renew the ULA to avoid a compliance issue.
“Unlimited” Applies to Production Only (in some cases): Some ULA contracts may distinguish between production and non-production environments. Generally, unlimited use is available in any environment. Still, if there were any odd restrictions (e.g., a ULA for non-production only – rare, but one must check), that would be a limitation.
Geographic Limitations: If a ULA isn’t global, using Oracle software in a different region than allowed means those deployments are not covered. For example, a multinational firm encountered this when they rolled out an Oracle-based system to a new data center overseas; it turned out their ULA’s territory clause didn’t include that country, forcing them to purchase additional licenses for those servers. The lesson: Ensure worldwide coverage or be mindful of where you deploy.
Legal Entity Restrictions: Only the legal entities in the ULA contract can leverage the unlimited rights. A real-world scenario: Company A had a ULA, then acquired Company B. Company B assumed it could use Oracle under A’s ULA and deployed several databases. At certification, Oracle pointed out those deployments weren’t under Company A’s legal entity and thus not covered, resulting in a compliance gap. The limitation is that those installations were technically unlicensed without adding Company B to the agreement (which wasn’t done initially). To avoid such issues, companies should negotiate the ability to add newly acquired entities or ensure all subsidiaries are listed upfront.
Time Limit and Post-ULA Rights: The “unlimited” nature is only during the active term. Once the ULA ends, you do not retain unlimited rights; you only keep a finite number of licenses equal to the deployment counts you certified. Any new deployment after the ULA end is not covered unless you purchase new licenses or sign another ULA. Companies must freeze or carefully manage deployments around the expiration. One limitation that companies sometimes underestimate is post-ULA compliance risk: if they continue to spin up Oracle instances after the term without realizing the ULA has ended, those new instances are unlicensed and subject to audit penalties.
Product Version or Bundle Limitations: Sometimes, the ULA might be limited to certain versions (though usually, it covers all versions available during the term) or certain bundles. For example, an Oracle Java ULA might specify only Java SE (not other editions). Or a ULA might exclude some specific feature packs. It’s important to note any such fine print.
Cloud Usage Restrictions: Historically, Oracle did not allow customers to count public cloud (e.g., AWS, Azure) deployments toward their ULA certification unless negotiated. This is a significant limitation for companies moving to the cloud. If not addressed, any Oracle software you run in AWS/Azure during the ULA might not “count” as owned licenses later (we delve into this in the next sections). This has caught many organizations: they moved workloads to AWS under a ULA, then, upon exit, found those deployments weren’t recognized, forcing them to either buy licenses for them or extend the ULA.
No Automatic Upgrades or New Products: If Oracle releases a new product or a major separate add-on during your ULA, it’s not automatically included. Similarly, your ULA doesn’t morph to cover new needs – its scope is fixed from the start. Companies sometimes find their needs evolve beyond what the ULA covers, effectively limiting the usefulness of the “unlimited” deal to their initial assumptions.
Non-Cancelable & Rigid Terms: The ULA is generally non-cancelable mid-term, a limitation if business circumstances change. For example, if a company downsizes or divests a division heavily using Oracle, it can’t reduce the ULA cost accordingly—it’s locked in for the full term. Or if it realizes a year in that it made a mistake, it’s too late—they must ride it out (unless Oracle exceptionally allows termination with hefty fees, which is uncommon).

Real-world scenarios of ULA limitations: Besides the examples already mentioned, consider a high-tech enterprise that signed a ULA expecting to grow its Oracle footprint. Instead, the market shifted, and they moved toward cloud-native databases.

By year two, they no longer needed unlimited Oracle DB but were still paying for it. The ULA’s rigidity became a hindrance and an expensive one.

Another scenario: A company, during its ULA, quietly used Oracle on a few unapproved cloud instances and in a subsidiary’s environment, thinking it wouldn’t matter.

At the exit, Oracle’s auditors identified those deployments and valued the compliance exposure at over $400 million—essentially, the cost had to be licensed separately.

The company had to scramble to purchase a small set of licenses to cover that, luckily avoiding the massive fee with minimal spending.

The takeaway is that every “unlimited” agreement has edges. If you fall over the edge (be it via geography, product scope, cloud, or entity), the consequences can be financially severe.

Read our article on the Top 10 Most Common Limitations in Oracle ULAs.

Three types of Oracle Unlimited License Agreements

Oracle offers different licensing arrangements that provide broad or unlimited usage rights.

The three main types often discussed are:

Oracle ULA (Unlimited License Agreement) – This is the standard ULA we’ve been describing: a time-limited contract (typically 2–3 years) allowing unlimited deployment of specific Oracle products during that term. Ultimately, you undergo certification to convert those deployments into perpetual licenses. It usually involves a one-time upfront fee and fixed support payments during the term. This type is strategic for organizations with expected near-term growth in Oracle usage, as it provides flexibility to scale within the term.
Oracle ELA (Enterprise License Agreement) – An ELA is not unlimited but a volume-based agreement. Under an ELA, the customer might purchase a large block of licenses (often with a processor/core cap or user count limit) at a discounted rate. It’s essentially a bulk purchase of licenses for a negotiated price, often covering a broad range of products. Still, there is a ceiling (unlike a ULA, which has no cap for included products during the term). ELAs often span multiple years, but instead of “deploy as much as you want,” you agree on a certain number of licenses upfront (with perhaps some flexibility or growth allowance). The advantage is straightforward ownership of those licenses without a certification step and typically lower cost per license via volume discount. An ELA suits organizations that can predict Oracle usage and want a better price by committing to a large purchase, but don’t necessarily need unlimited use.
Oracle PULA (Perpetual ULA) – A PULA is a Perpetual Unlimited License Agreement, meaning it grants unlimited deployment rights for specified products with no expiration on those rights. In other words, it’s as if the ULA term never ends – you pay a very high upfront cost and have unlimited use of those products indefinitely (though support fees still recur annually). There is no certification at the end because the end doesn’t come; you already own perpetual, unlimited rights. PULAs are relatively rare and extremely costly, but they make sense for some large enterprises that know they will use huge amounts of Oracle software for the foreseeable future. The trade-off is the high upfront investment and, typically, also a high ongoing support billin exchange for never worrying about licensing that product again.

Comparison of ULA vs. ELA vs. PULA: A Standard ULA is time-bound, unlimited usage – great for a growth spurt phase, but requires an exit strategy. An ELA is more like a big discount bundle – no unlimited rights, but simpler since you own the licenses outright (though if you outgrow the cap, you’d need to buy more). A PULA gives ultimate flexibility (unlimited forever), but at a premium price that only the largest Oracle customers can typically justify.

For example, if a company is rapidly expanding and isn’t sure how many Oracle databases it will need, a ULA might be ideal; if another company has stable but large Oracle needs, an ELA could secure a good price without the complexity of certification; and if a company is enormous (say a global bank) that will always use Oracle as a backbone, a PULA could be negotiated to permanently cover their usage.

When someone says “Oracle ULA,” they usually mean the standard time-limited ULA (option 1).

If unlimited isn’t necessary, Oracle sales might present an ELA as an alternative or dangle the PULA concept for customers who express a long-term commitment to Oracle.

Each type has its use case: ULAs for agility and growth, ELAs for predictability with cost savings, and PULAs for long-term, uncapped usage without future true-ups.

How much does an Oracle ULA cost?

The cost of an Oracle ULA can vary widely and is typically negotiated on a case-by-case basis. However, there are general patterns in how Oracle prices these agreements:

One-Time License Fee: A ULA usually involves a substantial one-time upfront license fee paid to Oracle. The scale of this fee depends on the scope of products and the anticipated usage. Oracle has been known to price ULAs anywhere from around $1 million to over $50 million for the largest contracts. For example, a mid-sized company’s ULA for a handful of Oracle products might be in the low single-digit millions, whereas a global enterprise’s ULA covering a broad suite could run tens of millions.
Annual Support Costs: In addition to the upfront fee, the customer pays annual support (typically 22% of the theoretical license list price of the software). When negotiating a ULA, Oracle often determines support by taking your existing support stream and adding any new products’ support. Commonly, entering a ULA increases your yearly support commitment, sometimes significantly. Example: A company paying $1M/year in support pre-ULA might, after signing the ULA, find themselves paying $2M+/year in support because all their licenses were consolidated and “uplifted”. In one observed scenario, a customer with $1M support was charged a $5M upfront ULA fee, and their new annual support became $2.1M (with typical yearly increases after the term).
Factors Influencing Price: Oracle considers several factors when setting the price. Key factors include the number of products included (more products = higher cost), the length of the ULA term (a longer term might cost more since you have unlimited rights for longer), and the customer’s current and projected usage. Oracle will often ask for your projected deployments over the ULA period (e.g., “How many databases do you expect to run in 3 years?”) and then calculate a cost, perhaps somewhat discounted from what those licenses would normally cost. They may also consider how much you’re spending on Oracle currently (license & support) as a baseline, then add to it.
Negotiation and Leverage: The listed price of Oracle software is notoriously high, and ULAs are no exception, so negotiation is crucial. Oracle might initially present a very high number and offer a big-looking discount. One strategy they use is referencing a supposed license compliance gap: “You would owe $X million if you bought all the licenses we think you need; we’ll give you a ULA for 50% of that.” As noted, House of Brick observed Oracle often proposes a fee of roughly 50–70% of the cost of the customer’s licensing shortfall (if an audit found you under-licensed by $10M, they might offer a ULA for $5M). They pair this with folding in support that often doubles your annual spending, which recoups a lot for Oracle over time.
Example Benchmark: For a large enterprise with ~100k employees running Oracle DB and middleware globally, a ULA might be $10M upfront plus $3M/year support for a 3-year term. For a smaller company using mostly Oracle Database, maybe $1M upfront + $200k/year support. These numbers can fluctuate drastically based on each deal’s context.
Support Renewal Costs: Even after the ULA term, the support fees continue if you keep using the licenses you certified. So a big aspect of cost is not just the initial price, but the long-term support liability. Oracle typically will not allow you to reduce support on the licenses you certify (since those came from the ULA). Thus, if you certify 10,000 licenses at the end, you’ll be paying support on 10,000 licenses in the future, which can be millions per year. Maximizing deployment during the ULA can improve cost-effectiveness (more licenses for the same support fee).
Pricing Model Tip: Oracle usually calculates what your deployments might look like, converts that to a list license price, and then gives a discount. It’s not unusual to see a 75%–85 % discount off the list in a ULA deal, which sounds great, but given Oracle’s list prices, it can still be a hefty sum. Providing conservative deployment forecasts to Oracle can lead to a lower quote. If you overestimate how many servers you’ll license, Oracle could base the price on that higher figure.
Range of Costs: As noted in Redress’s data, ULA deals have ranged from $1M to $ 50 M+. Smaller deals might cover one Oracle product (e.g., Oracle DB only) for a specific environment, whereas larger ones cover many products enterprise-wide. The cost is highly tailored – Oracle sales will aim to extract a fee commensurate with the “value” the customer will get (often tied to what the customer would pay if they bought incremental licenses over time).

An Oracle ULA’s cost structure is front-loaded with a big license fee and back-loaded with annual support. It’s a financial commitment that needs to be justified by the amount of Oracle software you’ll deploy.

Companies should model different scenarios (low vs. high growth) to see if the ULA’s fixed cost will pay off.

It’s also wise to involve those with Oracle pricing expertise or use benchmarks from similar companies to ensure you’re getting a fair deal. Oracle’s initial offers might have lots of room for negotiation.

Read Case Study: Oracle ULA Management and Certification for a Global Manufacturer

What happens when the Oracle ULA ends?

When an Oracle ULA’s term ends, the organization faces a critical juncture: the certification process. The unlimited deployment period is over, and the company must declare its usage to Oracle.

Here’s what happens step by step:

Counting and Certification: The customer must thoroughly count all deployments of the Oracle products covered under the ULA. You must inventory every server, VM, or environment where those products are installed and running. This is formally documented in a certification letter stating the quantities being certified to Oracle. For example, you might certify that you have 120 installations of Oracle Database Enterprise Edition, 50 of WebLogic Server, etc., as of the end date. According to Oracle’s rules, once you submit this, those counts (upon Oracle’s acceptance) become your perpetual licenses.
Oracle Audit Involvement: Practically, certification often feels like an audit. Oracle’s License Management Services (LMS) or auditors will typically get involved in validating the counts. The ULA contract usually obligates you to cooperate and provide data. Oracle may ask you to run its audit scripts across your systems to generate an official usage report. It’s not adversarial if all is well. Still, Oracle will verify that your numbers are accurate and that you haven’t included things you shouldn’t (like deployments started after the term or products not in the ULA).
Outcome – Perpetual Licenses: Once certified, Oracle will issue or acknowledge that you now have a certain number of perpetual licenses for each product, fully paid up. These licenses typically come with a unique CSI (Customer Support Identifier) for support going forward. Your unlimited rights cease, and now you simply own X licenses of each product (with the ability to continue support annually). You can use those in the future, but only for those quantities. If you need more in the future, you’d have to purchase additional licenses or sign a new ULA.
Support After ULA: After certification, you continue paying support on the licenses you end up with. The important factor is that the support cost does not increase based on the number you certify. If you started with $500k/year support during the ULA and ended up certifying a huge amount of licenses, you still pay $500k (plus a standard minor yearly uplift) for support, not more, which is a benefit. However, you also cannot decrease your support just because you might not use all those licenses actively – Oracle will insist you maintain support on all the certified licenses if you want updates and support.
Risks of Non-Compliance Post-ULA: If something is mismanaged, this is where problems surface. Suppose you accidentally deployed some Oracle product not covered by the ULA, exceeded a cap, etc. Those instances would not be licensable under the ULA, and Oracle might refuse to certify them. That leaves you with a shortfall – you’re using Oracle software and don’t have a license after the ULA. The risk here is significant: Oracle could charge you license fees and back support for those or push you to renew the ULA as a solution. Many companies in this situation feel pressured to simply renew the ULA (often at a higher cost) because buying licenses for unlicensed usage is exorbitant. For example, if you had unknowingly deployed an extra product and Oracle says, “You now owe $10M for that usage,” renewing the ULA might be offered for less than that as the “easy way out,” albeit locking you in longer.
If You Do Nothing: It’s noteworthy that doing nothing is not an option. A ULA doesn’t automatically turn into something else. If a company were to ignore the certification requirement and just keep using Oracle, they would be out of contract and in breach (no legal right to use the software beyond the term). Oracle would likely initiate an audit, which could become a serious compliance issue. Therefore, by the end of the ULA term, you must either certify or have negotiated an extension/renewal. The contract typically stipulates that failure to certify means you have zero licenses (because you didn’t record any) – a nightmare scenario to be avoided at all costs.
Certification is One-Time: The ULA agreement is concluded after you certify and get your perpetual licenses. The relationship with Oracle returns to normal license maintenance mode. Any new deployments beyond those certified numbers would require new licenses from Oracle. So companies must be very careful immediately after a ULA—sometimes, employees are used to the “free use” mindset and might continue deploying out of habit. It’s important to communicate internally that post-ULA, normal rules apply again.
Importance of Accuracy: The certification process is crucial. Companies should prepare well (months before expiration) to ensure all deployments are found and counted. If you undercount, you lose licenses you could have had (essentially leaving money on the table). If you overcount or include things that aren’t allowed, Oracle will challenge you. It’s truly a scenario where diligence pays off. Engaging a third-party Oracle’s scripts internally beforehand is a common best practice to ensure the numbers are right.

In summary, when a ULA ends, you transition from unlimited usage to a fixed set of licenses. Handle it like an audit: prepare, count everything, and resolve any discrepancies before the official certification.

If done correctly, you smoothly exit with all the licenses you need. You could face a compliance gap or an expensive renewal if done poorly.

One real-world case study showed a company that, as its ULA neared its end, discovered huge compliance risks (worth hundreds of millions).

By proactively addressing those (buying a few missing licenses and carefully counting everything), they managed a successful exit and avoided over $400M in potential costs. That underscores how high the stakes can be at the ULA’s endgame.

Read our Oracle ULA Renewal Strategies article.

How do you leave the Oracle ULA?

Leaving (or exiting) an Oracle ULA requires a well-planned certification process to ensure you comply and have all the necessary licenses.

Here are the steps and best practices for a smooth transition out of a ULA:

Start Early and Plan: Don’t wait until the last minute. Ideally, begin preparation at least 6 months before the ULA expiration. Early planning gives you time to address issues. Some experts say you should consider the exit right from the day after signing the ULA. At least half a year out, assemble a project team (IT asset managers, DBAs, etc.) and make a task timeline.
Inventory All Deployments: Conduct a comprehensive internal audit of all Oracle deployments covered by the ULA. Use Oracle’s LMS scripts or third-party tools to scan your environment for ULA productinstallations. Be thorough – include physical servers, virtual machines, containers, and cloud instances, if applicable. The goal is to create an accurate list of every instance of Oracle software running on which hardware.
Verify Scope Compliance: As you gather data, cross-check that each deployment is within the scope of the ULA (right product, within the territory, by an authorized entity, etc.). Identify any deployments of Oracle products not covered by the ULA. For example, maybe an Oracle product that wasn’t on the ULA list got installed – this is a red flag and a potential compliance issue. Similarly, check if any installations are in a location or a subsidiary that might not be included. It’s better to find these now than have Oracle find them later.
Remediate Non-Compliant Usage: If you find Oracle software usage outside the ULA’s scope (common problems include an Oracle option or pack enabled that wasn’t in the ULA or usage in a cloud/region not allowed), take action before the ULA ends. Solutions might include uninstalling or disabling that software or purchasing separate licenses. For instance, if you discovered 10 Oracle processors used in an excluded environment, you might negotiate a purchase for those or ensure they are removed. Redress Compliance advises running LMS scripts internally and having an independent expert review the results so you can fix issues before Oracle sees them.
Maximize Legitimate Usage (Optional): Some companies maximize deployments in the final months of the ULA to increase the number of licenses they’ll certify. This means that if you have capacity and genuine foreseeable needs, you might deploy additional instances of the ULA products (for example, install Oracle DB on servers that you plan to use in the future) so that they count in your final number. Be cautious: These should be real or at least justifiable deployments. Oracle may question a huge spike in the end. But as long as it’s within contract terms, it’s allowed. Remember the “365-day average” rule for cloud (discussed later) – on-prem deployments can usually be done even in the last week; cloud ones need to be out there longer to count in some contracts.
Decide Renew vs. Certify: Internally, make the strategic decision: are you exiting (certifying) or renewing the ULA? This decision should be made well in advance. If you plan to certify and exit, proceed with these steps. If you decide to renew (perhaps because you need more time or want to extend unlimited use), you’ll pivot to negotiating the renewal instead (see the renewal section). But you should still do an inventory because it will inform renewal negotiations, too.
Engage Experts if Needed: Exiting a ULA is not routine for most companies, so consider getting expert help. Oracle licensing specialists or firms can assist in interpreting your contract and advising on tricky points (like how to count certain metrics). They can also help ensure you don’t accidentally miss something. Gartner and others often recommend an independent licensing assessment before Oracle’s involvement.
Prepare Documentation: Keep detailed records of the data you gather. For every deployment, document the product name, version, the server or instance it’s on, the CPU count or other licensing metric details (like cores and whether virtualization tech is in use), and when it was first deployed. You’ll need to consolidate this information for Oracle. Also, maintain evidence for anything you plan to certify – Oracle might ask for proof that a certain number of instances exist.
Internal Review and Cleanup: Do a sanity check on your numbers. Often, companies have multiple groups cross-verify the inventory. Ensure no duplicates are counted (for example, the same server reported twice). Also, ensure that any decommissioned environment is not counted. Scrub the data so it’s clean and defensible.
Draft the Certification Letter: This is the formal letter you’ll send to Oracle (usually addressed as per the contract), stating something like: “Under the terms of our ULA, Company X hereby certifies the following quantities…” and then list each product and the quantity. Oracle likely provided a template, or at least the contract language says what to include. Be precise and include all covered products, even if the count is zero (if you ended up not using one of them, it’s good to explicitly state 0 for completeness and to potentially avoid paying support on that if you didn’t deploy it – you might try to remove it).
Engage with Oracle (90 days prior, typically): Often, the ULA will say you need to notify Oracle 30 days before the expiration of intent to certify, or Oracle will reach out to begin discussions. In practice, about 90 days out, Oracle’s account team will likely contact you to discuss renewal or certification. It’s in Oracle’s interest to offer a renewal, but if you intend to exit, let them know you will certify. Oracle usually coordinates a process where you run their scripts and provide data. Work collaboratively but carefully – only share what’s required and within the agreed scope. Some companies choose to present their numbers and negotiate any disagreements before formally finalizing the letter.
Oracle’s Audit & Acceptance: Oracle will review the certification letter and typically schedule meetings to review the results. They will raise questions about whether Oracle’s audit scripts or their analysis show different numbers or if there is any unauthorized usage. Be prepared to explain any discrepancies. For example, if Oracle says, “We see 105 installs of WebLogic, but you certified 100,” you should reconcile why (maybe five were uninstalled just before certification, etc., with evidence). Assuming everything is resolved and in order, Oracle will accept the certification. They might provide a written acknowledgment or an amended final certificate of licenses.
Aftermath – Ensure Compliance Going Forward: After exiting, ensure all teams know that unlimited rights are over. It’s wise to implement normal license tracking again immediately. The licenses you obtained now behave like regular perpetual licenses. You should also organize how you’ll handle any excess – for instance, if you end up with more licenses than you need in use, you still have to keep paying support on them unless you terminate support on some (terminating support is another decision – usually not recommended if you plan to use the software, as you’d lose updates). Some companies drop support on unused licenses to save costs after certification, which means losing Oracle’s support, which is a business decision.

Best practices summary: Plan for at least 6 months, do an internal audit, fix issues, get expert help, and communicate clearly with Oracle. By the day the ULA ends, you should have all your ducks in a row so that the certification is a formality.

One best practice highlighted by Insight is continuous tracking throughout the ULA, not just at the end. If you maintain a good record from day one, leaving the ULA won’t be a scramble; you’ll already know your usage. Moreover, decide early whether you want to renew or exit – that shapes your strategy.

If exiting, you might restrain unnecessary deployments; if renewing, you might be okay with being a bit more lax, knowing you’ll continue with unlimited. In either case, always stay within the contract’s boundaries to avoid an unwelcome surprise at the end.

Read Oracle ULA FAQs – What Are the Risks?

Three Oracle ULA Challenges when certifying

Companies commonly face a few key challenges when it comes time to certify their ULA usage and exit the agreement.

Here are three major challenges during ULA certification and how to address each:

Non-Compliance with ULA Terms: This challenge occurs if the company has deployed Oracle software that isn’t covered by the ULA (or exceeded some cap/limitation in the contract). For example, installing a database option that wasn’t included or using the software in a location/entity outside the scope. If not caught, this results in a nasty surprise during certification – Oracle will flag those deployments as unlicensed and demand remediation (licenses or another ULA). Solution: Perform a thorough internal audit before Oracle’s audit. Identify any deployments of non-ULA software and either remove them or license them separately ahead of time. Clean house so you fully comply with the contract terms by certification day. Double-check the list of ULA products and ensure nothing outside that list is running in your environment.
Insufficient Deployment Documentation: Many companies struggle with incomplete or disorganized records of where Oracle products are deployed. Suppose you cannot produce a reliable count of installations. In that case, the certification can be delayed, or worse, you might miss some and under-report (or Oracle might insist on their own data collection, which can be nerve-racking). Solution: Maintain up-to-date and accurate deployment records throughout the ULA term. Well before certification, reconcile data from different sources (CMDBs, monitoring tools, etc.) to ensure you know exactly what’s deployed. During the ULA, tracking every time you spin up a new instance of Oracle software is wise. During certification time, you can present a consolidated report confidently. If your records are lacking, invest the time to scan and rebuild the inventory (possibly using Oracle’s scripts to be sure you see what they will see).
Unclear Rights for Cloud Deployments: As more workloads move to the cloud, many ULA customers face a challenge: understanding how (or if) their cloud-based Oracle deployments count in the certification. A common “gotcha” is discovering that Oracle’s contract didn’t allow those to be counted or that the rules differ (like needing to maintain them for 12 months). This leads to confusion or compliance gaps if not handled properly. Solution: Review your ULA terms before exiting, specifically those about cloud usage. If the contract is silent or restrictive, engage Oracle or a licensing expert to clarify your rights. It may be necessary to negotiate an amendment or understand how to calculate the cloud usage (Oracle may require converting cloud vCPUs to on-prem equivalents, etc.). Ensure your cloud instances are counted correctly or adjust your strategy (for instance, if they can’t be counted, you might plan to bring them on-prem temporarily or be ready to license them separately). Essentially, don’t assume cloud deployments are covered – get confirmation and plan accordingly so that you’re not excluding big chunks of usage during certification.

Aside from these three, other certification challenges can include internal disagreements on data (e.g., different business units have different figures), last-minute pressure from Oracle’s sales team to renew instead (“Are you sure you want to certify?

We can offer a renewal deal…” which can be distracting), and timing issues (the certification process might drag on, overlapping with the expiration, which needs careful handling so you remain in good faith compliance).

Addressing the challenges: The overarching theme is preparation and clarity. Know what you have (documentation), what you’re allowed to have (contract compliance), and how to handle special cases like the cloud.

By tackling these challenges proactively, certification becomes much smoother. For example, one best practice is to simulate a certification internally a few months prior: pretend the ULA ended and see if you can confidently produce the letter. This flushes out any challenges while you still have time to fix them.

Read Oracle ULA Renewal FAQs – Money and Control.

Oracle ULA to Public Cloud

Moving Oracle workloads to the public cloud (such as AWS or Azure) under a ULA presents some unique considerations.

ULAs were traditionally designed for on-premises deployments, but many companies now run Oracle software in cloud environments.

Here’s how ULAs work in the cloud context and what to consider:

Deployment During ULA Term: Generally, during the active ULA period, you can deploy Oracle software in public clouds like AWS or Azure, treating it similarly to an on-prem deployment. Oracle cannot prevent you from using the software in the cloud under the ULA, but the critical question is whether those cloud deployments will count when it comes time to certify. The ULA contract might have specific language about cloud platforms. If cloud use is not explicitly allowed, you could use Oracle on AWS during the term without issue (since you have unlimited rights), but in the end, Oracle might say, “Those don’t count toward your perpetual licenses.”
License Metric in Cloud: Oracle’s licensing policies for the public cloud count cores differently (for example, Oracle counts two vCPUs as one processor for licensing on many cloud platforms, with some exceptions). Under a ULA, you don’t worry about that during the term – you just deploy. However, for certification, if allowed, you would need to calculate how many licenses your cloud instances represent. For instance, if you had 100 vCPUs of Oracle Database on AWS, Oracle might equate that to 50 processor licenses (assuming the 2 vCPUs = 1 processor rule). Understanding this conversion is important so that you report correctly.
Check the Contract for the Cloud Clause: Oracle has evolved its ULA contracts. Newer ULAs often include a clause that explicitly permits counting of cloud deployments at the end, sometimes with conditions (like the 12-month average rule discussed next). If your contract has this clause, you can certify cloud instances but must follow the specified method. Suppose your contract lacks such language (common in older ULAs). In that case, officially, any Oracle software deployed on third-party clouds won’t be counted in your certification unless Oracle makes an exception. This has huge implications: companies have discovered too late that a large portion of their Oracle footprint was in the cloud and wasn’t countable, meaning they’d suddenly need to license all that separately after the ULA.
Example Scenario – Allowed vs. Not Allowed: Suppose Company X has an Oracle ULA and moves many databases to AWS. Case 1: Their ULA contract allows counting cloud usage. At certification, they determine the average number of processors used in AWS over the last year (as required) and include that number in their certified licenses. They exit with licenses covering both on-prem and cloud instances. Case 2: Another company’s ULA did not allow cloud counting. They used 250 Oracle DB instances on AWS. At exit, Oracle says those 250 instances don’t count; the company would have to buy new licenses. With Oracle DB Enterprise Edition’s price, that could be $11.9 million for 250 processor’ licenses. In reality, many companies in this situation are forced to renew the ULA because they can’t afford that hit. Renewing the ULA extends the unlimited period and avoids immediate license purchases, but, of course, it comes with its own cost.
Bring Your Own License (BYOL) and Oracle Cloud: One special consideration is Oracle’s cloud (OCI). Oracle encourages ULA customers to use Oracle Cloud by allowing BYOL and offering Support Rewards (33% off support costs for OCI usage). If you move workloads to Oracle Cloud Infrastructure (OCI), you typically can count those just like on-prem (Oracle has no incentive to penalize you for using their cloud). Using OCI can reduce your support bill via credits. So if your strategy allows, leveraging Oracle’s cloud might simplify things – your ULA software on OCI is within Oracle’s ecosystem, and Oracle often treats it favorably in contracts. However, be aware that if you plan to move away from OCI later, you’ll need licenses, but during the ULA, it’s fine.
Public Cloud Considerations: If using AWS/Azure/Google Cloud:
- Monitor Usage: Track how many Oracle instances/cores you run in the cloud continuously. It might fluctuate with autoscaling, etc. You’ll likely need an average count for certification if allowed.
- Architectural Choices: Some companies, knowing the uncertainty, avoid putting too much Oracle in the public cloud under a ULA unless they have clarity. Others use cloud for ephemeral or test workloads and keep production on-prem until after certification.
- Negotiation Point: If you intend to use the public cloud heavily, negotiate it in the ULA upfront. Ensure a clause is added that those deployments count. Oracle’s standard newer clause might say something like: You can include the average deployment in the cloud over the last 12 (or 6) months. Knowing that, you might plan your cloud ramp-up accordingly.
- Cloud Provider Licensing Policies: Remember that using Oracle in someone else’s cloud sometimes requires following that provider’s rules (e.g., AWS has a document on how Oracle licensing works on AWS). Under a ULA, you have leeway, but ensure your usage aligns with Oracle’s definition of a “processor” in that environment.
Hybrid Environments: Many companies have a mix of on-prem and cloud. During the ULA, a hybrid is fine. Treat each environment accordingly at certification, but combine the counts (if allowed). A pitfall would be double-counting (like if an instance moved from on-prem to cloud and you accidentally count it twice). Good record-keeping prevents that.

ULAs and public cloud can mix, but you must know the contract terms. Always clarify your rights for AWS/Azure deployments. If the rights are not there, either avoid large cloud usage under the ULA or be prepared to address it (via negotiation or license purchase). The worst outcome is assuming it’s covered when it isn’t.

On the positive side, Oracle is increasingly aware that customers use public clouds, so recent ULA agreements have mechanisms to include those, albeit on Oracle’s terms (like the averaging rule). As long as you follow those terms, you can enjoy unlimited usage in the cloud during the term and successfully include them at exit.

Read Oracle ULA Certification FAQs

Oracle ULA and Public Cloud – 365 days average.

One specific clause that has become common in Oracle ULA contracts regarding public cloud deployments is the “365 days average” rule.

This clause affects how you can count Oracle usage in public clouds (like AWS or Azure) for ULA certification:

What the 365-Day Average Means: If your ULA includes permission to count cloud deployments, Oracle usually doesn’t let you just take a snapshot at the end of the term (because a customer could, in theory, spin up a massive number of cloud instances in the final week to inflate their count). Instead, the contract might say that the number of licenses you can certify for cloud deployments is the average number of instances (or processors) running in the cloud over the last 12 months (365 days) of the ULA. In some cases, Oracle has used a shorter averaging window, like 3 or 6 months, but 12 months is a common standard.
Implication: You can’t game the system by suddenly bursting your cloud usage at the tail end. For example, if you only ran 50 Oracle servers in AWS for most of the year and then ramped up to 200 in the last month, Oracle might calculate the average as 65 for the year, not 200. Thus, you’d only get credit for ~65 licenses from that cloud environment.
Why Oracle Does This: Oracle protects itself from customers artificially maxing out usage to claim more perpetual licenses at exit. It ensures that the certified number reflects sustained usage, presumably the licenses the customer needs.
Challenge for Customers: This introduces a planning challenge. If you plan to use Oracle in the cloud and want those licenses later, you must start and maintain those deployments early enough. To count them fully, you must maintain Oracle workloads in the cloud for at least a year (or whatever the averaging period) before the ULA ends. Those deployments won’t fully factor into the average if you only migrated to the cloud in the last few months.
Example: A company has a ULA ending in December next year and wants to move a lot of Oracle databases to AWS. If their contract has a 12-month average clause, they should ideally have those databases up and running in AWS by December of this year (one year before) so that by the time of certification, they’ve been in the cloud for 12 months. If they wait until mid-next year, the average will include zero months, which drags down the count. Perhaps Oracle might take a 3-6 month average (some contracts also mention a 3- or 6-month average window), but one should assume worst-case 12 months unless told otherwise.
Impact on Cloud Migration Planning: If you are under a ULA and considering a cloud migration, factor this clause into your timeline. You might accelerate moving to the cloud so those deployments “season” for the required time. Or, if you’re near the end and it’s too late, you might delay moving certain workloads to the cloud until after certifying (so you certify them on-prem and then move later with the perpetual licenses in hand).
Negotiating the Average Window: If you’re negotiating a new ULA and expect to use cloud a lot, you could try to negotiate a shorter or more favorable averaging period. For instance, push for a 3-month average instead of 12, so only the last quarter’s usage counts (which allows you to ramp up in that quarter). Oracle might or might not agree, but it’s worth discussing if the cloud is central to your strategy.
Monitoring the Average: You should monitor your cloud usage trend over the last year of the ULA. If the average calculation is in play, compute a running average each month to see what number you’re trending towards. This will tell you how many licenses you’d get if you were certified. You may add more cloud instances sooner if they are lower than needed.
Real-World Note: Redress Compliance noted that later versions of ULA agreements include this clause for the public cloud, and older ones don’t. They emphasize planning and managing your contract with this in mind to avoid issues. One can infer cases where companies didn’t realize the rule and ramped up usage too late, and then Oracle only gave them an average count, leaving them short.

In essence, the 365-day average rule is about seasoning your cloud deployments. To maximize your certified licenses from cloud usage, those workloads must run for most of the period considered. It prevents last-minute spikes from being counted. So, plan your cloud moves early if you want credit for them under the ULA.

For example, one company wanted to maximize its ULA by moving test and dev systems to AWS a few months before the end. Oracle informed them that only an average of six months would count due to the contract.

The company ended up renewing the ULA because it couldn’t get credit for the full burst it did; it learned it should have moved those systems a year earlier to benefit.

This highlights how this clause can impact decisions: If you can’t fully count on it, you might either advance your cloud migration timeline or reconsider the ROI of doing it under the ULA.

The bottom line is maintaining consistency in cloud deployments for at least a year if you want them counted. Avoid huge end-of-term surges, or know they won’t fully help your license count..

This requirement might slow down some cloud plans or encourage extending the ULA if you started cloud adoption late. It’s a key detail to be aware of in any ULA-to-cloud strategy.

Oracle ULA Problems and Solutions

Companies often encounter several recurring issues while managing an Oracle ULA.

Here are some of the most common problems and how to address them:

Problem: Deploying Products Not Included in the ULA. It’s surprisingly easy for an organization to accidentally use an Oracle product or feature that isn’t part of their ULA (for example, enabling a database option or a pack that wasn’t purchased). This results in a compliance issue discovered at ULA’s end, which can force a costly resolution. Solution: Strictly govern and audit your Oracle usage throughout the ULA. Maintain an accurate list of what products are covered, and educate your IT teams that they must not deploy anything outside that list without approval. Regularly run Oracle’s audit scripts internally to catch any early non-ULA product usage. If something slips through (say, a developer turned on Oracle Advanced Security unbeknownst to licensing), address it immediately – either turn it off or get it added to the ULA via a contract change or separate license purchase.
Problem: Unplanned Vendor Lock-In / Renewal Pressure. A ULA can create a trap where, by the end of the term, you feel you have no choice but to renew because of how usage has grown or because of compliance gaps. Oracle sales might apply pressure as the end approaches, highlighting how many licenses you’d need if you leave, thus nudging you toward renewal. Solution: Have a clear exit strategy from day one. Treat the ULA as a finite window and aim to be able to exit it cleanly. This means tracking deployments and ensuring you can live with the number of licenses you’ll certify. If you suspect you’ll still need unlimited use (maybe growth hasn’t slowed), plan negotiations for renewal in advance rather than being cornered at the last minute. If compliance gaps are being used as leverage by Oracle, try to solve those gaps proactively (as above) so that renewal is a choice, not a necessity.
Problem: Cost Overruns & Support Cost Creep. ULAs fix costs, but sometimes companies realize they committed to more spending than they truly needed. Or they included products they never used, but still pay support on. Oracle ULAs often bundle in products that sound nice-to-have, inflating the support bill. Solution: Optimize the ULA scope. Before signing, carefully select which products to include – don’t add products “just in case” if you’re not fairly certain of using them. Each product has a support cost attached that you’ll carry forward. If you have already signed and some products aren’t used, you might plan to remove unnecessary products during renewal to reduce costs. Also, monitor your usage versus the cost: calculate the cost per deployment over time. If you’ve deployed far less than the ULA could cover, you essentially overpaid – learn from that for future negotiations.
Problem: Territory or Entity Restrictions Causing Compliance Issues. As mentioned, if a ULA isn’t enterprise-wide globally, you could inadvertently have teams deploying Oracle in uncovered places. This often isn’t realized until an audit finds a server in a country not in the contract, requiring immediate licensing. Solution: Negotiate worldwide coverage and include all subsidiaries at the outset. If the ULA is already in place, keep track of company acquisitions or expansions – if you acquire a new company, you may need to negotiate adding them to the ULA. Don’t assume a new data center in a new country is okay under the ULA; get confirmation or amend the contract if needed. Essentially, maintain alignment between your corporate structure/footprint and the ULA’s defined “customer” and “territory.”
Problem: Oracle Audit at ULA End (and possibly during). While formal audits during a ULA term are uncommon (Oracle knows you have unlimited usage for covered products), in the end, they are effectively audits. Many companies feel unprepared for the scrutiny Oracle applies during certification, leading to panic or missteps. Solution: Perform an internal audit as a rehearsal. Before engaging with Oracle, run the same scripts and procedures Oracle would. This way, you see what they would see and can fix any discrepancies. Have all your evidence and deployment data ready. By treating the certification like an audit and preparing, you avoid surprises. Also, some recommend involving a third-party auditor (not Oracle’s, but your consultant’s) ahead of time to double-check everything.
Problem: Including Products You Don’t Use (Locks in Support). Oracle might encourage adding more products into the ULA bundle, which can be enticing (“Take these extra options, you might need them”). The downside is that you still pay support indefinitely if you don’t use it significantly. One case: a company included a suite of Oracle management packs they never deployed widely; after certification, they had to keep paying support on hundreds of licenses of those packs, wasting money. Solution: Only include products that have a clear value/use case. If you did include some that turned out unnecessary, plan to terminate or license off those at renewal or post-exit if possible. Explicitly identify underused products during renewal and negotiate their removal to drop support costs. Oracle might resist dropping support (they don’t like reducing revenue), but if you have no product deployment, you have a case to remove it.
Problem: Mergers & Acquisitions during ULA. Changes in the organization can complicate ULA usage. If you merge with another company, their Oracle usage might not be covered, or vice versa. If you spin off a division, who retains the ULA rights? These questions can be thorny and, if not handled, lead to compliance gaps for new entities or stranded licenses after separation. Solution: Proactively address M&A in the ULA contract. For acquisitions: Ensure you can add newly acquired entities’ usage into the ULA (some contracts allow a grace period to bring them in). For divestitures: Clarify if part of your certified licenses can transfer to the spun-off entity (Oracle typically doesn’t allow splitting, but you might negotiate something if known in advance). During a ULA, always inform Oracle (or at least check your rights) if a major corporate change happens so you can adjust accordingly, rather than finding out later that half of your new subsidiary’s Oracle use wasn’t licensed.
Problem: Lack of Internal Ownership and Expertise. Sometimes, no one internally “owns” the ULA management, resulting in poor tracking and strategy. The ULA runs on autopilot until it’s almost over, when panic ensues. Solution: Assign a dedicated ULA manager or team from the start. This team should be responsible for tracking deployments, educating teams about the ULA’s boundaries, and liaising with Oracle as needed. They also keep an eye on timelines – for example, reminding the business 12 months out to start prepping for exit or renewal. Invest in Oracle licensing training or outside advisory services during the term. It may seem like you don’t need license management in a ULA (since it’s unlimited), but you do – to ensure compliance and a good outcome.

In summary, many ULA issues stem from complacency or misunderstanding the contract’s limits. The solutions invariably involve active management: treat a ULA not as a license holiday but as a period requiring governance (albeit with a different focus than normal licensing).

You can avoid common pitfalls by regularly auditing, keeping scope in check, and planning for changes. ULAs can deliver great value, but only if managed with the same rigor as any other significant IT asset.

Read Oracle ULA Negotiations FAQs.

When should you start planning for the ULA Oracle exit?

It’s often said that the best time to plan your ULA exit is immediately after signing the ULA. While that might sound extreme, it underscores the importance of early preparation.

In practical terms, you should start planning well before the ULA expires – ideally, a year ahead and at least 6 months before expiration.

Recommended Timeline: Most experts recommend beginning formal exit planning about six months before the ULA end date. At that point, you should start the internal project to gather deployment data, review contract obligations, and decide on your post-ULA strategy (whether to certify and exit or negotiate a renewal).

Starting at least half a year in advance gives you ample time to react to any findings – if you discover a compliance issue or a need to adjust something, you have a window to do so before you’re in the pressure cooker of the final weeks.

For example, if your ULA expires in December, you’d want to start the process by June at the latest.

Some companies start the year with preliminary steps: 12 months out, they might begin discussions on whether the business intends to renew or exit, and do a light inventory to see where things stand. By 6 months out, they mobilize fully.

Why start early? Because the exit process (certification) itself can take a couple of months of effort, and if any negotiation or issue resolution is needed, that adds time. Also, if you decide to renew, those negotiations should ideally conclude before the term ends.

If you start only a month out, you have virtually no leverage or room for error. Oracle could then squeeze you into a renewal under less favorable terms, or you might run out of time to count properly and end up short on licenses.

Key Steps Leading Up to Certification (and when to do them):

12+ Months Before Expiry: Re-read your ULA contract. Note the end date and any notice periods (some ULAs ask you to give Oracle notice 30 or 60 days before the end if you intend to certify). Identify stakeholders involved in exit planning (IT asset management, DBAs, procurement, legal, etc.). Start forecasting your Oracle usage at exit, and if any big changes (projects, cloud moves, etc.) are expected in that timeframe.
6 Months Before Expiry: Initiate the internal audit and data collection of all Oracle deployments (as described in the earlier sections). Concurrently, internal discussions should be held on the path forward: Do we want to exit the ULA, or do we anticipate needing to renew it? Sometimes, the answer is obvious, but other times, it is not. Consider factors like expected growth, budget, changes in Oracle strategy, etc. If leaning towards renewal, you’ll want to negotiate with Oracle soon. If leaning towards exit, continue the certification prep. This is also a good time to engage an external licensing advisor if you plan to use one.
3–4 Months Before Expiry: By now, you should have a solid handle on your deployment counts and compliance status. Begin drafting the certification letter and have internal dry runs of the certification process. If you haven’t already, around 3 months out, you should inform Oracle of your plans. Oracle often reaches out in this window to discuss “what’s next.” If you plan to certify (exit), you can politely let them know and perhaps arrange the logistics for certification (like scheduling when to run LMS scripts, etc.). If you plan to renew, serious talks should be underway (Oracle will be happy to talk about renewal).
Notice Period (as per contract): Many ULAs require a formal notice of intent to certify (or not renew) about 30 days before the term ends. Mark that date and send a written notice to Oracle, if required, stating you intend to exercise the certification clause and not renew the ULA. Missing this notice could lead to complications (in some contracts, failing to notify might automatically extend support or similar).
Final Month: Execute the plan – finalize the certification letter, complete any Oracle-required measurements, and be ready to submit. Ideally, you will be polishing details by the last few weeks because all the heavy data lifting was done earlier.

The day after signing: It’s worth echoing that sentiment: as soon as a ULA begins, you should think about how to eventually get out of it. This means maintaining good deployment hygiene from day one. It’s much easier to plan an exit if, throughout the ULA, you kept records.

Many companies coast through the term and then have a fire drill at the end. A smarter approach is continuous monitoring. Some even set internal checkpoints, like annually during a ULA, to simulate how many licenses they’d have if it ended then – this keeps them prepared.

Special Cases—When to plan even earlier: Plan well in advance if your company is considering a major move (like shifting to the cloud or a merger) that could occur near the end of the ULA. For example, if you foresee an acquisition that will bring in Oracle usage one year before the ULA ends, plan how to integrate that into certification.

In conclusion, start planning early and revisit the plan often. At least 6 months’ lead time is advised, with many tasks ideally kicked off a year prior. The more time you give yourself, the smoother the exit.

One strategy is to treat the six-month-to-go mark as the point of no return when deciding to renew or exit. Before that, weigh your options, commit to a direction, and execute the necessary steps.

Read about the Top 5 Oracle ULA Certification Strategies for cost savings.

Oracle ULA Renewal

If your Oracle ULA is nearing its end and you determine that you still need the benefits of unlimited deployment, you can renew it.

Renewing means signing a new ULA (or extending the current one) for another term. This process isn’t automatic; it’s a negotiation with Oracle and has financial implications.

Here’s what to know about ULA renewal and how to approach it:

Why Renew? Companies choose to renew for several reasons: Perhaps they are still growing their Oracle usage and don’t want to be constrained by fixed licenses yet, or they uncovered compliance issues that make exiting risky (renewing pushes out the need to resolve those immediately). Some renewals include additional products they anticipate needing, reshaping the ULA for new business needs. Renewal can also be a strategy to realign with your current state – maybe your first ULA was overly broad or narrow, and now you know better what you need.
Financial Impact: Renewing a ULA means another upfront license fee and continuing (or increasing) the support costs. Oracle will charge for the renewal based on the new scope and possibly the deployments you achieved. Important: Just because you have certified X licenses doesn’t mean Oracle will let you walk away and re-enter a ULA cheaply. They might calculate the renewal price based on your current licenses. However, you have leverage too: if you truly have a huge deployment, Oracle wants to keep you under a ULA rather than you owning all those licenses and potentially not buying more. Companies often find the renewal fee is lower than the initial ULA (because they are perhaps not expanding as explosively or they negotiate better), but this isn’t guaranteed.
Negotiation Strategy for Renewal: Renewal time is a chance to renegotiate terms – you’re not obligated to carry over the same conditions. Use this opportunity to fix any shortcomings of the original ULA. Key negotiation points include
- Included Products: Add any new Oracle products you plan to use in the next term so that unlimited rights cover them. Conversely, remove products that you no longer need or have never fully used to avoid paying support on them.
- Term Length: Maybe the first term was 3 years; consider whether you want a shorter or longer term this time. Longer terms lock in pricing, but shorter terms give flexibility. If your growth horizon is only two more years, there is no need to sign a 5-year ULA.
- Support Costs and Caps: Try to negotiate the support arrangement. For example, ensure the annual support fee remains flat during the renewal term (no yearly uplift), or cap any post-ULA support increase at a lower rate. If your previous ULA rolled in a lot of support from old licenses, see if there’s any way to adjust that (though Oracle usually won’t let you reduce support revenue).
- Certification Conditions: If certain clauses (like the cloud 365-day rule or specific entity restrictions) were problematic, discuss them. Perhaps you can get a clause allowing a particularly large subsidiary that wasn’t in the first deal or more lenient cloud terms.
- Price Breaks for Lower Usage: If your deployment didn’t grow as expected, you might argue for a lower renewal cost. Show Oracle that your needs are more modest; thus, the unlimited grant is less risky to them, warranting a cheaper deal.
- Credit for Purchased Licenses: If you had to buy some licenses during the ULA (maybe for a non-included product), see if Oracle can factor that into renewal pricing or allow you to include those.
Renegotiation Benefits: Many companies successfully use renewal to reduce risk and cost. For instance, one might negotiate that newly acquired business units are included going forward, eliminating compliance issues in case of M&A, or if the original ULA had some outdated contract language, now is the time to update it to current standards. If you found the original ULA’s terms around virtualization or cloud restrictive, you could negotiate more flexible terms in the renewal. You have some leverage because Oracle wants to keep you on a ULA (it ensures your continued spending).
Renewal Process Timeline: Start discussions with Oracle early (maybe 6-12 months out if considering renewal). Oracle is usually very willing to talk because they want to lock in the renewal before you decide to walk away. You should have an offer from Oracle for renewal terms a few months before expiry. This might go through rounds of negotiation. If you reach an agreement, you’d sign a new contract (or amendment) that either extends the ULA from the end date or begins a new term seamlessly after the old one ends, so there’s no gap in coverage.
Costs Example: In the case study mentioned earlier, the company saved $8 million by not renewing. That implies Oracle likely quoted around that amount for renewal. This indicates renewal can be a multi-million-dollar decision. Another company might find that Oracle offers a renewal for the same annual support, plus a smaller one-time fee, because the heavy lifting was done in the initial deal. It varies.
If Not Renewing: If you decide not to renew, ensure you follow the certification process to exit. Oracle will sometimes keep a renewal offer on the table even as you approach the end, but know that after exit, you lose the option to renew under those unlimited terms. You’d then be just a normal customer with fixed licenses.
Negotiation Tip: Get Oracle’s sales team competing against the scenario of you certifying and leaving. If they fear you might just certify and walk away with thousands of licenses (which you could then possibly stop buying more for a while), they may present a more attractive renewal to keep you “in the fold.” Use that as leverage to get better terms – effectively, “We’re prepared to exit unless the renewal terms make sense for us”. Conversely, if Oracle senses you have no choice but to renew (because you clearly can’t certify due to compliance issues or ongoing projects), your leverage diminishes. Thus, even if you plan to renew, try to maintain the posture (and reality) you could exit if needed.
Future Strategy Alignment: Use renewal time to assess your long-term strategy. Are you renewing just to postpone an inevitable exit, or do you foresee that you’ll likely keep renewing indefinitely (some companies roll ULAs for many years)? If your goal is eventually to get off the ULA, maybe negotiate a smaller renewal that just covers until a certain project ends. If you’re all-in on Oracle for the long run, consider if a PULA (perpetual ULA) or a longer ULA might save money versus repeating renewals.

In summary, ULA renewal is a chance for a “do-over” – to fix contract terms, right-size your license scope, and align costs with current usage. While it does mean paying Oracle more license fees, a well-negotiated renewal can yield more value and reduce future headaches.

Go into renewal discussions with clear objectives: what you want to add, drop, or change. And always weigh the renewal offer against the alternative of certifying and exiting. That comparison will tell you if renewing is worth it.

Read Oracle ULA Renewal and Exit Strategies: A CIO Playbook.

Oracle ULA Certification Case Study: Saves more than 400m USD

To illustrate the high stakes and potential savings in managing a ULA, consider a real-world case study of a company that navigated its ULA certification with remarkable success, reportedly saving over USD 400 million in potential costs.

Background: The company in question was a leading high-tech enterprise with 100,000+ employees, and it had multiple Oracle ULAs running concurrently. As these ULAs were nearing expiration, the company recognized that its future Oracle usage wouldn’t grow (they saw a leveling off). They were one year away from the ULA renewal point and wanted to avoid renewing since no further growth was expected. However, having multiple ULAs and a sprawling deployment meant the certification process would be complex.

Challenge: The main challenge was to exit the ULAs efficiently while minimizing costs and compliance risk. With renewal looming, Oracle might push them to extend the ULAs (keeping costs high). The company needed to ensure they weren’t caught in a position where Oracle could claim a huge license shortfall at certification, which could force an unwanted renewal. Essentially, they wanted out on their terms without paying a fortune in true-up fees.

Actions Taken: The company engaged an Oracle licensing consultancy (Redress Compliance) to assist. Together, they undertook several key actions:

Stakeholder Interviews & Workshops: To fully understand the company’s Oracle footprint and business strategy, they gathered all relevant internal stakeholders (IT, procurement, etc.). Workshops were conducted to educate the teams on ULA contract details and the certification or renewal options.
Contract Analysis & Strategy Development: They performed an in-depth review of the Oracle ULA contract terms and identified any areas of risk or leverage. From this, they developed possible strategies – scenarios for either renewing with changes or certifying and exiting – tailored to the company’s goals.
Licensing Assessment & Risk Mitigation: They did a comprehensive licensing audit across the company’s deployments. This assessment uncovered compliance risks valued at over $400 million, meaning if those issues weren’t addressed, the company could theoretically owe that much in licenses/fees. The team pinpointed exactly what and where these risks were. Many companies would panic at this number, but with analysis, they found a smart fix: They recommended the company purchase specific licenses (outside the ULA) for under $1 million to cover those risky areas. By spending <$1M, they could eliminate the $400M exposure – an incredible ROI on that spend.
Maximization & Certification: They also advised the company to maximize deployments before exit, ensuring that the value of deployed licenses at certification would exceed $2 billion (this sounds like they made sure to fully utilize the unlimited aspect to get a huge number of licenses). They then guided the company through the formal certification process, preparing all necessary documentation and data for Oracle to review. Essentially, they left nothing to chance; every piece of data Oracle might ask for was ready, and every deployment was accounted for.

Outcome and Benefits: The results were highly successful:

The company smoothly exited the ULA, with Oracle accepting its certification. They walked away with over 50,000 processor licenses across various Oracle technologies and middleware as perpetual licenses. To put that in perspective, they now owned tens of thousands of licenses without additional purchase, all as a result of having deployed them under the ULA.
They avoided renewing the ULA, thereby directly saving the renewal fees, which were calculated to be over $8 million. They would have paid Oracle this money had they extended the agreement, but now they kept it.
Most dramatically, by investing less than $1M in some licenses to plug the gaps, they mitigated over $400 million in compliance risk. In other words, Oracle could no longer present them with a huge bill for those deployments because they preemptively covered them. This is effectively a cost avoidance of $400M—money that, in a worst-case audit, the company might have had to spend or negotiate away. It’s an eye-popping number that shows how a little proactive licensing can save a fortune.
The engagement also left the company better educated and prepared regarding Oracle’s licensing strategy, presumably preventing such large risks from accumulating.

Key Takeaways: This case highlights several important lessons for any ULA customer:

Start Early and Get Expert Help: The company brought in experts and did the heavy work one year before renewal, not at the last second. This gave them time to find creative solutions (like the $1M purchase to save $400M) without Oracle’s pressure.
Thoroughly Audit Your Deployments: If they hadn’t uncovered those compliance issues, Oracle would have had a certification, and the negotiation dynamic would have been entirely different (Oracle holding a $400M bill over their head). By discovering it themselves, they solved it on their terms.
Don’t Be Afraid to Spend a Little to Save a Lot: Sometimes companies resist buying licenses during a ULA (pride or the notion that “we have unlimited, we shouldn’t buy extra”). But strategically spending a relatively small amount can shield you from astronomical costs later. It’s about the bigger picture.
Maximize the ULA Value: They ensured they got as many licenses as possible from the ULA by fully deploying where it made sense. This means that when they exited, they had a massive license estate now owned. That sets them up well – they likely won’t need to buy Oracle licenses for a long time, having 50k processors’ worth.
Avoiding Renewal Can Be Done: Oracle often expects large customers to renew, but this company proved that with the right preparation, you can exit cleanly and avoid continuous payments, even for a very large Oracle shop.
Quantify the Success: It is important to measure and communicate the savings (like they did: $400M risk avoided, $8M fees saved). This helps internally to show leadership the value of the effort and justifies the focus on license management.

In essence, this case study is a success story of turning a potentially costly situation into a huge financial win by being proactive and strategic about ULA management.

Not every company will have a $400M issue at stake, but even on a smaller scale, careful planning, risk identification, and strategic action is universally applicable.

Oracle ULA Pricing

Understanding how Oracle determines ULA pricing can help you negotiate a better deal. Oracle ULA pricing is not a fixed menu; it’s more of a custom quote based on your organization’s circumstances

. Here’s a breakdown of Oracle’s typical approach to ULA pricing and the factors involved:

Baseline: Your Current Spend and Usage: Oracle often uses your existing Oracle investment as a starting point. They will examine how much you’re currently paying in support (and licenses, if you were about to buy more). For example, if you currently pay $500k/year in support and you’re short on licenses that would cost $5M to purchase, Oracle has a rough idea of the value of making that all “go away” via a ULA.
Projected Needs Method: Oracle commonly asks for your projected deployments over the next few years (the would-be ULA term). They may ask, “How many Oracle processors will you need for Database, WebLogic, etc., in three years?” They take those numbers, multiply by list price, and perhaps apply a discount. The total becomes a ballpark for the ULA fee. The logic is that the ULA should cost somewhat less than what you’d pay to license that growth traditionally. Tip: Be conservative in these projections – if you overestimate, the price will be higher.
License Shortfall / Audit Leverage: If a ULA is being offered in the context of an audit or known shortfall, Oracle might price it relative to the compliance exposure. For instance, House of Brick noted Oracle tends to offer ULAs at roughly 50–70% of the cost of the identified license gap. So, if an audit found you under-licensed by $10M, Oracle might propose a ULA for $5M (plus the new support amount). This way, they present it as “you save 50% versus buying licenses,” while Oracle secures a long-term support stream.
Number of Products Included: The more products you want covered, the higher the price, as each product adds its license value. Including, say, Oracle Database, WebLogic, and a pack of DB options will cost more than just including Oracle Database alone. Oracle will sum up the value of each product’s unlimited usage. If some products are minor or not heavily used, consider if they need to be in the ULA or if you can license them separately to keep ULA costs down.
Size of the Company (Deployment Scale): Larger organizations with more servers and usage will naturally face a higher ULA price range. Oracle has seen what similar companies deploy, so they have benchmarks. A global Fortune 100 firm will likely be quoted in the tens of millions, whereas a smaller enterprise might be quoted a few million. As mentioned, ULAs can range roughly from $1M to $ 50 M+.
Contract Length: A longer ULA (5 years vs. 3 years, for example) might have a higher upfront cost because you get unlimited rights for more time. But sometimes Oracle could offer a slight deal for longer terms since it guarantees them more years of support. It depends—some customers have reported that a 3-year vs. 4-year ULA didn’t change the fee much, except they had to pay an extra year of support.
Competitive and Negotiation Factors: Oracle sales will gauge how critical Oracle is to you and if you have alternatives. If they sense that you might reduce Oracle usage without a good ULA offer or go to a competitor, they might be more flexible on price. They might hold firmer if Oracle is confident you’re stuck with them. Also, timing (end of Oracle’s quarter/year) can affect discount – sales teams have quotas, and closing a ULA deal can help them, so you might get a better discount if you sign at a strategic time for them.
Support Fee Calculation: Oracle typically consolidates all your support into the ULA. The new annual support fee is usually your existing support + 22% of the net license fee of any new portion. The ULA deal is often structured so that your first year support equals your old support plus whatever new licenses you effectively got. That becomes the fixed support in the future. If you had $1M in support and paid $5M for the ULA license fee, your new support might be around $1M (old) + $ 5 M*22 % ≈ $2.1M, matching the earlier example. Oracle may keep support flat during the ULA term, then allow standard increases (e.g., +8% annually) after.
“Net License & Annual Support” Presentation: Oracle often presents a spreadsheet showing list price, discounts, etc. For example, they might list all products as “unlimited,” show a theoretical list price of $X, apply a big discount (70-80%), yielding a net license fee, and then show 22% of that as the annual support【33†】. This breakdown can be useful to see how they are valuing things. You can negotiate on either lever – the discount percentage or the support base.
Price Benchmarks: As a very rough guideline (not official, just observational), a mid-size ULA might be $3M up front + $660k/yr support (assuming 78% discount off $15M list, for example). A large ULA might be $20M + $4.4M/yr support (78% off $90M list, just for illustration). These numbers can vary hugely, but they show the pattern: high list, discount, and support at 22% of the net.
Negotiation Leverage: Always remember that everything is negotiable. If the initial number is too high, provide a rationale for a lower figure: Perhaps some of those projected deployments might not happen, or you could drop a product from the scope or have budget constraints. Oracle reps often have some flexibility. Also, consider getting quotes from third-party Oracle license consultants on what similar companies paid – this info can strengthen your case if Oracle’s quote to you is an outlier.

In summary, Oracle ULA pricing is based on the value Oracle believes you’ll derive (and the licenses you would otherwise buy). They aim to strike a balance where you feel you’re saving money, but Oracle still secures a sizeable fee and locks in your support.

To manage this:

Do your homework: Know your usage and what it would cost normally.
Be strategic in what you include: More isn’t always better if it bloats cost without benefit.
Negotiate: Don’t take the first offer. There’s often room to improve it.

Always examine the long-term support costs—that’s where Oracle often makes its money back. A slightly higher upfront fee with lower locked support might be better than a lower fee that doubles your support forever. When evaluating the ULA price, look at the total cost over 5-10 years.

Top 10 mistakes organizations make with their Oracle ULA

1️⃣ . Not Understanding the Contract Terms: Oracle ULA contracts can be pretty complex, and not fully understanding the terms and conditions can lead to non-compliance and unexpected costs.

2️⃣ Failing to Maximize the ULA’s Value: Many organizations fail to fully utilize their ULA’s potential, missing opportunities to deploy more software within the same Oracle ULA ends and scope.

3️⃣ Overlooking Oracle’s Compliance Rules: Oracle’s compliance rules can be intricate and change regularly. Failure to keep them current can result in violations and hefty fines.

4️⃣ Poor Record Keeping: Organizations often fail to maintain proper records of their Oracle software deployment, leading to difficulties during certification.

5️⃣ Not Planning for ULA Exit: Many organizations don’t have a strategic plan for the end of their ULA term, which can result in a rushed decision or unfavorable renewal terms.

6️⃣ Ignoring the Certification Process: Certification is crucial in a ULA contract. Neglecting it can result in license loss and higher costs.

7️⃣ Not Engaging Oracle Expertise: Not consulting with Oracle licensing experts can result in a lack of strategic insights and potential pitfalls.

8️⃣ Inadequate Audit Readiness: Organizations often underestimate Oracle’s unlimited license agreement audit capability, leading to unpreparedness and potential non-compliance during audits.

9️⃣ Not Considering Future Business Changes: Organizations fail to factor in potential business changes, like acquisitions, mergers, or divestitures, which can significantly impact the Oracle ULA.

9️⃣ Not Negotiating Effectively: Many organizations don’t negotiate effectively at the outset or during the renewal of their ULA, leading to unfavorable terms and conditions.

FAQs Oracle ULA

What are the most common mistakes companies make with Oracle ULA?

Companies often do not over-deploy Oracle software. The support fees are fixed regardless of whether you certify 50 processors or 50,000. Secondly, every organization is non-compliant and has mistakenly used non-ULA software.

Where can I find information on the certification process?

The certification process is described in the certification clause of your agreement, also known as the ordering document. This clause outlines the requirements for reporting your exit numbers, sharing data with Oracle, and cooperating with the Oracle audit team during the exit phase.

Will my support costs increase once I exit my ULA?

No, support costs will not increase after you have been certified. However, running older versions of Oracle software may result in additional costs for extended support and a 4-8% year-over-year increase in technical support fees.

How does ULA certification work with cloud deployments?

Older ULA agreements did not allow for counting deployments in a public cloud. However, newer deals have a standard clause allowing calculating an average deployment over 12 months. Planning and managing your contract is essential to avoid any risks with this clause.

Can I deploy Oracle on VMware while in a ULA?

Yes, deploying Oracle on VMware allows you to count all physical hosts in virtual environments, maximizing your ULA. The best practice is to deploy ULA software on VMware and then calculate all clusters toward your exit number.

Is deploying Oracle on VMware the best way to maximize my ULA?

Yes, it is a recommended strategy to maximize your ULA

Will Oracle be upset if we exit our ULA with 5000-15000 processor licenses?

Oracle may have difficulty explaining the numbers to upper management, but this is not the customer’s concern. Standing your ground and declaring all physical hosts in virtual environments is essential.

Can we negotiate to add more products to our ULA contract without a full renewal?

Yes, you can add additional products to your active ULA contract. However, you must be strategic about which products to add, as sharing too much information with Oracle can increase ULA pricing.

How can I minimize financial risk during the ULA certification process?

One way to minimize financial risk is to perform an independent Oracle license audit 6-9 months before the agreement expires. This will allow you to review your current deployments and remove license compliance risks. In the last months, you have maximized your agreement by deploying more ULA software before the certification begins.

How can I use my existing SAM tooling during the certification process?

We recommend only using it for discovery purposes; all verified SAM tools are only 90% accurate. The 10% where they are wrong equals millions in software risk.

What should I consider when negotiating the certification clause in my ULA contract?

When negotiating the certification clause, it’s essential to consider the following: how many days before or after the agreement ends you need to report your exit numbers to Oracle, what data you need to share with Oracle, how to count deployments in the public cloud, and how much you need to cooperate with the Oracle audit team during the exit phase.

How does ULA certification work with cloud deployments?

In older versions of the ULA, counting deployments in the public cloud toward your exit numbers was impossible. However, in newer versions of the ULA, a standard clause allows you to count an average deployment over 3-12 months. Understanding how this may impact your financial risk during certification is essential.

Which Products can be included in an Oracle ULA?

An Oracle ULA can include all Oracle products, including the database, middleware, applications, and Java.

How do I decide which type of Oracle ULA is right for my business?

Deciding which type of Oracle ULA is right for your business will depend on your specific needs and requirements. To determine which type of ULA is most appropriate, you must assess your current and future Oracle product usage, budget, and long-term growth plans. Consulting with an independent Oracle licensing advisor may also help make this decision.

How to Oracle determine the price for an Oracle ULA?

As we sold Oracle ULAs on Oracle’s behalf, we can reveal that there is no price list. Oracle tries to come up with a business value for your ULA. End customers should try never to pay more than $ M1-3 in license fees. If you have paid more, consider getting help from someone who can help you build the business case for a more optimal ULA price.

Can I run Oracle software on a public cloud while under a ULA?

Yes, we have not encountered a single Oracle ULA in which you, the end customer, were not allowed to use the public cloud while the unlimited period was valid.

What are the options for renewing an Oracle ULA?

When renewing your Oracle ULA, you can choose to renew the agreement as is, with the same products and terms. Alternatively, you can remove or add products and potentially renegotiate the contract terms. You can also consider signing a shorter agreement extension, such as 6-12 months.

How can I best prepare for my ULA renewal negotiation?

Before renewing your Oracle ULA, you must review your current Oracle licensing position and understand any financial risks. You should also review all contract terms, look for improvement opportunities, and remove contractual risks. It would help if you also considered working with an independent Oracle licensing advisor to ensure you maximize your agreement and maintain compliance.

How do I save money on my Oracle ULA?

Contact us. We have helped over 100 organizations with Oracle ULAs, and our Oracle ULA License Optimization service may deliver the best ROI this year.

What if my Oracle ULA is expiring next month?

Don´t worry; even contractually, you are supposed to report the ULA certification numbers on a specific date. Oracle recognizes and is aware that organizations may struggle to submit the certification on time.. Many organizations we work with report their numbers to Oracle months after the certification date. That means we always have time if you need our assistance to ensure you deploy the correct numbers.

How does an Oracle ULA work?

During the ULA term, you can deploy as many licenses as needed for specific Oracle products. At the end of the term, you certify your usage to Oracle, and these licenses become ‘perpetual licenses’ for your continued use.

What is an Oracle ULA?

An Oracle Unlimited License Agreement (ULA) is a contract that allows you to use an unlimited quantity of specific Oracle products for a fixed period, usually 2-3 years.

What are the benefits of an Oracle ULA for my organization?

Some Oracle ULA benefits are providing Oracle software at a fixed price and the ability to choose which infrastructure to deploy, as licensing fees are not considered.

What are the potential pitfalls of an Oracle ULA?

Potential pitfalls include unexpected costs at the end of the ULA if the certification process isn’t handled correctly, non-compliance risk due to misunderstanding of ULA terms, and the potential for overcommitment if the ULA isn’t fully utilized.

What happens when our Oracle ULA term ends?

At the end of the ULA term, you must count and certify your usage of the ULA products to Oracle. After certification, these licenses become perpetual licenses.

What is the process for Oracle ULA certification?

ULA certification involves counting and reporting your usage of the ULA products to Oracle at the end of the ULA term. This process should be approached carefully, as errors can incur additional costs.

How can we effectively manage our Oracle ULA?

Effective ULA management involves understanding ULA terms, keeping good records of software deployment, planning for certification, and seeking expert help.

What should we consider before renewing our Oracle ULA?

What if you have deployed non-ULA software without your knowledge? If you have a compliance issue, you can include any new products in the latest agreement and eliminate license issues that will be discovered the day you want to certify.

Can we exit our Oracle ULA before the end of the term?

Exiting a ULA early is generally impossible without negotiation with Oracle, as ULAs are contractual agreements for a fixed term. However, individual circumstances may vary.

We have an Oracle ULA and we want to reduce our Oracle support costs. How do we proceed?

You must certify your Oracle ULA; once that is done, you can reduce Oracle support fees.

What happens at the end of the Oracle ULA?

You are contractually obliged to submit a certification letter with quantities and products. Oracle also asks for deployment reports. You must do the deployment report correctly, or you will have problems with Oracle. You can call this “an Oracle ULA license audit.”

We are an Oracle ISV – Can we sign Oracle ULAs?

Yes, for your end customers, Oracle names them Oracle PAH ULA or for internal use only.

What should we do post Oracle ULA?

If possible, look at optimizing and reducing costs; read our Post Oracle ULA strategy guide.

What is an Hybrid Oracle ULA?

A Hybrid Oracle ULA is a contract where Oracle bundles its traditional ULA together with cloud services and benefits.

Oracle ULA when are they good?

There are some real use cases for Oracle ULA.

Oracle ULA vs ELA?

Oracle has two different flavors of ULA: capped and unlimited. ELA is sometimes called ELA.

Is there an audit at the end of the ULA?

The Oracle ULA certification process can be called the unlimited license agreement audit.

What is a ULA?

This is the short name for the Oracle Unlimited License Agreement.

What if we aquire an legal entity during the ULA term?

Entities may not use ULA software while acquiring the Oracle ULA unlimited license agreement.

How Redress can help with your Oracle ULA

Oracle ULA License Optimization Service

Watch this video on YouTube

Our Oracle ULA license optimization service offers the following benefits:

Independent licensing assessment: Our team of experts will review your current Oracle ULA agreement and assess your licensing requirements to ensure compliance and optimize your license usage.
Maximizing current agreement: We will analyze your current Oracle ULA agreement and recommend strategies to maximize the value of your investment.
Oracle ULA exit or renewal strategy: Our team will work with you to develop an optimal exit or renewal strategy based on your business needs and budget.
Negotiation assistance: We will provide expert guidance and support during the Oracle ULA negotiation to ensure you receive the best terms and pricing.

Our team has over 250 years of experience with Oracle licensing and has helped over 100 companies optimize and exit their Oracle ULAs.

We offer a flexible and tailored approach to meet your specific needs. Our services are designed to help you save money, reduce risk, and ensure compliance with Oracle licensing agreements.

Read more about our Oracle ULA License Optimization Service.

Do you want to know more about our Oracle ULA Optimization Service?

Author

Fredrik Filipsson

Fredrik Filipsson has 20 years of experience in Oracle license management, including nine years working at Oracle and 11 years as a consultant, assisting major global clients with complex Oracle licensing issues. Before his work in Oracle licensing, he gained valuable expertise in IBM, SAP, and Salesforce licensing through his time at IBM. In addition, Fredrik has played a leading role in AI initiatives and is a successful entrepreneur, co-founding Redress Compliance and several other companies.
View all posts