Cloud at Customer puts Oracle managed infrastructure inside your own data centre, which is why many agreements count it more like on premises than public cloud. Whether your deployment there converts at exit comes down to your contract wording.
By Daniel Voss · Ex Oracle LMS · 4 June 2026
Oracle Cloud at Customer places Oracle operated cloud hardware physically inside your data centre, so many ULAs count deployment on it on terms closer to on premises than to public cloud, without the continuous run condition that AWS and Azure deployment often must satisfy. That favourable treatment is common but not guaranteed. Where a contract predates this delivery model it may be silent, and silence is not inclusion. Read your cloud counting clause and any Cloud at Customer specific language, and confirm the treatment in writing before you rely on it at certification.
A ULA converts deployed quantities of named Oracle products into a perpetual entitlement at certification, and cloud counting is the part of that conversion most shaped by where workloads physically run. Public cloud is treated cautiously in most agreements. Many require a deployment in AWS or Azure to run a continuous period, commonly 365 days, before it counts toward the certification baseline, and some exclude public cloud altogether. The reasoning Oracle applies is that public cloud capacity is elastic and outside its control, so the contract guards against deployment that exists only briefly around the certification date.
Cloud at Customer changes that picture because the infrastructure, although operated by Oracle as a cloud service, sits physically inside your own facility, behind your own perimeter. That location is why many agreements count deployment on it on terms closer to traditional on premises deployment, without the continuous run condition. The hardware is in your building, the workloads are persistent, and the elasticity concern that drives the public cloud rules does not apply in the same way. For an organisation with eligible workloads, that treatment can make Cloud at Customer a stronger place to hold deployment heading into certification than a public cloud that will not count.
Often yes, and usually on better terms than public cloud, but only your contract gives the definitive answer. Three points decide it, and each needs reading against your specific wording rather than the general pattern.
Start with how your agreement counts cloud deployment generally. If the clause draws a clean line between public cloud, with its continuous run requirement, and infrastructure located on your premises, Cloud at Customer usually falls on the on premises side because the hardware is in your data centre. If the clause is written only around named public cloud providers, the treatment of Cloud at Customer may be undefined.
Newer agreements sometimes address this delivery model explicitly. Where they do, that language governs and removes the ambiguity. Where they do not, you are relying on the general clause and on how the contract defines the boundary between cloud and on premises, which is exactly the kind of question that should be settled before certification, not during it.
Many ULAs were signed before Cloud at Customer mattered, so the contract may simply not mention it. Silence is not inclusion. An undefined treatment is a question to resolve in advance, ideally confirmed in writing, rather than an assumption to carry into the count. The favourable on premises treatment is common, but common is not the same as certain.
Treat Cloud at Customer as a placement decision and confirm the counting treatment before you depend on it. If your contract counts it like on premises, it can be a strong home for deployment heading into certification, free of the continuous run trap that public cloud sets. If your contract is silent, resolve the ambiguity early, while there is still time to move workloads to a platform you know will count. The principle is the same one that governs all cloud counting at exit: deployment counts where your own wording says it counts, and the time to read the wording is before the migration, not after the certification letter is drafted.
Consider an anonymized public sector body running a significant Oracle estate on Cloud at Customer hardware in its own facilities, with a ULA approaching exit. Its cloud counting clause distinguished public cloud, with a 365 day continuous run requirement, from deployment located on its premises, and counted the latter without that condition. Because the Cloud at Customer hardware sat physically inside its data centres, the deployment fell on the on premises side and counted cleanly, with the evidence file recording the location and configuration of the infrastructure. A second anonymized organisation held an older ULA that named only public cloud providers and was silent on Cloud at Customer, so the treatment had to be clarified before exit rather than assumed. The figures are indicative and the difference came entirely from contract wording, which is the recurring lesson: the same delivery model counted differently because the two agreements described the boundary differently.
If any of your estate runs on Cloud at Customer, confirm how your contract counts it well before the term ends. Compare the broader menu of choices in the exit paths beyond certify or renew, see how relocating deployment to Oracle's cloud can convert excluded workloads in moving workloads to OCI before certification, and ground your planning in our ULA exit strategy guide.
Book a ULA assessment and we will read your cloud counting clause against your Cloud at Customer footprint, so the deployment converts at exit instead of being contested.