When AWS or Azure will not count toward your certification, OCI often will. Moving real workloads to Oracle Cloud before the exit can rescue value the contract would otherwise erase, but only when the counting terms agree and the timing allows.
By the Meridian advisory team · Ex Oracle licensing analysts · Updated June 2026
Consider it when three things line up: your contract will not count AWS or Azure but does count OCI, the workload is real and will keep running, and you have enough time to complete and evidence the move before certification. Cloud counting is contract specific, and many ULAs treat OCI more favourably than third party cloud, sometimes without the continuity conditions that apply elsewhere. Where that is true, moving a workload that would otherwise count for nothing onto a platform that counts in full can recover meaningful entitlement. The move is a tool, not a reflex, and it only pays when the contract, the workload, and the calendar all agree.
OCI is the friendliest place to land cloud value at a ULA exit, but friendliness is not a guarantee. Confirm your specific OCI counting language first, then decide whether a migration earns its cost in recovered entitlement.
The difference is commercial, not technical. Oracle has every reason to make its own cloud the easy place to count, because it encourages customers onto OCI. As a result, many ULA agreements recognise OCI deployments on terms closer to on premises than to third party cloud, and some omit the 365 day continuous deployment rule that catches AWS and Azure. That asymmetry is exactly what makes OCI a useful destination when public cloud will not count. It is also why you should never assume the OCI terms match the AWS terms in your own agreement. Read both.
No. OCI is more often countable than AWS or Azure, but it is not automatic. Some agreements still attach conditions to OCI deployments, and a few treat all cloud the same way. The only reliable answer comes from your contract. Before you plan a migration around OCI, confirm the exact counting language, including any continuity requirement, any product specific carve outs, and how the agreement defines an OCI deployment as installed and running. This is a place where assuming the general pattern applies to your specific deal can be an expensive mistake.
A move to OCI earns its place only if the recovered entitlement outweighs the cost and risk of the migration. The cases below show the difference.
The strongest case is a substantial workload sitting in AWS or Azure that your contract will not count, where the same workload on OCI would count in full, and where you have twelve months or more before certification. The workload is one you intend to keep running regardless, so the migration is not waste, and the recovered entitlement is large relative to the move. Here OCI turns stranded cloud spend into permanent licenses.
The move is hard to justify when the workload is small, when certification is only a few months away and the timing or continuity requirement cannot be met, or when the OCI counting language in your specific contract is no better than the AWS language. It is also the wrong call if the only reason to migrate is the count and you would otherwise tear the workload down, because that drifts toward gaming rather than legitimate deployment. A move that exists purely to inflate a number, with no intent to keep running, is the kind Oracle can later challenge.
The figures below are indicative and shown only to illustrate the decision.
| Scenario | Where it runs | Counts now | After OCI move |
|---|---|---|---|
| Analytics platform, 90 processors | AWS, excluded by contract | 0 | 90 |
| Reporting estate, 30 processors | Azure, fails 365 day rule | 0 | 30 |
| Small test cluster, 8 processors | AWS, excluded by contract | 0 | 8 |
The two larger workloads, totalling an indicative 120 processors, are strong candidates: real, persistent, and currently counting for nothing. Moved to OCI with eighteen months of runway, they convert into 120 processors of certified entitlement at the same support cost. The eight processor test cluster is a weaker case, where the migration effort may not justify the gain, and it might be better repatriated on premises or simply left out. The method is to rank candidates by recovered value against migration cost and time, not to move everything.
An OCI move is sound when you would run the workload there anyway. It tips into risk when the instances would not exist but for the count and would vanish after the letter is signed. Real and persistent is the standard.
Give it real runway. The migration must be complete, stable, and evidenced as deployed within the term before certification, and any continuity requirement in your contract has to be fully satisfied by the exit date. That argues for starting twelve to eighteen months out. A rushed migration risks two things at once: the technical outcome, because complex Oracle workloads do not move cleanly under pressure, and the count, because a deployment that lands too late or breaks a continuity test counts for nothing despite all the effort. Treat the move as a programme with its own plan, owners, and evidence trail, not a last minute scramble before the certification window.
An OCI move is usually a response to a cloud counting problem. To understand the clause that most often creates that problem, read the 365 day continuous deployment clause, and if your cloud estate is containerised read containers in the cloud and ULA counting before you plan the move. For the full exit picture, our Oracle ULA exit strategy guide is the pillar that sequences cloud, OCI, and on premises decisions against the clock.
Consider it when your contract will not count AWS or Azure but does count OCI, and when the workload would otherwise add nothing to your certified position. The move only makes sense if OCI is genuinely countable under your terms, the workload is real and will keep running, and you have enough time before certification to complete and evidence it.
No. OCI is more often countable than third party cloud, and many agreements treat it more favourably, but it is not automatic. Some contracts still impose conditions. Always confirm the exact counting language for OCI in your agreement before planning a migration around it.
Give it real runway. A migration must be finished, stable, and evidenced as deployed within the term before certification, and any continuity requirement in your contract has to be satisfied. Starting twelve to eighteen months out is sensible, because a rushed move risks both the technical outcome and the count.