Undercounting an Oracle ULA at certification surrenders perpetual licenses for good. Because the event is irreversible and support stays flat whatever you certify, every legitimate deployment left out of the number is entitlement you can never reclaim and must buy again if you use it later.
By the Meridian advisory team, former Oracle LMS and GLAS licensing analysts. Updated 4 June 2026.
It costs the licenses you fail to certify, permanently. At the end of a ULA the count you declare converts to your perpetual entitlement and the unlimited rights end. A deployment legitimately running within the term that you leave out of that count does not roll over and cannot be added later. If you need that capacity afterwards, you buy it again at full price. The cost is doubly sharp because the marginal price of certifying more was zero: support fees stay flat at the ULA level regardless of the number you declare. Undercounting therefore gives up free value on the way out and creates a future purchase on the way back, which is the worst trade in the entire lifecycle.
Certifying a deployment you are entitled to count is free. Failing to certify it costs the full price of buying it later. The risk is one directional, which is why the discipline is to count everything you can defend.
Undercounting is rarely a single mistake. It is the sum of several quiet omissions, each of which removes real deployments from the number. Understanding the causes is how you prevent the cost.
The most common cause is simply not finding the whole estate. Servers that internal records miss, instances on networks nobody scanned, environments owned by a team outside the certification project: all of these are deployments that exist but never reach the count. Broad, independent discovery is the antidote, and the difference between a partial inventory and a complete one is often a large fraction of the final number. We set out the tools for this in discovery tooling for a ULA count.
Test, development, and disaster recovery instances deployed within the term are part of the deployment picture, and they are routinely left out because teams think of them as secondary. They are not secondary to the count. A disaster recovery site running the named products, or a development estate spun up for a major programme, can represent significant entitlement. Leaving them out is leaving licenses on the table.
Cloud counting is contract specific, and the error runs both ways. Some teams count cloud that the contract excludes, which creates exposure. Others fail to count cloud that does qualify, which creates undercount. Many ULAs allow deployments in AWS or Azure that meet the conditions, often a requirement to run for 365 continuous days, to count toward the certification baseline. Assuming cloud does not count without reading the clause surrenders that volume. The rule is to read the cloud clause and count what it allows, neither more nor less.
Applying a core factor that is too low, or counting cores incompletely, understates the processor licenses an estate represents. The core factor is a multiplier, so a conservative error scales across the whole count. Getting the factor right for each chip, as we describe in core factor math in a ULA exit, is part of claiming the full defensible number rather than a smaller, timid one.
The belief that certifying a higher count raises support fees makes teams deliberately hold the number down. It is false. Support does not move with the certified count. Every processor a team declines to certify out of misplaced caution is permanent entitlement surrendered for no benefit. This myth alone accounts for a meaningful share of the undercounting we see.
| Cause of undercount | What it removes | The fix |
|---|---|---|
| Incomplete discovery | Whole servers and instances | Broad independent discovery |
| Overlooked non prod and DR | Test, dev, recovery deployments | Document every environment |
| Cloud assumed out | Qualifying cloud volume | Read the cloud clause, count what counts |
| Conservative core factor | Processor licenses across the estate | Correct factor per chip, shown |
| Support myth | Count held down deliberately | Certify everything defensible |
The specific exposure in your case depends on your estate and your contract, so treat these as the common causes to rule out rather than a fixed diagnosis.
Take an indicative case. An organisation certifies a database ULA at 1,000 processor licenses, drawn from a partial inventory and a cautious approach to support. A complete count would have reached 1,600: the missing 600 sit in an unscanned data centre, a disaster recovery site, a qualifying cloud estate, and a corrected core factor. Those 600 processors had a marginal certification cost of zero, because support was flat. After certification, the organisation grows into part of that capacity and has to license 300 processors it could have certified for nothing, now at full purchase price. The undercount converted free entitlement into a real, avoidable purchase. The figures are indicative, but the shape, free on the way out, expensive on the way back, is exactly how the cost lands.
Prevention is method. Discover the estate broadly and independently, document every environment including non production and disaster recovery, read the cloud and contract clauses before deciding what qualifies, apply the correct core factor to each chip and show the working, and set aside the support myth entirely. Build the evidence file as you go, so the larger number you reach is also a defensible one. The aim is a count that is both complete and provable, captured before the irreversible letter is signed. The full process sits in our pillar, the Oracle ULA certification guide.
Undercounting is the quiet, expensive failure of a ULA exit. It surrenders perpetual entitlement that cost nothing extra to certify and forces a future purchase to recover the same capacity. The causes are known and the fix is disciplined counting backed by evidence. Count everything you can legitimately defend, because the only number you keep is the one you declare, and you declare it once.
It costs the perpetual licenses you fail to certify, permanently. Every legitimate deployment left out of the count is entitlement you cannot reclaim, because the certification is irreversible and support stays flat whether you certify it or not. Future use of that capacity then has to be licensed again, at full cost.
Usually because of incomplete discovery, overlooked non production and disaster recovery instances, cloud volume that was wrongly assumed not to count, conservative core factor work, and the myth that a higher count raises support. Each cause removes real deployments from the number, and together they can understate a count by a wide margin.
Book a confidential assessment and we will find every deployment you are entitled to count before the certification closes the door.