Certification is the single event that converts unlimited Oracle deployment into a permanent entitlement, declared in a letter your contract usually requires a C level executive to sign. There is no fee to certify and support does not rise with the count, so the number you can evidence is the value you keep for free.
An Oracle Unlimited License Agreement gives you the right to deploy named products without counting for a fixed term and a fixed fee. That right ends on a single day. On that day you either certify the quantities you deployed during the term into a perpetual entitlement, or you renew the unlimited right for another term and a new fee. Certification is the buyer side opportunity of the whole agreement, because the count you declare becomes permanent and costs nothing to lock in. It is also the moment Oracle has refined to its own advantage, through the mechanics of what counts, how it is measured, and how the evidence is examined afterward.
This handbook walks the entire exit on the buyer side. We are an independent advisory. We are not a reseller, we hold no Oracle quota, and we sit on your side of the table. What follows is the method we run with clients, written so an IT asset manager, a procurement lead, an enterprise architect, or a general counsel can run the same sequence and defend the result to a board and, later, to an auditor.
What is an Oracle ULA and what does certification actually do?
A ULA is a contract that grants unlimited deployment of a defined set of Oracle products to a defined set of legal entities, in a defined territory, for a defined term that usually runs three to five years. During the term you do not count and you do not buy more licenses for the products in scope. You pay the agreed fee and the annual technical support that sits on top of it. In exchange you can deploy those products as widely as the business needs.
Certification is the act that ends the unlimited right and replaces it with a fixed perpetual entitlement. You measure how many units of each product you had deployed at the certification date, you declare those quantities to Oracle in a certification letter, and the declared numbers become your permanent licenses. From that day you own perpetual licenses equal to the certified count, you keep paying support at the ULA level, and any growth beyond the certified count requires new licenses bought deliberately. The single most important consequence is that the number is permanent. You do not get a second pass at it, which is why measuring and evidencing the largest defensible count is the whole game.
A standard ULA certifies at the end of the term. A capped ULA limits the unlimited right to a ceiling, so the count you can certify is bounded. A PULA is perpetual and has no certification exit at all, so the mechanics in this handbook apply differently. Confirm which shape you hold before you plan anything, because the exit you are entitled to depends entirely on the contract.
Certify or renew: which exit are you taking?
Every standard ULA ends with the same fork. You certify and convert, or you renew and defer. Certification keeps the deployed value as a permanent asset at no fee, caps your Oracle estate, and ends the unlimited right. Renewal keeps the unlimited right for another term and a new fee, defers the certification decision, and makes sense only when the deployment you will genuinely add during the next term, valued at what those licenses would otherwise cost, exceeds the renewal fee by a comfortable margin.
This handbook assumes you are heading toward certification, because that is the path that needs the most careful execution and the path where most value is won or lost. The renewal decision deserves its own model on your own figures, and we cover it in the certify or renew analysis. The discipline that protects you in either case is the same: measure the deployment and build the evidence file first, then decide, because a measured position is what gives you leverage whichever exit you choose.
What is the certification letter and who signs it?
Certification is completed by a formal declaration, usually called the certification letter, sent to Oracle within the window the contract specifies near the end of the term. The letter states the quantity of each product deployed as at the certification date, on the metric the contract uses, and it asserts that those quantities are accurate. The contract typically requires the letter to be signed by a senior officer of the company, often at C level, because it is a binding statement of fact that the perpetual entitlement is built on.
Two practical points follow. First, the signature means the number must be defensible before it is declared, not after, because a C level officer is attesting to it. Second, the letter is the document an auditor returns to in the years that follow, so every figure in it must be traceable to evidence you can produce on request. Treat the letter as the public face of a file, not as a form to be filled in at the last minute. The work that makes the letter safe to sign is the measurement and the evidence behind it.
The certification window, the exact wording the letter must use, the signatory level required, and the metric each product is declared on are all set by your specific agreement. In ULA work the answer almost always turns on the contract language. Read your certification clause before you measure anything, and confirm the window dates against the contract clock rather than a calendar assumption.
What counts toward the certified number?
The certified count is the sum of everything you had deployed, on the contract metric, at the certification date, within the entities and territory in scope. For most database and middleware products the metric is Processor, counted by multiplying the physical cores by the Oracle core factor for the chip. Some products and some agreements use Named User Plus, a count of distinct users and devices subject to per processor minimums. The handbook works the Processor case because it carries the most value in most estates, but the same discipline applies to Named User Plus.
The deployments that count are not only production. Test environments, development environments, and disaster recovery instances that were genuinely deployed within the term generally count toward the number, which is why a narrow production only view leaves entitlement on the table. The deployments whose treatment depends on the contract are the ones in public cloud and the ones inside virtualized clusters, and those are the two traps that decide whether a count lands at the low end of the range or the high end. We cover them in outline here and in depth in the cloud and partitioning guides.
| Deployment | Usual treatment | What governs it |
|---|---|---|
| Production on premises | Counts toward the certified number | Deployed within the term, on the contract metric |
| Test and development | Generally counts when deployed in term | Evidence that it was live before the certification date |
| Disaster recovery | Generally counts when deployed in term | Active or warm standby status and the contract definition |
| Public cloud, AWS or Azure | Depends on the contract | The authorized cloud clause and any continuous day test |
| Public cloud, GCP | Often does not count | Frequent contract silence, and silence is not inclusion |
| OCI | Frequently the most favourable | Oracle cloud terms in the agreement, still read closely |
| VMware clusters | Can be swept into the count | Oracle partitioning stance and the isolation you can prove |
A worked processor count, step by step
The method is simple arithmetic applied carefully. Take each group of servers running an in scope product, count the physical cores, multiply by the Oracle core factor for the processor type, and sum the result to a Processor figure for that product. The figures below are indicative and illustrate the mechanics for a mixed estate. Your own platforms, products, and contract language govern the real result.
| Server group | Cores | Core factor | Processor licenses |
|---|---|---|---|
| Production x86 cluster | 640 | 0.5 | 320 |
| Test and development | 240 | 0.5 | 120 |
| Disaster recovery, in term | 160 | 0.5 | 80 |
| Eligible OCI deployment | 128 | 0.5 | 64 |
| Defensible total | 1,168 | 584 |
The figure that matters is the defensible total, not the largest number you can imagine. Defensible means every line is supported by evidence you can produce: a host list, a tool output, a configuration record, and a clear note on why it counts under your contract. A count of 584 Processors that you can evidence is worth more than a count of 700 that collapses under examination, because the perpetual entitlement is only as strong as the file behind it. The figures are indicative and your environment and contract govern the result.
Indicative figures for one product. A narrow production only view leaves entitlement behind. Test, disaster recovery, and eligible cloud are where a defensible count grows, when each line is evidenced.
Why does support not rise when you certify more?
The most expensive misconception in certification is the belief that declaring a higher number raises your support bill. It does not. Support fees on a ULA are set at the ULA level and continue at that level after certification, regardless of whether you certify a thousand Processors or ten thousand. A higher certified count is free value, not a higher cost. The fear runs exactly backwards, and it costs buyers real entitlement every year they act on it.
This matters because the support myth is the lever most often used to push a team toward under counting or toward renewal. If people believe a large certified count will be punished with a larger support invoice, they declare cautiously and leave permanent licenses on the table. Within the bounds of what you can evidence, more is always better, because the marginal certified license is free to keep and free to support. Certify the largest number you can defend, and your support stays exactly where it is.
What is the evidence file and why does it matter as much as the number?
The certified number is a claim. The evidence file is the proof. It is the organised record that shows, for every line in the count, that the deployment existed within the term, that it was measured correctly, and that it counts under the contract. The file is what makes the C level signature safe, and it is the defense if Oracle examines the certification in the audit sensitive years that follow. A strong number with a weak file is a liability. A defensible number with a complete file is an asset.
A good file is built as you measure, not reconstructed under audit pressure later. It captures the host inventory, the tool outputs and scripts used, the methodology you applied, the core factor mapping, the contract clauses each decision relies on, and the dated snapshots that fix the position at the certification date. Build it once, build it well, and keep it. The reading on this is simple: the evidence file is the certification, and the letter is just its cover page.
Are Oracle LMS scripts an obligation or a choice?
Oracle License Management Services scripts are tools that collect deployment data from your environment. Running them is frequently presented as a required step in certification, but in most agreements it is a choice rather than an obligation, and the choice deserves analysis rather than reflex. The scripts produce data in Oracle's preferred format, which can be convenient, but they also shape the picture in ways that may not favour the buyer, and they hand a detailed view of your estate to the vendor at the most sensitive moment of the relationship.
The buyer side approach is to measure your own estate with your own tooling first, build the evidence file on your terms, and decide deliberately whether and how to use Oracle scripts to support the declared number. Where the contract genuinely requires a specified data collection, comply with the requirement while keeping your own independent measurement as the reference. The point is to enter certification with your own defensible number already built, so that any vendor data collection is checked against your position rather than defining it.
Cloud counting is contract specific, and many agreements require deployments in AWS or Azure to run a continuous period, often 365 days, to count. Read the detail in the cloud counting clause guide. Under Oracle's partitioning stance, soft partitioning does not limit scope, so a whole VMware cluster can be swept into the count, for better in a maximization context and for worse in an audit.
When should you start, and what happens in each phase?
Start the certification program nine to twelve months before the term ends. That runway is what turns a rushed declaration into a defensible one, because it leaves time to measure the estate, find and fix the cloud and virtualization positions, build the evidence file, and maximize the count deliberately rather than under deadline. Teams that begin in the final weeks declare what is easy to see and lose the entitlement that careful work would have secured. The clock is set by the contract, so confirm the exact term end and certification window against the agreement before you build the plan.
| Phase | When | What happens |
|---|---|---|
| Contract read | Month 12 to 11 | Confirm agreement shape, certification window, metric, entities, territory, cloud and partitioning clauses |
| Estate measurement | Month 11 to 8 | Inventory every in scope deployment across production, test, disaster recovery, cloud, and virtualization |
| Maximization | Month 8 to 5 | Make eligible cloud workloads count, manage virtualization scope, deploy planned growth before the date |
| Evidence file | Month 5 to 3 | Assemble host lists, tool outputs, methodology, core factor mapping, and dated snapshots |
| Declaration | Month 3 to 1 | Finalise the count, brief the signatory, prepare and submit the certification letter in the window |
| Aftercare | Post exit | Retain the file, govern growth beyond the certified count, prepare for audit risk in the first two years |
How do you maximize the defensible count?
Maximization is not inflation. It is the deliberate, evidenced work of ensuring every deployment you are genuinely entitled to count is counted, and that workloads which could count are positioned to do so before the window closes. The largest gains usually come from three places: bringing test and disaster recovery into the count properly, making eligible cloud workloads count by reading the clause and starting any continuous run early, and handling virtualization so that scope works in your favour rather than against you. Each move must be real and evidenced, because a number that cannot be defended is worse than a smaller one that can.
The deeper maximization moves, including repatriating workloads that will never qualify in public cloud, sequencing planned deployments before the certification date, and using the partitioning rules deliberately, are set out in the deployment maximization playbook. Run them inside the runway, not in the final weeks, because every one of them needs time and evidence to hold.
Do the scope traps change what you can certify?
Yes, and they bite at exactly the moment you have the least time to fix them. A ULA does not grant unlimited deployment to the whole world. It grants it to a defined customer, usually a named set of legal entities, in a defined territory, for the term. The certified count can only include deployment that sits inside that scope. Deployment in an entity that was never named, or in a territory the agreement excludes, does not count toward your certified number, and worse, it can become a compliance exposure that Oracle raises at certification as leverage.
The customer definition is the first trap. If the agreement names specific entities and your Oracle estate has spread to subsidiaries, joint ventures, or newly formed companies that were never added, those deployments are outside scope. The territory clause is the second trap. Where the agreement limits the territory, deployment outside it does not count and may trigger a remediation demand. The third and most common trap is corporate change during the term. Acquisitions, divestitures, and reorganisations move Oracle deployment across the boundary of the customer definition, and they do it on the calendar of the deal rather than the calendar of the ULA. An acquired estate is not automatically inside your ULA, and a divested one may take entitlement with it.
The defense is to map scope against the contract early, identify every entity and territory question, and resolve it before the certification date rather than during the declaration. Where corporate change happened during the term, document how it was handled against the customer definition. The reading on scope is simple: certification only captures what is inside the agreement, so the boundary of the agreement is part of the count, and it has to be managed against the ULA clock from the day notice of expiry is on the horizon.
What happens after the exit?
Certification is not the end of the work. Audit risk rises in the first two years after a certification, because the certified count is a fixed declaration that Oracle can examine, and the deployment that produced it keeps changing. The evidence file built during certification is the defense in that window. If it is complete, dated, and traceable, an examination confirms the number and closes. If it is thin, the same examination becomes a negotiation about quantities you can no longer reconstruct, which is the position the whole handbook is written to avoid.
Two aftercare disciplines protect the value you certified. The first is retention: keep the evidence file intact and accessible for at least the audit sensitive period, because the people who built it move on and the systems that produced it are replaced. The second is governance of growth. Once you have certified, the unlimited right is gone, so deployment beyond the certified count requires new licenses bought deliberately. The mistake to avoid is treating growth beyond the count as a reason to panic into a new ULA. Measured, planned license purchases for genuine growth are almost always cheaper than a fresh unlimited agreement bought under pressure, and they keep the estate inside a position you control.
The certification workbook
Use this as the cover checklist for your own program. Work the contract first, measure before you maximize, and build the evidence as you go so the letter is safe to sign when the window opens.
- Agreement shape confirmed as a standard ULA, capped ULA, or PULA, with the certification window and metric read from the contract.
- Scope mapped across the entities and territory in scope, with any corporate change during the term identified.
- Estate measured across production, test, development, disaster recovery, cloud, and virtualization, on the contract metric.
- Cloud positions resolved against the authorized cloud clause and any continuous day test, with eligible workloads made to count.
- Virtualization handled so partitioning scope works for you, with isolation and documentation in place.
- Count maximized and defensible, every line supported by evidence you can produce on request.
- Evidence file assembled with host lists, tool outputs, methodology, core factor mapping, and dated snapshots.
- Letter prepared and signatory briefed, with the declared number traceable to the file before the C level signature.
- Aftercare planned for retention of the file, governance of growth, and audit readiness in the first two years.
Common certification questions
The questions below come up in almost every certification. The answers hold as general guidance, and the specifics always depend on your agreement.
Is there a fee to certify? No. Certification itself carries no fee. You declare the deployed quantities and they become perpetual licenses, and you continue to pay support at the existing ULA level. The cost of certifying well is internal effort and advisory support, not a payment to Oracle for the conversion.
Will certifying a larger number increase my support bill? No. Support is set at the ULA level and does not rise with the certified count. This is the single most important fact to settle internally, because the fear that a large count is punished with higher support drives teams to under declare and leave permanent licenses behind.
What happens if I cannot evidence a deployment? If a deployment cannot be evidenced, it is not safe to certify, because the certified number must survive examination in the years that follow. The answer is to build the evidence during the runway rather than declaring numbers you cannot defend. A smaller defensible count is worth more than a larger one that collapses under audit.
Can I certify some products and renew others? This depends entirely on the contract, and it is one of the more contract specific questions in the whole exit. Some agreements allow a split treatment and some do not. Read the certification and renewal provisions together before assuming either path is available product by product.
What if my term is ending and I am not ready? A short, well negotiated extension can buy the time to build a defensible position, but it is a fallback rather than a plan. The better answer is to start the runway nine to twelve months out so that readiness is built before the window opens. Where an extension is genuinely needed, negotiate it deliberately rather than accepting a full renewal by default.
The next step
Certification is won in the measurement and the evidence, and it is permanent once the letter is signed, so the work is worth doing properly and doing early. If you would like the estate measured, the count maximized, and the evidence file built with you, on your contract and your figures, that is the work we do on the buyer side. For the full mechanics in context, read the Oracle ULA certification guide, and to make every eligible deployment count, read the cloud counting clause guide and the deployment maximization playbook.