When a ULA cloud clause excludes Azure or AWS, or a workload misses a 365 day rule, the value is not automatically lost. Moving that workload to on premises infrastructure or to OCI before the term ends can bring it into a scope that counts, provided the move completes in time and is evidenced.
Cloud counting is the part of a ULA exit most likely to produce an unwelcome surprise. You read the cloud clause, you discover that a large Azure or AWS footprint will not count, and the certified number you expected shrinks. Repatriation is the response. By moving Oracle workloads off a cloud that does not count and onto infrastructure that does, before the term ends, you convert stranded deployments into countable ones. This article explains when repatriation makes sense, where workloads can go, and why timing is the whole game.
Certification counts what is genuinely deployed within the term on infrastructure the contract recognises. If your ULA excludes public cloud, an Oracle database on Azure is real but invisible to the count. The same database running in your own data centre, or in some cases on OCI, sits on infrastructure the agreement does recognise, so it counts. Repatriation does not invent deployment, it relocates existing deployment onto countable ground. The workload, the data, and the business purpose are unchanged. Only the place it runs moves, and the place it runs is what the contract cares about.
Yes, within limits set by your contract and the calendar. The move has to complete while the unlimited right is still live, because deployment outside the term does not count. Where the agreement carries a 365 day continuous run requirement for the destination, the workload needs to be in place with margin against that threshold. And the repatriated deployment has to be genuine: a running system carrying real workload, not a token instance stood up to be removed afterward. Inside those limits, repatriation is a legitimate and often substantial source of certified value.
There are two main destinations, and the right one depends on your estate, your future plans, and the contract.
Returning a workload to your own data centre puts it under the on premises counting rules, where processor counting with core factors applies. This is the most universally countable destination, because almost every ULA recognises on premises deployment. The detail of how the count is built once the workload lands is covered in moving workloads on premises to count them. The cost is the capacity you need to host the returning workload, which is why this decision belongs in the early planning phase rather than the final weeks.
Some agreements treat OCI more favourably than third party public cloud, and Oracle frequently offers incentives to move workloads onto OCI around an exit. Where the contract recognises OCI for counting, it can be a lower friction destination than repatriating to your own data centre. The trade is a deeper commitment to Oracle infrastructure, which has its own commercial consequences to weigh. Whether OCI counts, and on what terms, is contract specific and has to be confirmed against your clause.
Consider an indicative healthcare provider whose ULA excludes public cloud. A cluster of Oracle databases on AWS represents roughly 300 processors of potential value that the contract will not count. Eleven months before the term ends, the team repatriates the workloads to on premises hosts already earmarked for refresh. By certification the databases have run on countable infrastructure for the full term remainder, and the 300 processors enter the certified number. The figures are indicative and the result depends on the cloud clause and the counting method.
Repatriation fails for one reason more than any other: it starts too late. A migration of production Oracle workloads is not a weekend task. It needs capacity planning, testing, a cutover window, and operational sign off, and all of it has to land before the term ends. Where a 365 day rule applies to the destination, the effective deadline moves a further year earlier. The practical consequence is that the decision to repatriate has to be made during the exit planning phase, around 18 months out, not when the certification window opens. By the time the window is open, the option is usually gone.
There is also an evidence dimension. A repatriated workload needs the same documentation as any counted deployment: dated build records, server lists, and discovery output showing it running on countable infrastructure within the term. The migration timeline itself becomes part of the evidence file, demonstrating that the deployment was genuine and complete before the exit.
Repatriation has a cost, and it is not always justified. If the excluded cloud workload is small, or if the capacity and effort to move it outweigh the certified value it would add, leaving it where it is may be the better call. The decision is a straightforward comparison: the permanent licensing value the workload would contribute against the one time cost and risk of moving it. That comparison is exactly the kind of judgement the exit planning phase exists to make, and it is rarely obvious without reading the specific clause and sizing the specific workload.
Repatriation is one move inside a broader cloud and exit strategy. For the full framework, start with our ULA exit strategy guide. For the on premises destination in detail, read moving workloads on premises to count them, and for the case where the contract does not mention a provider at all, read when the ULA is silent on GCP. Because repatriation lives or dies on timing and contract language, the earlier you test the option, the more of it remains available.
Yes. Where a ULA excludes public cloud or a workload misses a 365 day rule, repatriating it to on premises infrastructure or to OCI before the term ends can bring it into scope so it counts. The move must complete inside the term and be evidenced.
Early enough that the workload is genuinely deployed on the counting infrastructure before the term ends, and where a continuous run rule applies, with margin against it. Repatriation decisions usually need to start a year or more before certification.
We size your excluded cloud workloads and plan the moves that bring them into the count in time.