Whether a cloud deployment counts toward your Oracle ULA certification is set by the contract, not by the cloud. Many agreements require AWS or Azure to run a continuous period before they count, some exclude public cloud entirely, and most are silent on GCP. Read the clause, then make eligible workloads count before exit.
A ULA grants unlimited deployment of named Oracle products for a fixed term. At the end you certify, and the count you can defend becomes your perpetual entitlement. When a large share of that estate runs in public cloud, a single set of contract clauses decides whether those deployments add to the number you keep or fall away at the worst possible moment. Cloud counting is where certified value quietly leaks, and where careful buyer side work recovers it.
This guide sets out how the clauses work, how the continuous day test interacts with your certification date, how each provider tends to be treated, and the sequence that turns an uncertain cloud position into counted entitlement. We are an independent advisory. We sit on the buyer side, we hold no Oracle quota, and every figure here is indicative because the answer depends on your specific contract language.
Why does cloud counting decide your exit?
Certification converts deployed quantities into permanent licenses at no fee. For on premises deployment the rule is straightforward: if it ran on the contract metric within the term and inside scope, it counts. Cloud breaks that simplicity, because Oracle does not own the hardware your workloads run on in AWS, Azure, or GCP, and the agreement therefore sets specific conditions on whether and how those deployments count toward the certified baseline. Those conditions are not standard across agreements, which is why two customers with identical cloud estates can certify very different numbers.
The stakes are highest for organisations that moved Oracle workloads to public cloud during the term. If the contract counts them, the cloud estate becomes free perpetual entitlement. If it does not, that same estate adds nothing to the certified number, and the licenses that would have supported it must be bought again after exit. The difference between those two outcomes is often a large share of the total value of the certification, and it is decided entirely by clauses most teams never read until it is too late.
It is worth settling one related fear at the outset, because it shapes behaviour. Counting more cloud deployment does not raise your support bill. Support on a ULA is set at the ULA level and continues at that level after certification regardless of the count, so a larger certified position, including the cloud lines, is free value rather than a higher cost. The instinct to minimise the cloud number to avoid a bigger support invoice is based on a myth, and acting on it simply throws away permanent entitlement. The discipline in cloud counting is therefore to capture every deployment you are genuinely entitled to count, not to keep the number small, because within the bounds of what the contract allows and what you can evidence, more counted cloud is always better.
What is the authorized cloud environment clause?
Most modern ULAs contain a clause, often called the authorized cloud environment provision or similar, that defines which third party cloud providers count toward certification and on what conditions. It typically names the providers, most often AWS and Azure, and sets the rule for how their deployments are measured. Where a provider is named and the conditions are met, those deployments count. Where a provider is not named, the deployments usually do not count, and the absence of a name is not an invitation to assume inclusion.
The clause matters because it is the gate. Everything else in cloud counting flows from whether your providers are named and whether their conditions are satisfied at the certification date. Read this clause first, word for word, and map it to your actual cloud footprint before you do anything else. Where the wording is ambiguous, treat the ambiguity as a risk to resolve in writing, not as a benefit to assume.
The list of named providers, the counting conditions, the measurement date, and any public cloud exclusion are all set by your specific agreement, and they vary widely. In cloud counting the answer almost always turns on the exact clause. Read your authorized cloud provision and confirm the treatment of each provider in writing before you rely on it.
How does the 365 day continuous test work?
The most common condition on cloud counting is a continuous deployment test. Many agreements require a deployment in a named public cloud to have run continuously for a set period, frequently 365 days, ending on or before the certification date, in order to count. The logic from Oracle's side is that a brief spin up of capacity just before exit should not inflate the perpetual entitlement. The consequence for the buyer is that timing is everything: a workload that will count must be in place and running early enough to satisfy the continuous period before the window closes.
This is the single most actionable point in the whole guide. If your contract carries a continuous day test, the clock has to start well before certification, which means cloud planning belongs at the start of the exit runway and not at the end. A workload deployed eleven months before certification will not satisfy a 365 day test, and no amount of evidence after the fact will change that. The continuous test rewards the team that read the clause early and penalises the team that discovered it late.
Indicative, against a 365 day continuous test ending at the certification date. Only the workload in place early enough satisfies the period. The figures depend on your contract and the exact measurement date.
What if the contract excludes public cloud, or is silent on a provider?
Two situations cost buyers the most. The first is an explicit public cloud exclusion, where the agreement states that deployments in third party cloud do not count toward certification at all. Where that exclusion applies, the cloud estate adds nothing to the certified number, and the only way to capture the value is to move eligible workloads to a counting environment before exit. The second is silence, most often on GCP. When a provider is not named in the authorized cloud clause, the safe and usually correct reading is that its deployments do not count, because silence is not inclusion. Assuming the opposite is the most common way organisations overstate a cloud position and then cannot defend it.
Both situations have the same response: identify the workloads that will never qualify where they currently run, and decide whether to repatriate them on premises or move them to OCI before the certification date so that they count. That decision is a planning exercise with a deadline, and it only works if it starts early. The detail on the GCP silence case is set out in the analysis of when the ULA is silent on GCP.
How is each provider usually treated?
Provider treatment is contract specific, but there are common patterns worth knowing as a starting point for reading your own clause. The table below summarises the typical position. Treat every line as indicative and confirm it against your agreement, because the same provider can be handled very differently in two contracts.
| Provider | Typical treatment | The condition to check |
|---|---|---|
| AWS | Often counts when named | The continuous test, frequently 365 days, met by the measurement date |
| Azure | Often counts when named | The continuous test, frequently 365 days, met by the measurement date |
| GCP | Often does not count | Frequent contract silence; confirm in writing, as silence is not inclusion |
| OCI | Frequently the most favourable | Oracle cloud terms in the agreement; still read the exact condition |
| Public cloud, excluded | Does not count at all | The exclusion wording; plan to repatriate or move to OCI before exit |
OCI tends to be treated most favourably because it is Oracle's own cloud, and many agreements count OCI deployment on terms closer to on premises than to third party cloud. That makes OCI a natural destination for workloads that will not qualify where they currently run, provided the move is genuine, evidenced, and completed in time. As always, read the OCI condition rather than assuming it, because favourable is not the same as automatic.
How do you make cloud workloads count? The eligibility sequence
The buyer side method is a short sequence run while the unlimited right still applies. It begins with the clause and ends with evidence, and the order matters because the continuous test makes early moves count and late moves worthless.
| Step | What you do | Why it matters |
|---|---|---|
| 1 Read the clause | Parse the authorized cloud provision, the named providers, and the continuous test | Defines the gate every cloud deployment must pass |
| 2 Map deployments | List every cloud deployment against the provider and the eligibility condition | Separates what already counts from what needs action |
| 3 Start the clock | Place workloads that need a continuous run early enough to satisfy the period | A late start cannot be fixed after the certification date |
| 4 Repatriate or move | Shift workloads that will never qualify on premises or to OCI before exit | Captures value the contract would otherwise leave behind |
| 5 Evidence it | Record dates, configurations, and continuous run proof for each deployment | Defends the cloud lines in the count if the certification is examined |
Each step is evidenced for the file that defends the number later. Cloud lines in a certified count attract scrutiny precisely because they depend on conditions, so the proof that a workload met the continuous test or that a move completed before the date is as important as the workload itself. A counted cloud deployment without that evidence is a weak line, and weak lines are where post certification audits concentrate.
Read the clause early, map every deployment to its eligibility, start any continuous clock at once, and move the workloads that will never qualify before the window closes. Cloud value is captured by timing, and timing only exists if you start the runway early.
A worked cloud counting example
The figures below are indicative and illustrate the method for a mid sized estate with a material cloud footprint and a contract that names AWS and Azure with a 365 day continuous test, is silent on GCP, and counts OCI favourably. Substitute your own clause and footprint and the structure holds.
| Workload | Where it runs | Processors | Counts as is |
|---|---|---|---|
| Core production | AWS, in place 2 years | 120 | Yes, test met |
| Analytics | Azure, deployed month 11 | 48 | No, test short |
| Reporting | GCP | 32 | No, silent |
| Batch | On premises | 64 | Yes |
| Counted as is | 184 | ||
| After moving analytics and reporting to OCI early | 264 |
In this illustrative case, the cloud position counts 184 Processors if left alone, because the late Azure analytics workload fails the continuous test and the GCP reporting workload is not named. Moving both to OCI early enough to satisfy the condition lifts the counted position to 264 Processors, a difference of 80 permanent licenses captured at no fee. The figures are indicative and your contract and timing govern the result, but the shape, where late and unnamed cloud quietly falls away unless it is moved, is common.
What is the measurement date, and how does a hybrid ULA change cloud rights?
The measurement date is the point at which deployment is counted for certification. In most agreements it is the certification date itself or a date close to it, and the continuous test is measured backward from that point. This is why the date is not a detail. A workload that satisfies a 365 day test on one measurement date may fail it on a date a month earlier, and the difference can be a material number of Processors. Confirm the exact measurement date your contract uses, because it is the line every cloud workload is measured against, and it determines how early any continuous clock must start.
Some agreements are not standard ULAs at all when it comes to cloud. A hybrid ULA folds specific cloud rights into the agreement, for example a defined entitlement to deploy in a named public cloud or in OCI on particular terms. Where you hold a hybrid ULA, the cloud counting rules are written into those provisions rather than left to a single authorized cloud clause, and they can be more generous or more restrictive than a standard agreement. The practical instruction is the same: read the cloud provisions that actually apply to your agreement, do not assume the standard pattern, and confirm in writing how each provider and each environment is counted. In cloud counting the contract is the only authority, and a hybrid agreement simply means there is more of it to read.
A further nuance is the difference between authorized and counted. An agreement may authorize deployment in a cloud provider, meaning you are permitted to run there under the unlimited right, without that deployment counting toward the certified baseline on the same terms. Authorization to deploy and eligibility to count are two separate questions, and conflating them is a frequent and expensive error. Always ask both: am I permitted to run this workload here, and will running it here add to the number I certify? The answer to the second question is the one that governs your exit.
Repatriate on premises or move to OCI?
When a cloud workload will not count where it currently runs, you have two ways to capture its value before exit: bring it back on premises, or move it to OCI. Both work, and the choice is a practical one driven by timing, cost, and the contract. Repatriation on premises is the most certain route to a counted deployment, because on premises deployment counts on the straightforward in term rule, but it carries the operational cost and lead time of standing up infrastructure you may have deliberately moved away from. Moving to OCI is frequently lighter, because OCI is often counted on favourable terms close to on premises, and the migration path from another cloud can be shorter than a full repatriation. The trade is certainty against effort, and the deciding factor is usually how much runway remains.
Whichever route you choose, the move has to be genuine and completed in time. A workload shifted to OCI a week before the measurement date, against a contract that applies a continuous test to OCI, has not solved the problem. The move must satisfy the actual condition the contract places on the destination environment, which means the OCI condition has to be read with the same care as the public cloud clause. Plan the move as a project with a hard deadline set by the measurement date and any continuous period, resource it properly, and evidence every step. A move that captures entitlement is worth real effort, and a move that misses the deadline captures nothing.
There is a third option that is sometimes overlooked: leave a workload where it is and accept that it will not count, when the cost or risk of moving it outweighs the entitlement at stake. Not every cloud deployment is worth recovering. The discipline is to value each one, prioritise the moves that capture the most defensible entitlement for the least disruption, and let the smaller or harder cases go rather than rushing a migration that will not satisfy the condition anyway. Maximization is about defensible value captured, not about moving everything.
How do you defend cloud lines after the exit?
Cloud lines in a certified count attract more scrutiny than on premises lines, precisely because they depend on conditions that can be tested after the fact. Audit risk rises in the first two years after certification, and an examiner looking at a cloud line will ask the same questions the contract asked: was this provider named, was the continuous period satisfied by the measurement date, and is there evidence that the deployment was genuinely in place. If the answers are documented, the line holds. If they rest on assertion, the line is where a post certification examination concentrates its pressure.
The defense is the evidence file, built as the cloud moves happen rather than reconstructed under audit pressure. For each counted cloud deployment, the file should hold the dated record of when the workload was deployed, the configuration that shows what was running and at what scale, the proof that any continuous period was met, and a note tying the line to the specific contract clause that makes it count. For workloads moved to OCI or repatriated before exit, the file should also hold the migration record and the date the move completed against the measurement date. The detail on building this record for cloud is set out in the analysis of evidence for cloud deployment counts. A counted cloud deployment with that evidence is an asset that survives examination. The same deployment without it is the weakest line in your certification.
The cloud counting checklist
Use this as the cover checklist for the cloud part of your certification program. Read the clause first, act on timing early, and evidence every cloud line.
- Authorized cloud clause read word for word, with the named providers and any public cloud exclusion identified.
- Continuous test confirmed, including the period length and the measurement date it runs to.
- Every cloud deployment mapped to its provider and its eligibility condition.
- Continuous clocks started for workloads that need a run, early enough to satisfy the period.
- Silent and excluded workloads decided, with a plan to repatriate or move to OCI before exit.
- OCI condition verified rather than assumed, with moves genuine and completed in time.
- Cloud evidence assembled, with dates, configurations, and continuous run proof for each line.
- Position reconciled to the wider certified count and the evidence file before the letter is signed.
Common cloud counting questions
A handful of questions come up in almost every cloud counting review. The short answers below hold as general guidance, and each one ultimately depends on the exact wording of your agreement.
Does moving to the cloud during the term reduce my certified number? It can, if the workloads land in an environment the contract does not count. A migration that felt like modernisation can quietly remove deployment from the certified baseline, which is why cloud moves made during a ULA term should always be checked against the counting clause before they happen, not after.
If my contract names AWS but not Azure, can I assume Azure counts too? No. A provider that is not named is generally not counted, and naming one provider does not extend to another. Treat each provider as a separate question answered only by the contract, and confirm any uncertain case in writing.
Can I spin up extra cloud capacity just before certification to inflate the count? Not where a continuous test applies. The test exists precisely to stop a late surge from counting, so capacity added in the final months against a 365 day condition will not qualify. The only capacity that helps is capacity in place early enough to satisfy the period.
Is OCI always the safe destination for workloads that will not count elsewhere? Often, but not automatically. OCI is frequently counted on favourable terms, which makes it a natural destination, but the OCI condition still has to be read and satisfied. Favourable is a starting assumption to verify, not a guarantee to rely on.
What if my contract says nothing about cloud at all? Silence on cloud is one of the most contract dependent situations there is, and it usually calls for specialist reading rather than a default assumption. An older agreement written before cloud was material may treat cloud deployment in ways neither party anticipated, so the wording, the definitions, and any deployment location language all need careful analysis before you rely on a position.
The next step
Cloud is where the certified count most often leaks, and the leak is almost always a timing problem hiding inside a clause. If you would like your cloud position read against your contract, mapped to your footprint, and moved into counting environments before the window closes, that is the buyer side work we do. For the providers that need the most care, read when the ULA is silent on GCP and evidence for cloud deployment counts, and for the full exit picture read the ULA exit strategy guide.