When a ULA will not count a public cloud deployment, that capacity is at risk of converting into nothing at exit. Repatriating those workloads on premises or onto OCI before the term ends can turn them into certified entitlement. This is a timing exercise, and the clock is set by your contract.
Yes. Where a contract does not count public cloud deployments, repatriating those workloads on premises or onto OCI before the term ends can convert them into deployments that certify as perpetual entitlement. The move has to be genuine, completed inside the term, and evidenced, and there must be enough runway for any continuous run clock to complete. Done late, the workload simply will not qualify and the capacity is lost at exit.
A workload that will not count where it sits is value waiting to be stranded. Moving it to ground that counts, with time to spare, is the difference between a permanent license and a future purchase at list.
Cloud counting is contract specific, and the differences decide everything. Many ULAs require a deployment in AWS or Azure to run 365 continuous days before it counts toward the certification baseline. Some exclude public cloud entirely. Many contracts are silent on Google Cloud, and silence is not inclusion. If a workload sits on a platform the contract excludes, or cannot satisfy a continuous run clause before the term ends, it will not contribute to your certified number no matter how real it is. That is the gap repatriation closes.
Deployments in your own data centers are the most straightforward to count, because they sit on infrastructure you control and are measured by processor with the relevant core factor. Bringing a workload back on premises inside the term puts it on the firmest possible ground for certification.
OCI is Oracle's own platform, and many agreements treat deployments there more favorably than third party public cloud. For workloads that are not practical to run on premises, moving to OCI can be the cleaner route to a deployment that counts. Whether OCI counts without condition still depends on the specific contract language, so the clause is read before anything moves.
Repatriation is a planning exercise above all. The deployment has to be live and stable on the counting platform before the term ends, and where a continuous run clause applies, the clock has to finish inside the term as well. That can push the real deadline many months ahead of the expiry date. The sequence matters too. Move the workload, let it run and settle, capture the evidence of its date and host, and only then approach certification. A rushed move in the final weeks produces a deployment that is neither stable nor documented, and a reviewer treats that exactly as it looks.
A retailer ran a sizeable Oracle estate in a public cloud that its ULA excluded from the count. Left in place, that capacity would have certified as zero and been repurchased afterward at list. With a year of runway, the workloads were migrated, part on premises and part to OCI, both completed and evidenced inside the term. At certification the repatriated deployments counted, the perpetual number rose materially, and support stayed flat at the ULA level. Figures are indicative and depend on the specific contract language.
A move only adds durable value when the destination deployment is real and recorded. Keep the workload genuinely operational rather than a shell that exists for the count. Document the migration date, the host, and the workload so the deployment can be traced. Stay inside the customer definition and territory your contract defines, since a repatriated workload in an out of scope entity creates remediation rather than entitlement. Audit risk rises in the first two years after certification, and a moved workload with a clean evidence trail is what carries the count through a later review.
Whether public cloud counts, which providers a continuous run clause covers, how OCI is treated, and what scope your deployments must sit inside all come from the specific agreement. Two firms can make opposite decisions about the same workload because their contracts read differently. In ULA work the answer almost always depends on the specific wording, so any repatriation plan is built against your own contract and its clock, not a general rule.
If cloud capacity may not count under your contract, the time to decide is now, because repatriation needs runway. Start with the deployment maximization pillar guide, then read the deployment maximization guide and standing up capacity you will actually use.
Yes, where a contract does not count public cloud deployments, repatriating those workloads on premises or to OCI before the term ends can convert them into deployments that certify. The move has to be genuine, completed inside the term, and evidenced, and there must be time for any continuous run clock to complete.
Cloud counting is contract specific. Many ULAs require a deployment in AWS or Azure to run 365 continuous days to count, some exclude public cloud entirely, and many are silent on Google Cloud, where silence is not inclusion. If the workload will not satisfy the clause, it will not count where it sits.
Often yes. Oracle Cloud Infrastructure is Oracle's own platform and many agreements treat deployments there more favorably than third party public cloud. Whether OCI counts cleanly still depends on the specific contract language, so the clause has to be read before any workload is moved.
Book a confidential assessment and we will read your cloud clause, map the clock, and plan any repatriation while there is still time for it to count.