Certification is your one chance to convert unlimited deployment into permanent value. Counted properly, with cloud, disaster recovery, test, and virtualization handled correctly, certified counts often land 1.5 to 2.5 times higher than the first estimate. There is no fee, and support does not rise with the count, so the work is pure upside.
A ULA grants the right to deploy named Oracle products without limit for a fixed term. At the end of that term, certification turns the quantity you have deployed into a perpetual entitlement that you keep forever. The certified number is therefore the prize. Most organisations leave part of it on the table, not through any rule against them, but because the first count is built quickly, from incomplete data, by people who are nervous about declaring too much. This playbook is about counting completely and counting correctly, so the number you certify reflects everything the agreement actually entitles you to keep.
We are an independent, buyer side advisory. We carry no Oracle quota and no reseller conflict. The moves in this paper are legitimate uses of rights you already hold under the agreement, evidenced for the file that defends them. None of this is about inventing deployment. It is about making sure real, eligible deployment is found, stood up where it should be, and counted before the window closes.
Why the first count is almost always low
The first certified estimate is usually built from a license management spreadsheet and a few production server lists. It misses the deployments that sit at the edges of the estate, and those edges are where the volume hides. Disaster recovery instances that run continuously are forgotten. Test and development environments deployed during the term are excluded out of habit. Cloud deployments are left out because nobody is sure whether they count. Virtualized clusters are counted as a handful of named hosts rather than the full footprint the partitioning rules allow. Each omission is a quantity the customer is entitled to certify and keep, given away because the count was rushed.
Certified counts often land 1.5 to 2.5 times higher than the first expectation once cloud, disaster recovery, test, and virtualization are handled properly. The figure is indicative and depends on the estate and the contract, but the direction is consistent. The first number is a floor, not a ceiling.
How Oracle processor counting works
Processor licensing counts physical cores and applies a core factor that depends on the processor type. The deployed processor count is the sum, across every eligible server, of the physical cores multiplied by the applicable core factor. For most modern Intel and AMD server processors the core factor is 0.5, so two physical cores count as one processor license. Some processors carry a factor of 1.0, and a few carry lower factors. The factor is set by Oracle's published core factor table, and using the right factor for each server is the difference between an accurate count and a guess.
Every eligible deployment in scope during the term contributes to the number. That includes production, and it includes test, development, and disaster recovery instances that were deployed while the unlimited right applied. The counting task is to find every eligible server, record its cores and processor type, apply the correct core factor, and document the evidence, so the total is both maximised and defensible.
A worked processor count
The table below shows the same estate counted two ways. The first column is the rushed count that looks only at production database servers. The second is the complete count that includes disaster recovery, test, and a correctly measured virtualization footprint. The figures are indicative.
| Environment | Cores | Core factor | First count | Complete count |
|---|---|---|---|---|
| Production database | 320 | 0.5 | 160 | 160 |
| Disaster recovery, continuous | 320 | 0.5 | 0 | 160 |
| Test and development | 160 | 0.5 | 0 | 80 |
| Virtualized cluster, eligible hosts | 192 | 0.5 | 24 | 96 |
| Certified processors | 184 | 496 |
The complete count is 2.7 times the rushed count in this illustration. Nothing has been invented. The disaster recovery site was always running, the test estate was always deployed under the agreement, and the virtualized cluster was always larger than the few hosts the first pass recorded. The difference is entirely in the thoroughness of the count and the quality of the evidence behind it.
Indicative. The uplift comes from counting eligible environments that the first pass omits, each backed by evidence for the file.
Where the uplift comes from
The volume sits in four places, and each needs handling on its own terms.
Disaster recovery and standby
Disaster recovery instances that are installed and running during the term generally count, and they often mirror production core for core. A standby site can therefore double the production contribution on its own. The evidence is the server inventory and the configuration that shows the instances were deployed within the term.
Test, development, and non production
Environments deployed under the unlimited right count toward the certified number even though they never serve a production workload. Teams routinely exclude them out of caution. They are eligible, and they should be measured and certified like any other deployment.
Cloud deployments
Cloud counting is contract specific. Many agreements require a deployment in AWS or Azure to run for 365 continuous days to count toward the baseline, some exclude public cloud, and many are silent on a provider, where silence is not inclusion. Where a workload will not qualify, it can sometimes be repatriated on premises or moved to OCI before exit so that it does count. The cloud clause has to be read precisely, which is why we treat it in its own paper.
Virtualization
Under Oracle's partitioning stance, soft partitioning does not limit licensing scope. In an audit that rule sweeps an entire cluster into the count and works against the customer. In a maximization context the same rule works for the customer, because eligible deployment across a virtualized cluster can be counted to its full extent while the unlimited right still applies. Isolation and documentation decide how the rule lands.
The partitioning stance that creates audit risk after exit is the same stance that supports a larger certified count before exit. Inside the window it is a tool. After certification it becomes an exposure. Counting deliberately while the unlimited right still applies is how you use it rather than suffer it. See the VMware sweep defense guide.
How do you maximise a certified count legitimately?
You run a deliberate sequence inside the certification window, while the unlimited right still applies. The aim is to find all eligible deployment, stand up the capacity you genuinely need before the window closes, and evidence every number for the file. The moves below are legitimate exercises of rights you already hold.
- Discover the full estate. Inventory every server running a named product, across production, disaster recovery, test, development, cloud, and virtualization, not just the production list.
- Apply the correct core factors. Record the processor type for every server and apply the right factor from the core factor table, rather than assuming a single value.
- Stand up capacity you will actually use. If a project on the roadmap needs Oracle within the next year, deploy it under the unlimited right now so it counts, rather than buying it as a new license later.
- Repatriate cloud that will not count. Where the cloud clause excludes a workload, move it on premises or to OCI before exit so the deployment is eligible.
- Count the virtualization footprint fully. Measure the eligible cluster to the extent the partitioning rules allow, with isolation and documentation in place.
- Build the evidence file. For every number, keep the server lists, tool output, and methodology that prove the deployment existed within the term.
- Certify the defensible maximum. Declare the largest number the evidence supports, because there is no fee and support does not rise with the count.
What maximization is not
A buyer side advisor has to be clear about the line. Maximization is counting real, eligible deployment completely and evidencing it well. It is not fabricating deployment that did not exist, backdating installations, or declaring servers that were never running a named product. A number you cannot evidence is a liability, not an asset, because the audit that can follow certification will test it. Everything in this playbook is about finding and proving genuine entitlement, which is exactly what survives scrutiny later.
The value you are protecting
The certified count is not an abstract figure. It is the quantity of perpetual licenses you keep for free, and it sets the headroom you have before any future growth requires new purchases. A count that lands at its true ceiling means more permanent entitlement, more room to grow without buying, and a stronger position if Oracle audits in the two years that follow. A count left low means paying again for licenses you were already entitled to certify. The work pays back directly, and it pays back only once, because certification happens once.
What counts as eligible deployment, how cloud is treated, and how virtualization is scoped are all set by your specific agreement. The figures in this paper are indicative and the moves are contract specific. Confirm the mechanics against your own ULA before you act on any of them.
The next step
The size of the uplift depends on how complete the count is and how well it is evidenced, and that is precisely the work we do inside the certification window. If you would like your real ceiling measured, with the moves run and the evidence file built, that is a deployment maximization engagement. For the wider picture, read the deployment maximization guide and the Oracle ULA certification guide.