Can you certify cloud deployments under an Oracle ULA?
You can sometimes certify cloud deployments under an Oracle ULA, but it is contract dependent, because whether AWS, Azure, or OCI deployments count toward the certified quantity depends entirely on the specific terms of your agreement. Some ULAs permit public cloud and let those deployments convert into perpetual licenses at exit. Others restrict counting to environments the agreement names, or exclude public cloud altogether, in which case cloud you deployed in good faith may not certify.
This single question can move the certified number by millions, because cloud is often where deployment grew fastest during the term. The wider exit framework sits in the Oracle license compliance guide, and the broader audit exposure of the term is covered in audit risk during a ULA term.
Cloud at certification is decided by your specific ULA terms, not by a general rule. Read the cloud language early, because it determines whether the deployments you grew during the term become perpetual entitlement or vanish from the count.
How does Oracle count cloud at ULA certification?
Oracle counts cloud at ULA certification using its cloud licensing rules for the named programs, so the certifiable number depends on whether the ULA permits cloud and on how processors or vCPUs are counted on each platform. On the major public clouds, Oracle applies its own vCPU based counting conventions, which differ from on premises processor counting, and those conventions feed directly into the quantity you can certify. Getting the count method right for each platform is essential, because an error compounds across a large cloud estate.
The detail of counting cores on the public clouds is a discipline in itself, set out in counting vCPUs on AWS and Azure. The key point for certification is that cloud is counted differently from on premises, and the certified quantity must reflect those rules accurately to survive Oracle's review.
| Platform | Counting basis | Certifiable |
|---|---|---|
| On premises | Processors with core factor | Yes, named programs |
| AWS and Azure | vCPU based conventions | Contract dependent |
| OCI | OCPU based counting | Contract dependent |
What is the two sided risk?
The two sided risk is that you can certify cloud the ULA does not permit, which Oracle can strike from the count, or you can under count cloud that does qualify, which leaves perpetual entitlement on the table. Both errors are expensive. Over certifying invites a challenge that reduces your final number and can sour the exit. Under certifying quietly forfeits licenses you were entitled to convert, which you then have to buy again later.
Avoiding both requires reading the cloud terms precisely and counting accurately, neither assuming cloud counts nor assuming it does not. The discipline is the same line by line rigor that defends any Oracle position, applied to the certification rather than to a finding.
How do you maximise the certified count?
You maximise the certified count by deploying the named programs fully and legitimately before the certification date, within the terms the ULA permits, and by documenting every qualifying deployment so the number is defensible. A ULA rewards genuine deployment of the covered programs during the term, and the certification captures that deployment as perpetual entitlement, so the work is to ensure real, qualifying deployment is complete and recorded before exit.
- Confirm whether the ULA permits public cloud and on what terms
- Apply the correct counting convention for each cloud platform
- Complete legitimate deployment of named programs before exit
- Document territory, entity, and environment for each deployment
- Exclude any cloud the agreement does not permit from the count
Whether public cloud counts, and how it is counted, is contract dependent and written into your specific ULA. The certification turns on those exact terms, so read the cloud language before you build the count.
What is the buyer move?
The buyer move is to read the cloud terms early, count each platform by its correct convention, and build a documented certification that includes every qualifying cloud deployment while excluding what the agreement does not permit. Done well, this converts a fast growing cloud estate into durable perpetual entitlement. Done carelessly, it either invites a challenge or forfeits licenses, both of which cost real money at exit.
A worked example
Consider an anonymized retailer exiting a ULA with substantial Oracle deployment split between on premises and public cloud. The initial draft certification mixed cloud the agreement did not permit with cloud that qualified, and undercounted the qualifying platforms.
| Stage | Certified value |
|---|---|
| Draft, mixed and undercounted cloud | $6.0M |
| After excluding non permitted and correcting counts | $9.5M |
Removing the cloud the ULA did not permit avoided a challenge, while correctly counting the qualifying platforms recovered entitlement the draft had left out, raising the defensible certified value. This example is illustrative and anonymized, and outcomes depend on your estate, your contract and your evidence.
Your next step
Cloud can be the difference between a strong ULA exit and a weak one, and it is decided by terms most teams read too late. An independent buyer side review reads the cloud language, counts each platform correctly, and builds a certification that holds. Our advisors work on a Fixed Fee or Gainshare basis with no risk to you, and we reduce your Oracle exposure or we reimburse our service fee.
Bring your ULA to a strategy call and read the Oracle license compliance guide for the full certification framework.