What is ULA certification?
Oracle ULA certification is the formal close of an Unlimited License Agreement. At the end of the term, the customer must declare to Oracle, in writing and under signature, the quantity of each in scope product it has deployed, expressed in the contract's licensing metric, which for the database and its options is almost always processors counted through the core factor table. Oracle reviews and accepts the declaration, and from that point the customer holds a perpetual licence for exactly the quantity certified. The unlimited deployment right ends, and ordinary per unit licensing resumes for any future growth.
Because the certified quantity becomes a permanent entitlement, certification is not an administrative formality but the realisation of the entire agreement's value. A customer that deployed widely during the term but certifies conservatively gives away perpetual licenses it paid for and will never recover. A customer that prepares carefully and certifies the full legitimate footprint locks in an asset that would have cost many times the ULA fee to buy outright. The mechanics are the same in every ULA; the outcomes differ entirely on preparation. The wider context sits in the Oracle ULA pillar guide.
The certification timeline
The certification window is fixed by the contract, typically a period of thirty to ninety days around the term end date, and missing it has consequences. Most agreements provide that if the customer does not certify within the window, the unlimited right simply lapses and the customer is left holding whatever it can subsequently prove, often a weaker position than a timely certification would have produced. The window is not the time to begin counting; it is the time to submit a count that was prepared over the preceding months.
Certification is prepared over the final year of the term, not in the final month. The customers who certify well start the inventory while there is still time to deploy more.
The disciplined approach treats the last twelve months of the term as a certification runway. During that period the customer completes any planned deployments, builds an independent inventory of every in scope installation, reconciles that inventory against the contract metric, and resolves any ambiguity in its own favour before Oracle is involved. Approaching the window with a finished, defensible count converts certification from an anxious negotiation into a confident submission, and it is the foundation of a clean exit strategy.
What you can legitimately count
The certification captures every legitimate deployment of an in scope product that is installed and running on the certification date. For the database this means production environments, but it frequently also includes standby, disaster recovery, and test environments where the contract and Oracle's policies permit them to be licensed and counted. The contract language governs precisely what qualifies, which is why reading it closely, rather than relying on Oracle's verbal guidance, is essential. Environments that the customer assumed were uncountable are sometimes countable, and the reverse is also true.
The most consequential question is whether deployments in third party public clouds can be counted. Many ULAs contain a clause that excludes counting instances in authorized cloud environments such as Amazon Web Services and Microsoft Azure, and where that clause exists, cloud deployments cannot be certified regardless of how real they are. This single clause can halve the value of a certification for a customer that migrated to cloud during the term, and it must be checked before counting begins. The full treatment is in counting cloud deployments at ULA certification.
| Environment | Usually countable? | Condition |
|---|---|---|
| Production on premises | Yes | Installed and running at cut off |
| Standby and disaster recovery | Often | Where contract permits, check failover terms |
| Test and development | Sometimes | Depends on contract and metric |
| Public cloud instances | Only if allowed | Check the cloud counting clause |
| Oracle Cloud Infrastructure | Frequently favourable | Subject to specific contract terms |
How deployments are measured
For the database and its options, the metric is the Oracle processor, derived by multiplying the physical cores by the core factor for the processor type and rounding as the contract specifies. Applying the core factor correctly matters because it directly scales the certified number, and the difference between a correct and a conservative application across a large estate is substantial. The customer that understands the core factor table and applies it accurately certifies more than the customer that lets Oracle's measurement scripts produce a number it does not check.
The evidentiary basis of the count should be the customer's own inventory, not Oracle's data collection. Oracle offers measurement scripts and review assistance, and while these are not inherently adverse, they frame the count on Oracle's terms and interpretation. The buyer side discipline is to hold an independent ground truth, the same principle that governs Oracle audit defence, so that the certified number is the customer's own defensible figure rather than Oracle's. Disagreements about measurement are far easier to resolve when the customer arrives with complete data.
The mistakes that understate certification
The recurring errors are predictable. The first is late deployment, where the customer leaves planned rollouts until after the certification date and forfeits the right to count them. The second is omitting countable environments, most often standby and disaster recovery instances that the customer wrongly assumed could not be included. The third is conservative measurement, applying the core factor or rounding in Oracle's favour out of caution. The fourth is failing to check the cloud clause, and either omitting countable cloud instances or, worse, certifying cloud instances the contract excludes and inviting a dispute.
The fifth and most damaging is allowing Oracle to lead the count. When the certification number is produced by Oracle's scripts and interpretation, it reflects Oracle's commercial interest in keeping the customer's perpetual entitlement modest and the renewal attractive. The remedy for all five is the same: prepare early, count independently, read the contract for what genuinely qualifies, and submit a complete figure that the customer can defend. These disciplines feed directly into the negotiation strategy for the term end decision.
Maximising the certified number
Maximising certification is not about overstating the count; it is about ensuring that everything which legitimately counts is deployed, installed, and captured before the cut off date. The single largest lever is deployment timing. Any production rollout the business intends to make should be completed and running before the certification date, because the unlimited right ends with the term and a deployment made the week after the cut off must be licensed at full price. A customer that knows it will need forty more processors of the database in the coming year, and has the right to deploy them under the ULA, should deploy them before certification rather than buy them afterward.
The second lever is the completeness of the inventory. Large estates routinely contain installations that the central licensing team is unaware of: instances spun up by project teams, embedded databases inside packaged applications, standby and disaster recovery environments maintained by infrastructure teams, and test systems that were never catalogued. Each of these, where it runs an in scope product and the contract permits counting, contributes to the certified entitlement, and each is commonly missed. A thorough discovery exercise across the whole environment, not just the systems the licensing team already knows about, frequently uncovers material quantities that would otherwise go uncounted.
The certified number is not what you happened to deploy. It is what you deliberately deployed and then proved you deployed. Both halves require work.
The third lever is correct measurement. For the database, the certified quantity depends on applying the core factor table accurately to the right processor types, and on rounding as the contract specifies rather than as Oracle's scripts default. A conservative or incorrect application of the core factor across hundreds of cores can understate the entitlement by a significant margin, and the difference is permanent. The customer that understands its own hardware, maps each server to the correct core factor, and applies the contract's rounding rules in its favour certifies materially more than the customer that accepts a number generated without scrutiny. All three levers reinforce the same principle established in the exit strategy guide: the certified number is an asset the customer builds deliberately, not a figure it discovers at the deadline.
The buyer side view
The practical takeaway is that certification rewards preparation and punishes passivity, and the gap between the two is permanent. The customer who runs the final year as a certification runway, deploys everything planned before the cut off, counts independently and accurately, and submits a complete, defensible declaration will certify the full value the ULA was capable of delivering. The customer who waits for the window, accepts Oracle's count, and certifies conservatively will leave perpetual licenses on the table forever.
Start the inventory early, resolve every ambiguity in your own favour with the contract in hand, and treat the certification as the realisation of an asset rather than a compliance chore. To work through certification on your own agreement, read the ULA pillar guide, the exit strategy guide, and engage the ULA negotiation service well before the term ends.
Oracle ULA: frequently asked questions
When does Oracle ULA certification happen?
Certification happens at the end of the ULA term, within a contractual window that is usually thirty to ninety days around the term end date. Missing the window can cause the unlimited right to lapse, so the count should be prepared in advance. See the ULA pillar guide.
What can you count at ULA certification?
You can count every in scope product installed and running at the cut off date, typically including production and often standby and disaster recovery environments where the contract permits. Public cloud instances count only if the contract allows. See counting cloud deployments.
How are deployments measured at certification?
Database deployments are measured in Oracle processors, calculated by multiplying physical cores by the core factor and rounding per the contract. Applying the core factor correctly directly affects the certified quantity, so it should be the customer's own defensible figure.
What happens after you certify a ULA?
After certification, the declared quantities become permanent perpetual licenses, the unlimited deployment right ends, and any future growth requires new purchases at prevailing prices. The decision to certify or renew is covered in the exit strategy guide.