At exit you face two strategies that pull in opposite directions. Maximize the certified count and lock in every defensible license, or shrink the Oracle estate and reduce what you support forever. The right answer is set by where your estate is going, not where it is now.
Growing the count captures free perpetual value, because support is flat and every defensible license you certify is yours forever at no extra fee. Shrinking the estate reduces the footprint you support after exit, which only pays if you genuinely intend to leave Oracle. Most organizations should maximize first and shrink later, but the order depends entirely on the roadmap.
Maximizing the count means measuring every defensible deployment and certifying as high as the evidence supports. Cloud, disaster recovery, non production, and virtualized environments are all counted properly, and the certified number lands well above a first estimate, often 1.5 to 2.5 times higher once these are handled correctly. The figure is indicative, but the direction is reliable: careful counting grows the number, and a bigger number is more perpetual entitlement.
Shrinking the estate means the opposite. You retire, migrate, or consolidate Oracle workloads before exit so there is less to certify and less to support afterwards. Every database you move to an open source engine, every Java workload you move to OpenJDK, every server you decommission, reduces the footprint that carries support cost into perpetuity. The strategies conflict because one adds to the certified number and one subtracts from it, and you cannot fully do both to the same workload.
A higher certified count is free value. A smaller estate is lower future cost. The tension between them is resolved by your Oracle roadmap, not by a rule of thumb.
Start with the fact that anchors everything: there is no fee for certification, and support continues at the ULA level regardless of the count you certify. A higher certified number does not raise your support bill. This is why maximizing is the default. If you are keeping Oracle, you capture every license you can defend at no extra cost, and the fear that certifying more raises support is a myth.
The case for shrinking turns on one question: are you actually leaving Oracle, and is the plan resourced? If you hold a credible, funded migration off Oracle databases or off Oracle Java, then an inflated certified count is licenses you will support for years and never use. Shelfware has a carrying cost. In that situation, reducing the estate before exit lowers the perpetual footprint and the support that rides on it. But the migration has to be real. An aspirational plan that never executes leaves you with both a smaller count and the same Oracle dependency, which is the worst of both.
| Factor | Grow the count | Shrink the estate |
|---|---|---|
| Best when | Oracle stays central to the roadmap | A funded migration off Oracle is underway |
| Certification fee | None | None |
| Effect on support | Flat, regardless of count | Lower footprint to support afterwards |
| Main risk | Certifying licenses you never deploy | Migration stalls and you lose the count too |
| Time sensitivity | Count what exists by the certification date | Migration must complete before exit |
The comparison shows why the decision is rarely either or. Many organizations maximize the count on the workloads they will keep, while shrinking the estate only where a migration is genuinely funded and on schedule. The skill is drawing the line correctly between the two groups.
For most ULA holders the right sequence is maximize first, then shrink deliberately afterwards. Certify the highest defensible count, since it is free and permanent, then run your migrations on your own timeline once the entitlement is secured. This protects you against the migration that slips: if the move off Oracle is delayed, you still hold the licenses, and if it succeeds, you simply stop using entitlement you already own at no penalty. Shrinking before exit only makes sense when the migration is so far advanced that the workloads will genuinely be gone by the certification date, and you would otherwise be certifying ghosts.
The mistake to avoid is shrinking on intention rather than execution. Reducing the estate in anticipation of a migration that has not happened forfeits a free, permanent count for a future saving that may never arrive. Where the plan is solid and funded, shrinking is sound. Where it is a slide in a strategy deck, maximize the count and keep your options open.
The decision rests on an honest read of your Oracle roadmap and the credibility of any migration plan. A maximization and exit review models both paths, the count you would certify and the footprint you would carry, so you can see the numbers before you commit. Two companion notes go deeper: keeping leverage when Oracle pushes OCI on handling the cloud pitch, and the exit alternative business case on pricing the options against each other. The wider method sits in our ULA exit strategy guide.
It depends on your roadmap. If Oracle stays central, maximize the certified count, since support is flat and a higher number is free value you keep forever. If you intend to move off Oracle, an inflated count is support you will pay on for years. The right strategy follows where the estate is going, not where it is today.
No. There is no fee for certification, and support continues at the ULA level regardless of the number you certify. A higher certified count is free perpetual value. The cost of support is set by the contract, not by how many licenses you certify, which is why maximizing is usually the default.
When you have a credible plan to reduce Oracle use, for example migrating to open source databases or OpenJDK, retiring workloads, or consolidating. Shrinking before exit lowers the perpetual footprint you support afterwards. It only pays if the migration is real and resourced, not aspirational.
We measure the count you could certify and the footprint you would carry, then map the sequence that fits your roadmap. Book a confidential assessment.