Your registration is confirmed and your guide is ready. The complete 2026 edition follows below, with nothing further to request.
Prepared by Atonement Licensing · buyer-side advisory · last reviewed June 2026. Firm figures — $2.4B+ negotiated, 38% average savings, and 72% average audit-claim reduction across 500+ engagements — trace to our methodology. The 500-processor Oracle Database estate modelled below is an indicative benchmark for illustration, not a quote, and every scenario figure is labelled accordingly.
Executive summary
An Oracle Unlimited License Agreement exit succeeds or fails on a single number, the certification count, and that number is a buyer decision long before it is an Oracle one. The same physical estate can certify two ways: on Oracle's whole-cluster reading of virtualization, or on an isolated, evidenced count that reflects where the software actually runs. The distance between those two readings is where the money lives, and it is settled by preparation, not by the account team.
On a representative 500-processor Oracle Database Enterprise Edition estate reaching the end of a three-year ULA, accepting Oracle's whole-cluster view of a VMware environment models a certified position near 720 processor licenses, while isolating Oracle onto evidenced clusters and applying the Processor Core Factor Table correctly models near 400, a gap of roughly 320 licenses on the identical deployment (indicative). Because support follows the certified base at roughly 22 percent of license value every year, that gap is not a one-time figure. It is about $3.3M of avoidable support per year, near $16M across a five-year hold (indicative), on software you already own.
The exit turns on five disciplines: the contract clauses that define what your count may include, a twelve-month certification countdown, the core-counting basis in virtual and cloud environments, the discipline to certify genuine deployments rather than padded ones, and a certification letter you can evidence years later. This guide covers each in turn, with the tables and checklists our advisors use on live exits. Across more than 500 enterprise engagements, buyers we advise have negotiated over $2.4 billion in software contracts, at average savings of 38 percent and average audit-claim reductions of 72 percent.
How a ULA works and what certification converts
An Oracle Unlimited License Agreement grants unlimited deployment rights to a defined set of products for a fixed term, most commonly three years, in exchange for an upfront fee and annual support. The word unlimited applies only to the named products and only inside the contracted scope. Anything outside that list is licensed separately at standard terms under the Oracle price list and the Oracle Processor Core Factor Table.
A ULA feels simple while it runs. You pay a fixed fee, deploy unlimited quantities of the named Oracle products, and stop tracking entitlements for them. The complexity all lands at the end. The contract gives you one chance to declare what you deployed, and that declaration becomes your permanent license grant. Certification is the exit path: you count every qualifying deployment of each covered product, declare those quantities to Oracle in a signed letter, and they become perpetual licenses at that fixed number. Support then continues on the certified base.
The economics are decided at certification, not at signature. A ULA only pays off if you deployed aggressively during the term and certify a number far larger than the licenses you would otherwise have bought. A flat deployment over three years usually means you overpaid for flexibility you never used, and the exit is your chance to stop the meter.
What is covered and what is not
Read the product schedule before anything else. The unlimited grant names specific Oracle programs, often a database edition plus a defined set of options and management packs. Programs that look related but are not named carry no unlimited right. A team that deploys Partitioning, Advanced Security, or Diagnostics Pack assuming they sit inside the ULA, when only Database Enterprise Edition is named, builds a compliance gap that surfaces at certification. The same applies to deployment type: some ULAs cover production only, some include non-production, and the treatment of disaster recovery and standby environments varies by contract. The definitions in your ordering document and the Oracle Processor Usage Rights control here, not the assumptions of the team that signed the deal three years ago.
Action. Pull the product schedule and the deployment-type definitions in week one, then stand up a continuous install register for every named program. The certification you defend later is only as good as the record you keep now.
2Exit, renew, or migrate: the decision framework
The first decision is not how to certify. It is whether to certify at all. Oracle account teams often arrive 9 to 12 months before term end with a renewal proposal framed as the safe choice. It is rarely the cheapest. Test all three options against your real roadmap and cost, not against the renewal quote.
| Option | When it fits | Main risk |
|---|---|---|
| Certify and exit | Deployment of covered products has plateaued and a certified position costs less than another term of ULA fees | Undercounting invites audit; overcounting locks in higher support |
| Renew the ULA | You have concrete, funded growth in the covered products over the next term | Paying again for flexibility you may not use |
| Migrate to subscription or cloud | Your roadmap moves the workload to OCI or to a subscription metric anyway | Trading a paid-up asset for a recurring cost that never ends |
Run the numbers on a five-year horizon. A certified perpetual position carries a one-time cost already paid plus ongoing support. A renewal or a subscription is a recurring commitment. Many buyers find that a disciplined exit, even with a modest true-up, beats a renewal that locks in years of fees for capacity they will not deploy. Be alert to how the renewal is positioned: a common pattern presents renewal as protection against an audit, with the implication that exiting is risky. The opposite is usually true. A clean, well-evidenced certification removes audit exposure for the covered products, because you hold a fixed and documented entitlement.
Timing belongs in the model too. Oracle's fiscal year ends May 31, and quarter ends concentrate discounting authority on the vendor side. If your term end allows a negotiation window that overlaps an Oracle quarter close, the renewal and migration offers you are comparing against exit will be at their most flexible, which sharpens the comparison rather than changing the logic. The matrix below puts the three paths side by side on the dimensions a CFO weighs.
Weighing exit against renewal on a live ULA? Our advisors model all three paths with you.
Oracle Licensing ExpertsAction. Build a five-year cost model for all three paths before you respond to any renewal quote, and decide on your own roadmap first. Then judge Oracle's best offer against it, not the other way around.
3The twelve-month certification countdown
The buyers who exit cleanly start a year out. Certification is an evidence exercise, and evidence takes time to assemble across a large estate. Before the countdown starts, read the five clauses that set the rules of the count: the certification clause itself, territory, legal entity, cloud and hosting, and mergers and acquisitions. They decide what your count can include, and a count that ignores them is a count Oracle can reject. This is the countdown we run.
Inventory and basis
Build an independent deployment inventory across data centers, virtual clusters, and cloud accounts, then resolve the counting basis for virtualization before it decides the number for you.
Decide and deploy
Model exit, renew, and migrate on a five-year cost, choose the path while you can still act on it, and complete only genuine, funded production growth.
Reconcile and certify
Reconcile the count host by host, document every environment, draft the letter, and submit on a timeline you control with support terms closed in writing.
| Months before term end | What to do | Why |
|---|---|---|
| 12 to 10 | Inventory every deployment of each covered product on your own basis | You cannot certify what you have not measured independently |
| 10 to 8 | Resolve the counting basis for virtual and cloud environments | Soft partitioning and cloud rules decide most of the number |
| 8 to 6 | Model exit, renew, and migrate against five-year cost | Decide the path while you still have time to act on it |
| 6 to 4 | Complete any genuine, planned deployments still in flight | Real production growth belongs in the certified count |
| 4 to 2 | Reconcile your count, document every environment, draft the letter | The certification letter is a legal record, not a formality |
| 2 to 0 | Submit certification and close support terms in writing | Timing protects you; a rushed letter does not |
Action. Put a certification owner and the five gating clauses on the calendar twelve months out. The early months surface the deployments nobody remembered, while you can still act on them.
4Core counting traps in virtual and cloud environments
The certified number lives or dies on how cores are counted, and virtualization is where the largest errors hide. Oracle's published position, set out in its Partitioning Policy, is that soft partitioning, including standard VMware configurations, does not limit licensing. Under that view an entire vSphere cluster can be treated as licensable even when Oracle runs on a few hosts. During certification that can inflate your count far beyond actual use, and after certification it inflates the support bill that follows for as long as you hold the licenses.
The defense is to map exactly where covered products run, isolate Oracle workloads onto defined and evidenced clusters, and apply the Oracle Processor Core Factor Table correctly to the hosts that genuinely run the software. The chart below shows, for the benchmark estate, where an over-count typically comes from, expressed as the share of the over-count attributable to each error.
| Environment | How cores are counted | Buyer action |
|---|---|---|
| Physical server | Populated cores times the processor core factor | Confirm the core factor for the chip family |
| VMware soft partition | Oracle treats the wider cluster as licensable | Isolate and evidence Oracle-only clusters |
| Approved hard partition | Only the partitioned cores count | Keep the configuration evidence current |
| Public cloud | Per the cloud policy and your ULA terms | Confirm what the contract allows before counting |
The Oracle Processor Core Factor Table assigns a factor of 0.5 to most modern x86 processors, so a 32-core Intel host counts as 16 processor licenses. Teams that certify raw core counts without applying the factor overstate the number by half, and teams that apply it to cloud vCPUs without checking the cloud policy understate it. Run the factor host by host, and keep the chip inventory with the certification evidence.
Public cloud adds a second trap. Whether AWS and Azure instances can be included in a certified count depends on what your specific ULA permits and on the version of Oracle's cloud licensing policy in force for your agreement. Many ULAs allow authorized cloud deployments to count, but with conditions, and some restrict counting to deployments live at the moment of certification. If your ULA only credits cloud instances live at the certification date, a workload you migrated to AWS during the term but scaled down before certifying may not count. Plan the state of your cloud estate for the certification window deliberately, the same way you plan your on-premise count.
Annual Oracle support a 320-license over-count adds at roughly 22 percent on the 500-processor benchmark estate, every year you hold the licenses (indicative).
The Processor Core Factor Table value for most modern x86 chips. A 32-core host counts as 16 processor licenses; certifying raw cores overstates the number by half.
Action. Settle the virtualization and cloud counting basis months before you certify, with isolation evidence in hand. These two questions move the number more than any other factor in the exit.
5The late deployment spike and how Oracle tests it
A ULA rewards deployment, so the temptation near term end is to install widely and certify a large number. Oracle anticipates this. Most ULA terms define what counts as deployed, and a credible certification rests on production or live installations, not on instances spun up days before the deadline to pad the figure. Genuine, planned growth belongs in your count, and you should complete real projects before term end rather than after. What does not hold up is a deployment that exists only to inflate certification; Oracle can question installations that appear in the final weeks and serve no workload, and an aggressive figure you cannot defend invites the audit you were trying to avoid.
A padded certification is not a win banked. It is a permanent support bill, dressed as an asset.
There is a cost tail. Every license you certify carries support at roughly 22 percent of its value each year, and you cannot reduce a certified base without consequences under the support repricing rules. The right mental model is to maximize genuine deployment, not paper deployment: if a project to expand a database estate is real and funded, accelerate it so the production systems are live and evidenced before term end. A directory full of idle instances created in the final week is a liability dressed up as an asset.
The support repricing clause, usually titled matching service levels and pricing following reductions, is what makes overcertification expensive. Drop part of a certified support set later and Oracle can reprice the remaining licenses toward list, wiping out the saving. Decide the support strategy for the certified base before the letter is signed, not after the first renewal invoice arrives.
Validating Oracle's certification tooling
Oracle often supplies scripts or a measurement tool to support certification, and these can be useful, but they are not neutral. The output reflects Oracle's counting assumptions, including the treatment of virtualization and of options that are installed but not used. Two areas deserve particular scrutiny: options and management packs enabled by default in the database but never actually used, which the tooling can report as deployed; and the cluster boundary in virtual environments, where the tool may assume a wider scope than your architecture requires. In both cases your independent baseline is the control that keeps the number honest.
Need an independent read on your certification count before you submit it?
Book a 30 minute callAction. Validate every number Oracle's scripts produce against your own host-by-host baseline before it reaches the certification letter, and certify only deployments you can evidence as real.
6Territory, entity, and acquisition clauses
The fine print on scope decides who and what your ULA covers, and three clauses cause the most surprises at certification. Territory: some agreements limit deployment rights to named countries or regions, so installations elsewhere may not certify. Legal entity: the named licensee and its defined affiliates are covered, and deployments in entities outside that definition can fall short. And mergers and acquisitions: if you acquired a company during the term, whether its Oracle deployments count toward your certification depends on the acquisition language. Some ULAs absorb acquired entities up to a size threshold, others exclude them entirely.
The certification clause itself frames all of them. It defines what you must declare, in what form, and by when, and it usually requires an officer of the company to sign a statement of deployed quantities. Where you find a scope problem, fix it before the letter, not after. A deployment sitting in a country outside the territory clause, or in a joint venture outside the entity definition, can sometimes be brought into scope by amendment during the exit negotiation, and Oracle has commercial reasons to agree while a renewal is still theoretically on the table. Divestitures cut the other way: deployments that left with a sold business unit should not appear in your certification, so reconcile organizational change against the entity definition so your final count matches the company as it exists at certification, not as it existed at signature.
Action. Reconcile every acquisition and divestiture against the entity and territory definitions before you count, and raise any scope gap on your timeline with a proposed amendment, not on an auditor's.
7The certification letter checklist
The certification letter is the document that ends the ULA, and its wording is a buyer concern, not an Oracle formality. It is typically signed by a C-level officer and becomes the permanent record of your entitlement. Before you sign, confirm every point below.
- The letter states the exact products and quantities you intend to certify, with no rounding up or padding you cannot defend.
- The numbers reflect your counting basis, validated host by host, not an unvalidated Oracle script.
- The perpetual grant is recorded clearly enough to defend in a future audit.
- Territory, entity, and acquisition scope match the company as it exists today.
- The support terms that apply to the certified base are closed in writing alongside the letter.
- The supporting evidence is filed and retrievable for the life of the licenses.
One omission appears in almost every troubled exit we review: Java. Oracle Java SE is almost never a ULA-covered product, and the Java SE Universal Subscription is priced per employee, counting your whole workforce rather than Java users. Buyers who assume the ULA covered their Java estate exit the database agreement cleanly and walk straight into a separate exposure. Scope Java on its own track before the certification letter is signed.
After the exit: support strategy
Certification ends the ULA, but it does not end your relationship with Oracle support. The certified base sets your annual support bill, and that bill is the single largest recurring Oracle cost most buyers carry after exit, running at roughly 22 percent of net license fees per year. Third-party support is a credible option for a stable, mature estate once you hold a fixed perpetual position, and even the option of switching strengthens your hand at the next support conversation. Whether or not you move, model the total cost of your support strategy before and after certification so the exit delivers the saving it promised.
Action. Close the support terms for the certified base in writing alongside the letter, scope Java separately, and keep every evidence artifact retrievable for the life of the licenses.
Certify the number you genuinely deployed, built on your own host-by-host measurement, isolated and evidenced against the Partitioning Policy and the Processor Core Factor Table, and decided on a five-year cost rather than the renewal quote. Resolve territory, entity, and acquisition scope before counting, scope Java on its own track, and close the support terms in writing alongside the letter. A disciplined exit converts the agreement into a clean, fully paid perpetual position; a rushed or padded one hands Oracle either an audit opening or a permanent support bill on licenses you never needed.
Key takeaways
- The certification number is a buyer decision. Build it on your own measurement.
- Decide exit, renew, or migrate against five-year cost, not the renewal quote.
- Read the certification, territory, entity, cloud, and acquisition clauses first.
- Start the certification countdown 12 months before term end.
- Settle virtualization and cloud counting before you finalize the number, using the Partitioning Policy and the Processor Core Factor Table as your reference points.
- Only certify genuine, evidenced deployments. A padded count carries permanent support cost.
- Validate Oracle's certification scripts against your own baseline, and scope Java SE separately.
Frequently asked questions
When should we exit an Oracle ULA instead of renewing?
Exit when deployment of the covered products has plateaued and a certified perpetual position costs less over five years than another term of ULA fees. Renew only when you have concrete, funded growth in the covered products. Model the decision at least a year before term end.
How is the ULA certification number calculated?
You count production deployments of each covered product on the agreed contractual basis, apply the Oracle Processor Core Factor Table to the hosts that run the software, and declare those quantities in a signed certification letter. They become perpetual licenses at that count, and support continues on the certified base.
Can we count cloud deployments in our certification?
It depends on your specific ULA terms and Oracle's cloud licensing policy. Many agreements allow authorized AWS and Azure deployments to count with conditions, and some only count instances live at the certification date. Read the contract language before you assume the cloud helps your number.
Is it safe to deploy heavily right before certifying?
Genuine, planned production growth belongs in the count. Installations created only to inflate the figure can be challenged under the contract's definition of deployed, and every certified license carries ongoing support, so a padded number is a permanent cost rather than a saving.
What happens to support after we certify and exit?
Support continues on the certified base at roughly 22 percent of license value per year, and reducing that base can trigger the support repricing clause. Model the support cost of your certified position before you finalize it.
Get an exit plan applied to your contract, with a confidential assessment within one business day. Or start with our Oracle Licensing Experts practice.
Book a 30 minute callRelated research: the Oracle Negotiation Playbook 2026, the Oracle Audit Defense Playbook 2026, and the Oracle Java licensing exposure guide. The landing page for this guide lives at the Oracle ULA Exit Guide overview.