Cloud Repatriation and the Oracle License Position

Why does repatriation change your license position?

Repatriation changes your license position because the rules that count your deployment are different on premises than in authorized cloud, so the same database can carry a different licensable number once it moves back. In authorized cloud, Oracle's policy counts vCPUs at 2 to 1 with hyperthreading on. On premises, the core factor table applies, converting physical cores into a licensable count using a multiplier, typically 0.5 for common x86 processors. Moving between the two is not a like for like transfer; it is a change of counting method, and the count can rise or fall accordingly.

Repatriation has become a real planning topic as organisations rebalance cloud and on premises estates for cost and control. The full counting framework for both environments sits in the Oracle virtualization licensing guide, and the cloud side of the equation is covered in counting vCPUs on AWS and Azure.

How does the core factor table apply again?

The core factor table applies again the moment a workload runs on physical hardware you control, because that is where Oracle counts cores multiplied by the relevant factor rather than counting vCPUs under the cloud policy. A sixteen core x86 server licenses as eight Processor licenses at a 0.5 factor, but the same logical workload may have been counted differently in the cloud. The repatriation therefore requires you to identify the target processor, find its factor in the core factor table, and count the physical cores that will actually run Oracle.

The risk here is landing the workload on more cores than it needs because the target server is generously specified. Oracle counts the cores available to the software, not the cores the workload happens to use, unless an approved hard partitioning method limits them. Sizing the target hardware tightly, and using a recognised partitioning approach where appropriate, directly controls the count.

Is repatriation an Oracle audit trigger?

Repatriation can be an Oracle audit trigger because infrastructure change and cloud migration are among the events Oracle's audit selection recognises, so a sudden shift in your on premises footprint can draw scrutiny. Oracle audits run through its Global Licensing and Advisory Services, formerly LMS, under the audit clause in the Oracle Master Agreement, with a 30 to 45 day response window. Audit triggers include virtualization changes, mergers and acquisitions, declining support spend, rejected sales proposals, and cloud migrations, and a repatriation can touch several of these at once.

The point is not to avoid repatriation but to do it from a documented position. A move that is planned, counted, and reconciled to the contract is defensible if it is ever reviewed. A move made in haste, with the new footprint never reconciled, leaves an easy finding. Standing compliance discipline is the protection, and it is the same discipline that defends any audit.

A worked example of a repatriation count

Consider a database running in authorized cloud on 32 vCPUs with hyperthreading on, counted at 16 Processor licenses under the cloud policy. Repatriate it to a server with two sixteen core x86 sockets, thirty two physical cores, and the core factor table at 0.5 produces 16 Processor licenses for the same workload, parity in this case. Land it instead on a larger server with forty cores available to the software, and the count rises to 20 Processor licenses even if the workload itself has not grown.

How do you plan a repatriation around licensing?

You plan a repatriation around licensing by sizing the target hardware to the workload, choosing processors with a favourable core factor, and confirming the count against your agreement before any data moves, so the new footprint is licensed by design rather than by accident. The licensing decision belongs at the start of the architecture, not at the end, because once the hardware is bought and the workload is live the count is fixed by what is physically present.

• Identify the target processor and its core factor before procurement
• Size the server to the workload, not to spare capacity
• Limit Oracle to the cores it needs using a recognised method where appropriate
• Recalculate the on premises count and compare it to your entitlement
• Document the deployment so the footprint is defensible if reviewed

The same care applies to disaster recovery and standby nodes that come with the repatriated estate, where the 10 day rule and failover terms change the count. The broader standing compliance framework is set out in the Oracle license compliance guide.

What is the buyer move?

The buyer move is to treat repatriation as a licensing project with an architecture attached, recalculating the count under the core factor table, sizing the target estate to the workload, and reconciling the result to the contract before the move completes. Done this way, repatriation can reduce cost without creating exposure. Done without a count, it can replace a clean cloud position with an unlicensed on premises one, exactly the kind of footprint an audit is designed to find.

Your next step

A repatriation is the right moment to get the on premises count exactly right, because the decisions are still open. An independent buyer side review models the target footprint, applies the core factor table, and confirms the position against your agreement so the move lands clean. Book a strategy call to plan the repatriation around your license position.