A lift-and-shift business case moves a two-socket database server with 32 Intel Xeon cores running Oracle Database Enterprise Edition onto a 64-vCPU instance in an authorised cloud environment. Compute, storage and egress are modelled carefully and the case shows a small saving. Which line is missing, and how big is it?

The assumptions, stated

Two published Oracle documents decide this, and neither is an infrastructure price.

On premises, the licence requirement is cores multiplied by a core factor. Oracle's Processor Core Factor Table gives Intel Xeon multicore chips a factor of 0.5. So 32 physical cores need 32 × 0.5 = 16 Processor licences.

In an authorised cloud environment the rule is different. Oracle's policy Licensing Oracle Software in the Cloud Computing Environment requires customers to count two vCPUs as one Oracle Processor licence where multi-threading of processor cores is enabled (one vCPU per licence if it is not), and states plainly that the Core Factor Table is not applicable.

The arithmetic, shown

• On premises today: 32 cores × 0.5 = 16 Processor licences.
• The same machine as a 64-vCPU multi-threaded cloud instance: 64 ÷ 2 = 32 Processor licences.
• The licence requirement doubles for identical compute, because the 0.5 factor that halved the on-premises count does not exist in the cloud rule.

Multiply the extra 16 licences by your own contracted price per Processor, then add annual support, which in most enterprise agreements is a fixed percentage of the licence fee and therefore doubles with it. Using an illustrative contracted $25,000 per Processor purely to show the shape — your number will differ and is the one to use — the missing line is about $400,000 one-off plus a recurring support increase every year after, against an infrastructure saving usually modelled in tens of thousands. The licence delta is an order of magnitude larger than the saving the case is built on.

Which assumption dominates the error

Not the price. It is the instance shape, which is an architecture decision nobody framed as a commercial one. Right-sizing to 32 vCPUs restores the count to 16 and the case survives; picking a 96-vCPU instance "for headroom" quietly commits 48 licences. Because the metric is per vCPU and not per unit of work, a faster core at a smaller count is cheaper twice: less licence and more throughput per licence, which inverts the usual habit of buying width.

The second assumption is edition. The same policy licenses Standard Edition products by instance size rather than by vCPU count, so a workload that genuinely fits Standard Edition 2 is a different calculation entirely, not a discount on this one.

What the number rules in or out

• It rules out the "we will decide the instance type during implementation" plan. The instance family is a term of the licence bill, so it belongs in the business case, with the count shown.
• It rules in the question every migration case should answer before the compute estimate: for each licensed product, what is the licence metric a function of, and which architectural choice moves it?
• It makes consolidation onto fewer larger hosts a licence decision, not a capacity one.

When this is the wrong answer

When the licensed product is a small part of the estate. If the database in question is one of forty and holds 2% of the data, spending a month optimising its licence position ahead of the migration is a poor use of the architect. Take the standard shape and move on.

It is also the wrong framing when the vendor relationship is up for renegotiation anyway: an enterprise agreement being renewed can change the metric, and designing hard against a metric that is about to be replaced wastes the design. The rule that survives both cases is narrower: never let an instance shape be chosen by anyone who has not been told what it costs in licences.

Common weak answers

• "Use a managed database service and the problem goes away." It changes who counts, not whether counting happens, and the authorised-cloud policy is explicit that the same vCPU rule applies to the listed managed offerings. A different engine would remove the metric; a different hosting model for the same engine usually does not.
• "Negotiate a discount." A discount on twice the quantity is still more money, and it arrives after the design has fixed the quantity. Quantity is architecture; unit price is procurement.