Where public cloud will not count toward your certification, OCI often will. Moving eligible Oracle workloads before the term ends can turn excluded deployment into permanent entitlement, if the contract and the evidence support it.
By Daniel Voss · Ex Oracle LMS · 4 June 2026
Moving Oracle workloads to OCI before certification can raise your certified count, because many ULAs count OCI deployment on terms more favourable than public cloud, which often requires a continuous run of a period such as 365 days to count. Where your agreement counts OCI without that wait, relocating genuine, operational workloads there before the term ends converts deployment that public cloud rules would exclude into perpetual entitlement. The gain is real only when the move is genuine, completed inside the term, and backed by an evidence file. Your own cloud clause decides whether it works.
A ULA grants unlimited deployment of named Oracle products for a fixed term, then converts the deployed quantity into a perpetual entitlement when you certify. Cloud counting is the part of that conversion that catches organisations out, because it is contract specific and rarely generous toward public cloud. Many agreements require a deployment in AWS or Azure to run a continuous period, commonly 365 days, before it counts toward the certification baseline. Some exclude public cloud entirely. Contracts are frequently silent on a given provider, and silence is not inclusion.
OCI sits in a different position in many agreements. Because it is Oracle's own platform, ULAs more often count OCI deployment cleanly and without the continuous run requirement that constrains public cloud. That asymmetry is the whole point of this lever. If you have workloads that will not count where they sit today, and your contract counts OCI on better terms, relocating them before the term ends can move deployment from the excluded column into the certified column. This is not a trick. It is using the unlimited right you already paid for to place deployment where your own contract will recognise it.
Sometimes, and the gain depends on three things being true at once: your contract must count OCI on favourable terms, the workloads must be eligible to move, and the move must be completed and evidenced inside the term. Miss any one and the benefit does not materialise.
Read your cloud clause before you move anything. The favourable OCI treatment is common but not universal, and the exact wording governs whether OCI deployment counts at full value, on a core basis, or under any condition. Where the clause is silent or ambiguous, treat that as a question to resolve, not an assumption to rely on. The contract decides, and only your contract.
The deployment must be a real Oracle workload doing real work. Standing up production, test, or disaster recovery instances on OCI that serve an actual operational purpose is within your ULA rights during the term. A nominal instance created to inflate a number, with no role and no run history, is poor practice and invites challenge. Eligibility also depends on whether the workload can technically and operationally run on OCI in the time available.
Everything must be deployed within the term. Certification fixes the count at a point in time, so a move that completes after the term ends captures nothing. This is why the OCI question belongs in exit planning months ahead, not in the final weeks. A migration takes time, and the deployment needs to be live and documented before the window closes.
Decide where deployment should sit at certification, then move it on purpose and document the move. The certified count is fixed by where workloads run inside the term, so placement is a lever you control if you plan early. Read the cloud clause first, identify which workloads will not count where they are, confirm OCI counts under your wording, and relocate the genuine ones with an evidence file that records deployment dates, configuration, and operational role. The discipline is the same whether you are protecting a count or maximizing it: real deployment, completed in time, supported by evidence.
Consider an anonymized retailer approaching the end of its ULA with a block of Oracle workloads running in a public cloud whose continuous run requirement they would not meet before the term ended. Left in place, that deployment would not count, and the entitlement behind it would be lost at certification. Their agreement counted OCI without the continuous run condition. By planning the move several months ahead, relocating the genuine workloads, and documenting each one with deployment dates and operational evidence, they brought that deployment into the certified count rather than forfeiting it. The uplift here is indicative, and it only worked because their specific cloud clause counted OCI on favourable terms. A different contract could have produced a different answer, which is exactly why the clause has to be read before the migration is planned.
If workloads sit in a cloud that will not count, map your options against your own cloud clause well before the term ends. See the full menu of choices at exit in the exit paths beyond certify or renew, understand how a related delivery model is treated in Cloud at Customer and the ULA, and ground your planning in our ULA exit strategy guide.
Book a ULA assessment and we will read your cloud clause, identify the deployment that will not count, and plan the moves that turn it into perpetual entitlement.