When deployment grows past your certified count, the answer is a deliberate, sized license purchase, not a rushed return to an unlimited agreement. Buy for the gap you can document, use the same counting methodology you certified on, and keep the re ULA as a considered option rather than a reaction.
After certification your Oracle entitlement is a fixed number, and the estate keeps moving. New projects launch, an acquisition brings its own systems, a database is promoted from test to production. Sooner or later deployment grows past the count you certified, and at that point you need more licenses. How you buy them decides whether the growth costs what it should or far more. The discipline is simple to state and easy to skip under pressure: measure the gap, buy deliberately for it, and treat a return to an unlimited agreement as one option to be tested rather than the default. This article sets out when a purchase is needed, how to size it, and why the panic re ULA so often costs more than the problem it solves. As always the specifics depend on your contract and the products in scope, so use the framework here and confirm the detail against your own agreement.
You need to buy when deployment grows past the perpetual count you certified. The certified number is your fixed entitlement, and the unlimited right that once covered any growth is gone, so any processors or Named User Plus beyond the certified figure require new licenses. The common triggers are routine growth in existing systems, new projects that stand up additional Oracle instances, and acquisitions that add an estate you did not certify. None of these is a problem in itself. The problem is letting the growth happen without noticing, so that a manageable gap is discovered later as a compliance finding rather than handled in advance as a purchase. Knowing your certified count and watching deployment against it is what keeps the buying decision in your hands.
Growth past the certified count is a purchase, not a panic. The size of the purchase is a number you can measure. The cost of treating it as an emergency is not.
Start from the certified count as the baseline, measure the actual deployment that exceeds it, and apply the same processor and core factor rules you used at certification. The aim is to buy for the gap you can document plus planned growth you are genuinely confident in, not for a worst case that pads the order. A purchase grounded in the same methodology as your certification is defensible and proportionate, because it follows the logic Oracle already accepted at exit. Two mistakes are common. The first is buying too little, by measuring loosely and leaving a residual gap that surfaces in an audit. The second is buying too much, by accepting a sales sized estimate rather than a measured one. Both are avoided by treating the purchase as a counting exercise with the same rigour you brought to the certification.
| Step | What you do |
|---|---|
| 1. Baseline | Take the certified perpetual count as the fixed entitlement |
| 2. Measure | Count current deployment using the same metric and core factors |
| 3. Gap | Identify the documented shortfall above the certified count |
| 4. Plan | Add growth you are confident in, not a worst case estimate |
| 5. Buy | Purchase the gap plus confident growth, deliberately |
Usually not. Returning to a ULA to cover a shortfall, sometimes called a re ULA, can convert a small and definable gap into a large multi year commitment and reset the very cycle you just spent an exit escaping. It can be the right answer when growth is genuinely large, broad, and uncertain across many products, because in that narrow case unlimited deployment again has real value. But it is the wrong answer when it is reached for under audit pressure as a way to settle a finding, because the settlement then comes wrapped in years of fees and another certification to manage later. The test is straightforward. Compare the cost of buying exactly what the documented gap requires against the cost of a new unlimited term over its life. If the simple purchase is cheaper and the growth is definable, buy the licenses. Keep the re ULA for the case where the numbers genuinely favour it, decided in calm rather than in a deadline.
Consider an anonymized services firm that certified a database position and, eighteen months later, found that a new analytics platform had pushed deployment past the certified count on two products. Oracle raised the gap during a review and offered a return to an unlimited agreement to resolve it. Measured against the same methodology used at certification, the actual shortfall was modest and specific. The firm bought licenses for the documented gap plus a year of confident growth, closed the finding, and avoided a multi year commitment many times the size. The figures are indicative and the outcome turned on the firm's own contract, but the pattern is the one to remember: measure first, then choose the cheaper defensible path.
Buying well after the exit depends on the same evidence discipline that defends the certification itself. Read defending your certified counts in an audit for how the baseline holds up under review and the audit clause in your post ULA world for the contract terms that shape what Oracle can ask. For the wider context, see the post certification audit defense pillar.
You need to buy when deployment grows past the perpetual count you certified. The certified number is your fixed entitlement, so any processors or users beyond it require new licenses. Routine growth, new projects, and acquisitions are the common triggers. The right response is a deliberate, sized purchase of exactly what the growth requires, not a rushed return to an unlimited agreement.
Usually not. Returning to a ULA to cover a shortfall, sometimes called a re ULA, can convert a small, definable gap into a large multi year commitment and reset the cycle you just exited. It is sometimes the right answer for genuinely large and uncertain growth, but it should be a deliberate choice tested against a simple license purchase, not a reaction to audit pressure.
Start from the certified count as the baseline, measure the actual deployment that exceeds it, and apply the same processor and core factor rules you used at certification. Buy for the gap you can document plus planned growth you are confident in, not for a worst case. A purchase grounded in the same methodology as your certification is defensible and avoids paying for capacity you will not use.
Book a confidential assessment and we will measure your deployment against the certified count, size the gap, and help you buy deliberately rather than under pressure.