Oracle ULA Certification Shortfall Report 2026

Executive Summary

An Oracle Unlimited License Agreement (ULA) is a fixed-term contract — typically three years — that grants unlimited deployment of a named set of Oracle products in exchange for a single upfront fee plus annual support. The economics of a ULA are decided not when you sign it but when you leave it. At the end of the term you certify: you declare, product by product, how many processor and Named User Plus licenses you have deployed, and that declared quantity becomes your perpetual entitlement forever. Deploy more before the snapshot and your perpetual licenses grow at no cost. Deploy less, miss instances, or rush the count, and the unclaimed capacity evaporates. The certification is the single most consequential event in the entire ULA lifecycle, and it is the one most customers handle worst.

This benchmark measures the result across 137 ULA and PULA certifications and exits drawn from our wider base of 600+ Oracle engagements, completed between mid-2021 and May 2026. The headline finding is blunt: 68% of ULAs certify fewer licenses than the customer was contractually entitled to deploy. The median amount forfeited — perpetual entitlement the customer could have claimed and did not — is $3.2M, and the mean is $4.7M, dragged up by a long tail of seven- and eight-figure losses at large enterprises. This is not money Oracle overcharged. It is value the customer already paid for in the ULA fee and then handed back at the door.

The cause is structural, and it favors Oracle. Certification depends on complete, defensible discovery of every deployed instance — including the estates buyers routinely overlook: disaster-recovery and standby environments, development and test, virtualized clusters, instances inside acquired subsidiaries, and authorized public-cloud BYOL deployments. Oracle's own certification process does nothing to surface capacity the customer has not found; it accepts the number submitted. A low count suits Oracle perfectly, because every license you fail to certify is one you must buy later, or the lever that pushes you into renewing the ULA or converting to cloud. The undercount is not a clerical accident Oracle regrets. It is the predictable outcome of an exit process designed to be navigated alone.

The buyer-side counter is equally structural. Because deployment during the term is free and the snapshot is permanent, the disciplined move is deployment maximization: legitimately standing up every eligible instance of the ULA's products before certification, then proving the count with forensic discovery. In our data this lifts the certified quantity by a median of 41% — and a managed certification recovered a median $3.9M of additional perpetual entitlement over the customer's own first-pass internal number. The sections that follow quantify the under-certification rate, the dollar value forfeited by deal size, the achievable uplift, the renew-versus-certify split, and the specific Oracle products most often left uncounted — and set out the playbook to certify from a position of evidence rather than haste.

Methodology & Data Set

What Is Oracle ULA Certification and Where Does Value Leak?

A ULA (Unlimited License Agreement) is a fixed-term Oracle contract granting unlimited deployment of a defined list of products in exchange for a single upfront fee and annual support. During the term — usually three years — you can install those products without counting licenses. The trade is that the agreement ends, and when it does you must certify: produce a formal declaration of how many Processor licenses and Named User Plus licenses you have deployed for each product as of the certification date. Oracle accepts that declaration, and the numbers in it become your perpetual entitlement. From that moment, your deployment is capped at the certified figure; anything beyond it is net-new deployment that requires fresh licenses.

That single mechanic is why certification is the most consequential moment in the ULA lifecycle. The number you declare is not an administrative formality — it is the permanent size of your Oracle estate. Under-declare by 200 processors of Database Enterprise Edition and you have not saved Oracle anything; you have given away roughly $9.5M of perpetual entitlement at list, plus the future support it would have carried. Over the years that follow, every database you stand up beyond the certified count becomes a compliance gap waiting for an LMS audit to find. The certification therefore sets both your asset base and your future audit exposure in one document.

Value leaks at certification through discovery failure, not through any single dramatic error. Oracle's products are designed to run quietly and in places a hurried inventory misses. The most common leakage points we see, in order of frequency: disaster-recovery and standby servers that are licensed but excluded from a production-only scan; development, test, and QA environments that run the same Enterprise Edition and options as production; VMware and other virtualized clusters where the deployable footprint is far larger than the running instances; database options and management packs — Diagnostics Pack, Tuning Pack, Partitioning, Advanced Compression — that are switched on inside instances nobody flagged; instances inside subsidiaries and recently acquired entities that fall within the ULA's contractual scope but outside the IT team's line of sight; and authorized public-cloud BYOL deployments whose certification eligibility is misread. Each of these is a place where a license you were entitled to certify simply does not make it into the count.

The asymmetry is the point. Oracle has no obligation to help you find capacity, and every incentive not to. A certification that comes in low produces a smaller perpetual entitlement, which means your next growth cycle forces a new purchase, a ULA renewal, or a cloud conversion — all of which are new revenue for Oracle. The customer, meanwhile, often treats the certification as a compliance chore to be cleared rather than the multimillion-dollar asset-capture exercise it actually is. That mismatch in stakes and attention is precisely where the median $3.2M goes. The discipline that closes it is the same forensic, evidence-based approach our Oracle ULA advisory team applies to every exit, and it is detailed across our Oracle ULA guide.

One contractual nuance deserves emphasis because buyers consistently misjudge it. The licenses you may certify are governed by the deployment rights in your specific agreement — including territory restrictions, the named legal entities in scope, and any product-specific carve-outs. These vary widely between ULAs, and Oracle's standard certification request does not interpret them in your favor. Reading the actual contract language before the snapshot — not the sales summary, the executed ordering document and its schedules — frequently changes the certifiable number by a wide margin in either direction. Certifying without that reading is how customers both forfeit entitlement they held and, occasionally, over-declare into territory the contract never granted.

How Many Oracle ULAs Certify Fewer Licenses Than They Could Deploy?

Under-certification is the rule, not the exception. Across 137 certifications we classified each as under-certified (the submitted count was materially below the deployable entitlement), accurately certified (within a tight tolerance of the maximum), or — rarely — over-certified (declared beyond contractual rights, itself a compliance risk). The breakdown is stark: roughly two-thirds left entitlement on the table, and the determining variable was not company size or industry but whether the count was built on forensic discovery or on a rushed internal estimate.

The reseller and systems-integrator column deserves a warning. Customers often assume that bringing in the partner who sold or implemented the Oracle estate protects them at certification. It does not, reliably. A reseller's commercial relationship runs to Oracle as well as to you, and an SI's interest is in a clean, fast sign-off rather than a maximized count. The 64% under-certification rate in that column is barely better than going it alone, and the conflict of interest is exactly why the certification should be run by an adviser whose only relationship is with the buyer — the definition of independent license optimization.

The over-certification figures matter too, even though they are small. Five percent of customers declared more than their contract permitted — counting instances in a restricted territory, including entities outside the named scope, or certifying products whose unlimited rights had a deployment cap the buyer forgot. Over-certification does not save money; it manufactures a compliance gap that Oracle can later assert, because the perpetual entitlement only extends as far as the contract actually granted. The goal is not the highest possible number — it is the highest defensible number, every instance of which is backed by evidence and contractual right. That distinction between aggressive and defensible is the line our team works to, and getting it wrong in either direction is costly.

Two segment patterns are worth flagging. First, the under-certification rate is highest among customers exiting their first ULA, who have never run a certification before and underestimate how much discovery it requires; repeat exiters do measurably better. Second, the rate spikes for organizations that grew through acquisition during the term, because the deployed estate is fragmented across newly absorbed environments that the central IT team has not fully mapped. Both patterns point to the same root cause — incomplete visibility of the real footprint — and both are addressable only by starting the discovery early enough to be thorough, the subject of the timing analysis later in this report.

A final observation on the blended 68% figure: it understates the problem for the customers who can least afford it. The rate is an average across organizations that did at least some preparation and those that did almost none. Strip out the minority who ran a forensic certification, and the rate for everyone else sits above 70%. For the typical enterprise reaching a ULA term-end with an internal team, a tight deadline, and no independent count, under-certification is not a risk to manage — it is the overwhelmingly probable outcome unless the process is deliberately changed. That is the realistic baseline a CIO should assume when budgeting the certification, not the comforting idea that careful people get it right by default.

How Much Value Is Forfeited at Oracle ULA Certification?

Forfeited value is the dollar expression of the under-certification gap: the perpetual licenses a customer could have certified and did not, valued at list. Because a ULA's products and the buyer's headroom scale with deal size, so does the loss. The table below sets out the median and top-decile forfeiture by original ULA deal-value band, alongside the share of original fee that the forfeiture represents — a reminder that the giveaway is often a large fraction of what the customer paid to enter the agreement.

Two things about this table should change how a CIO frames the certification budget. First, the forfeiture is a large fraction of the original ULA fee — a median 66% across the sample. Put plainly, the typical customer gives back at the door roughly two-thirds of what it paid to walk in, because it never certified the capacity the fee had already bought. Second, the loss is concentrated where the dollars are largest: the $10M+ band under-certifies most often (74%) and loses most ($9.4M median), because big estates have the most hidden footprint — more DR, more virtualization, more subsidiaries, more options quietly enabled. The places with the most to gain are the places most likely to leave it uncaptured.

It is worth being precise about what "forfeited" means here, because Oracle's account team will dispute the framing. We are not valuing licenses the customer never deployed and never would. We are valuing deployable entitlement — instances that existed at the snapshot, or that the customer had every contractual right and operational reason to stand up before it, and that a complete certification would have captured. The conservative construction matters: we exclude the 22% annual support stream that the additional perpetual entitlement would have carried, so the real economic loss over a typical post-ULA holding period is materially larger than the one-time list figure shown. A $3.2M median list forfeiture understates the true multi-year cost.

The forfeited-value lens also reframes the cost of doing the certification properly. An independent forensic certification is an engagement cost measured in tens of thousands; the median entitlement it protects is measured in millions. In our sample the return on a managed certification was rarely below 10x and frequently above 50x, because the exercise does not create value out of nothing — it captures value the customer already owns and is about to surrender. This is the rare licensing decision where the buyer-side math is not close. The detailed playbook sits in our Oracle ULA guide, and the case-study evidence in our client outcomes — including a manufacturer whose certified Database EE count rose by 240 processors after forensic discovery, worth $11.4M in perpetual entitlement it had been about to leave behind.

How Much Can Deployment Maximization Uplift the Certified Count?

Deployment maximization is the buyer-side discipline of fully exercising the "unlimited" in an Unlimited License Agreement before it ends. During the term, installing another instance of a ULA product costs nothing incremental — that is the entire premise of the contract. At certification, the count freezes. The logical consequence, which Oracle would prefer customers not internalize, is that the months before the snapshot are the cheapest licenses you will ever acquire: free now, perpetual forever. A maximization program identifies every legitimate, planned, or near-term use of the ULA's products and brings it forward so it lands inside the count.

This is not gaming the system, and it is not deploying phantom instances to inflate a number — that would be over-certification, a compliance risk we explicitly avoid. It is accelerating real, intended deployments: standing up the DR and standby environments the architecture already calls for; building out the test and pre-production estates that production needs; enabling the database options that the roadmap will use; migrating eligible workloads onto the ULA's products rather than alternatives. Each of these is a deployment the organization was going to make anyway. Maximization simply ensures it happens before the door closes rather than after, when it would require a fresh purchase. The table shows the uplift achieved by product family across managed maximization programs.

Database options and management packs show the largest uplift — a median 57% — for a specific reason. Options such as Partitioning, Diagnostics Pack, Tuning Pack, Advanced Compression, and Multitenant are licensed per processor of the database they run on, and during a ULA they can be enabled across the entire Enterprise Edition estate at no incremental cost. Customers routinely enter certification having enabled them on only a fraction of eligible databases. Switching them on across the full eligible footprint before the snapshot — where the architecture supports it and the roadmap intends it — converts them from a future purchase into certified perpetual entitlement. This is the single highest-yield maximization move and the one most often missed, because options are invisible unless you go looking for them.

Timing is the binding constraint, and it is where most programs fail. Maximization requires runway: time to design, provision, test, and document new deployments, and to run the discovery that proves them. An organization that begins thinking about certification with 90 days left has almost no room to deploy materially — it can count what exists, but it cannot build. Our data shows the achievable uplift collapses as the term runs out: programs started 12+ months before term-end captured the full median 41%, those started at 6 months captured roughly half of it, and those started inside 120 days captured almost none. The 62% of organizations that begin certification with under 120 days remaining have, in effect, already forfeited most of the maximization opportunity before they start. The remedy is to treat the certification window as opening at least a year out — a planning horizon our ULA advisory engagements build around from day one.

A word on defensibility, because Oracle will scrutinize a count that jumps. Every maximized deployment must be real, operational, and evidenced: an instance that exists, is installed, and can be demonstrated at the snapshot date, supported by discovery output, configuration records, and architecture documentation. A forensic certification does not assert numbers; it proves them, line by line, so that if Oracle questions the count the evidence is already assembled. This is the discipline that separates a 41% uplift that survives Oracle's review from an aggressive number that invites a dispute. The same evidentiary standard our audit defense practice applies to repelling a back-licence claim applies, in mirror image, to certifying a maximized count that holds.

Which Oracle Products Are Most Under-Counted at Certification?

Not all products leak equally. The under-count concentrates in entitlements that are hard to see: database options and management packs that are toggled on inside an instance rather than installed as separate software, and integration products that span many nodes. The Enterprise Edition database itself is under-counted too, but less severely, because servers are at least visible to infrastructure teams. Options are invisible unless a tool or an expert specifically interrogates each database for what is enabled. The table ranks the products by median undercount across the sample.

The Diagnostics Pack figure is the one to internalize. Diagnostics Pack — and the Tuning Pack bundled with it — is enabled by default in Oracle Enterprise Manager and is, by our long-running observation, accidentally or routinely in use across more than 40% of enterprise database environments. Inside a ULA that ubiquity is an asset, because every database where the pack is genuinely in use is a database whose Diagnostics Pack entitlement you can certify. Outside a ULA, the same ubiquity is the classic compliance trap our audit work disarms. The certification is the moment to convert that exposure into owned entitlement: identify every database legitimately using the pack and certify it, rather than leaving the count to a manual estimate that captures half of it.

The pattern across the table is consistent: the more a product hides inside other infrastructure, the more it is under-counted. Options sit inside databases; cluster members sit inside RAC configurations; integration nodes sit across both source and target systems; non-production sits outside the production-only scans most teams run. A certification built on a production database list will systematically miss all of it. Only a discovery that interrogates every database for enabled options, enumerates every node of every cluster, and includes DR, test, and virtualized environments captures the real deployable footprint. That is the difference between the first-pass internal count and the forensic count — and, in dollar terms, the difference between the median $3.2M forfeited and the median $3.9M recovered.

There is a contractual reading buried in this table that buyers miss. Whether you can certify an option across the full estate depends on whether that option was in your ULA's named product list and on any deployment restrictions attached to it. Some ULAs include the core database and a subset of options; others are broad. Maximizing and certifying an option you do not actually hold unlimited rights to is over-certification, and it backfires. The product-by-product undercount opportunity is real, but it is bounded by what your specific agreement granted — which is why reading the executed schedules, not the marketing scope, governs every number in this section.

Should You Certify and Exit or Renew the Oracle ULA?

At term-end every ULA forces a binary decision: certify and convert to perpetual licenses, or renew the agreement for another term and another fee. Oracle markets renewal hard, because a renewed ULA is recurring revenue and a deferred certification is one the customer may handle even less well next time. The buyer-side test is narrow and quantitative: renew only if your forecast deployment growth over the next term, valued at what it would cost to license outside the ULA, clearly exceeds the renewal fee plus support. If it does not — and for most estates at most term-ends it does not — certifying and exiting is the value-maximizing move. The table shows what actually happened against what the economics indicated.

The damning row is "renew, not growth-justified": 26% of customers renewed their ULA when the economics did not support it. They paid a fresh multi-year fee to retain unlimited rights they had no plan to exercise, usually because Oracle framed renewal as the safe choice and the customer had not built the certification case to know otherwise. A ULA renewed without a deployment-growth thesis is not flexibility — it is a recurring fee protecting an option the buyer will never use, and it postpones the certification problem to a future term-end where the estate will be larger and harder to count. The single most expensive ULA mistake is not under-certifying; it is renewing to avoid having to certify at all.

Renewal is genuinely the right answer in a minority of cases, and the discipline is to identify them honestly. If you are mid-way through a large migration onto Oracle products, integrating an acquisition that will materially expand the estate, or standing up a major new platform on Enterprise Edition over the next two to three years, the unlimited rights have real forward value and renewal can beat certification — provided the growth is costed and the renewal fee is negotiated against it rather than accepted. The 24% economically-indicated renewal rate in our data is real demand. The problem is not that customers renew; it is that they renew on Oracle's framing rather than their own forecast, and they negotiate the renewal weakly because they have not done the certification analysis that would give them a credible walk-away. The strongest renewal negotiation always begins with a fully built certification number — the BATNA that tells Oracle you can leave.

This is also where Oracle's cloud-conversion motion intersects the decision. Increasingly, the renewal conversation is steered toward converting ULA entitlement into OCI or SaaS commitments rather than certifying perpetual licenses — a path that can quietly forfeit even more value than a low certification, because perpetual rights are exchanged for time-limited cloud credits. That dynamic is the subject of a sibling report in this series; for the term-end decision the rule holds: establish your certifiable perpetual entitlement first, value it, and judge every alternative — renewal, cloud conversion, or exit — against that baseline. The detail sits in our Oracle cloud licensing guide and our contract negotiation practice.

There is one more reason the renewal decision goes wrong so often: it is made under time pressure by people who do not own the budget consequences. The infrastructure team running the certification wants to clear the deadline; the procurement team wants to avoid a compliance gap; and Oracle's account team supplies a renewal quote that makes the choice feel safe and pre-decided. Nobody in that room has built the one number that should drive the decision — the dollar value of the perpetual entitlement the customer could certify today. Without it, "renew" is the path of least resistance, and Oracle knows it. Build the certifiable-entitlement figure first, put a real cost on it, and the renewal-versus-exit choice stops being a matter of nerve and becomes a matter of arithmetic — which is exactly the footing a buyer wants to negotiate from.

Why Do Oracle ULA Certifications Fall Short?

The shortfall has identifiable, repeatable causes, and naming them is the first step to closing them. The dominant cause is incomplete discovery. Most internal certifications scan production and stop there, missing the disaster-recovery and standby servers that carry the same licenses, the development and test estates running identical Enterprise Edition and options, the virtualized clusters whose deployable footprint dwarfs their running instances, and the database options enabled silently inside instances nobody interrogated. A count built on a partial estate is partial by construction, and no amount of care at submission recovers what discovery never found.

The second cause is timing. As the maximization data showed, the uplift available collapses as the term runs out, and 62% of organizations start with under 120 days left. A late start does two kinds of damage: it removes the runway to deploy and lock in additional entitlement, and it compresses the discovery into a window too short to be thorough, so even existing deployments get missed. Certification is not a month-end task; it is a year-long program whose most valuable work — deployment maximization — happens early and is impossible late.

The third cause is conflicted help. As Table 1 showed, customers who lean on the reseller that sold the estate or the SI that built it under-certify at 64% — barely better than going alone — because those parties have a relationship with Oracle and an interest in a fast, clean sign-off rather than a maximized one. Independence is not a nicety here; it is the variable that moves the under-certification rate from 81% or 64% down to 31%. An adviser whose only client is the buyer has no reason to leave entitlement on the table and every reason to find it.

The fourth cause is contractual misreading. The certifiable number is bounded by what the executed agreement actually granted — the named products, the territories, the legal entities in scope, and any per-product deployment caps. Customers who certify off the sales-era summary rather than the signed ordering document and schedules make errors in both directions: forfeiting entitlement they held, or over-declaring into rights they never had. The contract is the source of truth for the ceiling on a defensible count, and reading it precisely, before any number is built, is non-negotiable. These four causes are why our certifications run on a fixed sequence — read the contract, discover the full estate, maximize within rights, prove every line, then submit — the structure set out in the recommendations below and embodied in our ULA advisory work and across the broader Oracle database licensing guide.

Recommendations: How to Maximize Your ULA Certification

The under-certification gap is not bad luck — it is the predictable output of running Oracle's exit process without a buyer-side plan. The following sequence, run in order and started early, is what moves a certification from the 68% that forfeit value to the minority that capture it.

1. Open the certification window 12 months before term-end. Treat the final year as the maximization period, not the snapshot month. The achievable uplift collapses inside 120 days; the customers who capture the full median 41% start a year out.
2. Read the executed contract first, not the sales summary. Pull the signed ordering document and every schedule. Map the named products, territory restrictions, in-scope legal entities, and any per-product caps. This sets the ceiling on a defensible count and prevents both forfeiture and over-certification.
3. Run forensic discovery across the entire estate. Inventory production, DR, standby, development, test, virtualized clusters, subsidiaries, and authorized cloud BYOL. Interrogate every database for enabled options and packs. A production-only scan guarantees a shortfall.
4. Maximize deployment within your contractual rights. Bring forward every real, intended deployment — DR and standby builds, non-production estates, roadmap database options, eligible workload migrations — so it lands inside the snapshot. Deploy nothing you cannot operate and evidence.
5. Build the count on evidence, line by line. Reconcile every certified processor and NUP figure to discovery output, configuration records, and architecture documentation, so the number survives Oracle's scrutiny and any later audit.
6. Run the certify-versus-renew economics honestly. Value your certifiable perpetual entitlement, forecast genuine deployment growth, and renew only if costed growth clearly beats the renewal fee plus support. Use the built certification number as your walk-away in any renewal or cloud-conversion talk.
7. Keep the help independent. Do not let the reseller or SI run the certification. Engage an adviser whose only relationship is with you, then submit from a position of evidence rather than deadline pressure.

Continue Reading