Many Oracle ULAs count public cloud toward certification only if it ran for 365 continuous days before the exit. The clause is easy to miss and expensive to discover late, because it can erase a large cloud footprint from your count overnight.
By the Meridian advisory team · Ex Oracle licensing analysts · Updated June 2026
It is a contract term that only counts public cloud deployments toward your certified baseline if they ran continuously for the 365 days immediately before certification. A real instance running in AWS or Azure that was stood up nine months before the exit fails the test, and so does an instance that scaled down to zero at any point in that year. The deployment exists, it is genuine, and it still contributes nothing to the count. This is one of the most common ways a confident cloud strategy collides with the fine print of a ULA, and it almost always favours Oracle at the exit.
If your agreement carries this clause, cloud you want to count must be running well before the final year opens. Discover the clause in the last quarter and the window has already closed. Discover it eighteen months out and you can still act.
Cloud counting is contract specific, and Oracle has refined the language over years. The 365 day rule exists because public cloud makes deployment effortless and reversible. Without a continuity test, an organisation could spin up enormous capacity days before certification, count it, and shut it down afterwards. The clause is Oracle's defence against exactly that. The difficulty for buyers is that the same rule also catches ordinary, legitimate cloud adoption that simply happened too late in the term, so a clause aimed at gaming ends up penalising honest deployment.
The first is timing. Anything deployed inside the final 365 days cannot, by definition, have run for the full window, so it is excluded. The second is continuity. A workload that existed for the whole year but paused, scaled to zero, or moved between regions in a way that breaks the continuity requirement can also fall outside the count. Both failures are invisible until someone reads the clause and maps the actual deployment history against it.
Usually not. The continuous deployment rule is typically written to apply to authorised public cloud, such as AWS and Azure, rather than to your own data centres. On premises deployments are normally counted on the standard installed and running basis, without the year long continuity test. This difference is precisely why on premises capacity becomes the safe harbour when the clause threatens your cloud count. That said, the reach of the clause is set by your specific wording, so confirm which environments it touches before you depend on the distinction.
The numbers below are indicative and exist only to show the effect.
| Cloud workload | Running since | Processors | Counts at certification |
|---|---|---|---|
| Azure production estate | 26 months before exit | 140 | 140 |
| AWS analytics platform | 8 months before exit | 90 | 0 |
| Azure burst capacity | continuous, but scaled to zero nightly | 40 | 0 |
On paper this is 270 processors of cloud deployment. Under a 365 day continuous clause, only the long running Azure production estate qualifies, so the count is 140. The analytics platform fails on timing and the burst capacity fails on continuity, erasing an indicative 130 processors. Caught early, the analytics platform could have been repatriated on premises or rebuilt on OCI in time to count, and the burst pattern could have been replaced with steady capacity. Caught late, the value is simply gone.
The clause punishes two things buyers do naturally: adopting cloud late and running it elastically. Neither is wrong operationally. Both are costly at certification if no one has read the counting terms in time to adjust.
Begin with the contract. Read the cloud counting language at least eighteen months before the term ends and confirm whether the 365 day rule is present, which providers it names, and how it defines continuity. Map your live cloud deployments against it and label each as qualifying, at risk on timing, or at risk on continuity. For the qualifying workloads, protect their continuity so nothing breaks the window. For the at risk workloads, decide early between repatriating them on premises, where the clause usually does not apply, and moving them to OCI, which many agreements treat more favourably. The one option you do not have is leaving the discovery until the certification window, because by then the year has already run.
The 365 day clause is one piece of how cloud counts at the exit. To act on the at risk workloads it catches, read moving cloud workloads to OCI before exit, and to understand how containerised cloud deployments are treated read containers in the cloud and ULA counting. For the whole exit picture, our Oracle ULA exit strategy guide is the pillar that brings the cloud, on premises, and timing decisions together.
It is a contract term that only counts public cloud deployments toward your certified baseline if they ran continuously for the 365 days before certification. Cloud instances stood up later in the term, or scaled up and down, fail the test and contribute nothing to the count even though they are real deployments.
Usually not. The continuous deployment rule is typically aimed at authorised public cloud such as AWS and Azure. On premises deployments are normally counted on the standard installed and running basis. Your exact wording governs, so confirm which environments the clause reaches before you rely on it.
Read the clause at least eighteen months before the term ends, then make sure any cloud you want to count has been running well before the 365 day window opens. For workloads that cannot meet it, plan to repatriate them on premises or move them to OCI in time, so the value is not lost.