Oracle Database Licensing During Cloud Migration

Cloud migration is where many Oracle estates accidentally pay twice, because the period when the on premises database and the cloud instance both run is a window of double demand that the licence base was never sized for. Managed deliberately, a migration reduces licence cost; managed loosely, it creates an overlap that an audit reads as unlicensed deployment. This article sets out how Oracle counts during migration, how Bring Your Own License works on the major clouds, and how a buyer side estate retires capacity cleanly. It sits under the database licensing pillar and connects to the cloud specific guides for AWS and Azure.

Why dual running doubles the licence demand

A migration is almost never instantaneous. The cloud target is built, data is replicated, the application is tested against it, and only then does production cut over, with the on premises database often kept available as a fallback for a period after. Throughout that sequence two databases exist and run, and Oracle licenses installed and running software, so both must be covered at once.

An estate that holds exactly enough licences for its on premises footprint has nothing spare to cover the cloud instance during the overlap. The moment the cloud database starts, the estate is over deployed against its entitlements until the source is retired, and that gap is precisely what an audit reconstructs from the effective licence position.

Bring Your Own License during migration

Bring Your Own License lets an estate apply entitlements it already owns to instances on authorised clouds, preserving the value of those licences rather than buying cloud bundled ones. It is the natural model for a migration of an existing licensed estate, because the licences move with the workload. The catch is that the same licence cannot cover both the on premises database and the cloud instance simultaneously, so BYOL only resolves the dual running problem if the source usage is reduced as the target comes up.

BYOL also keeps existing support flowing on the owned licences, which matters because support is the recurring cost, and it avoids the premium embedded in license included pricing for steady workloads.

How vCPUs convert to Processor licences

On authorised clouds the familiar core factor table does not apply. Instead Oracle uses a vCPU rule: with hyperthreading enabled, two vCPUs count as one Processor licence, and without hyperthreading one vCPU counts as one Processor licence. This replaces core factor arithmetic with a straightforward vCPU ceiling per Processor licence.

The practical effect is that each owned Processor licence covers a fixed vCPU allowance on the cloud, and the migrated instance must be sized within that allowance. Oversizing the cloud instance beyond the vCPU equivalent of the owned licences creates a shortfall even when the on premises database has been retired, which is why instance sizing is part of the migration licensing plan rather than an afterthought.

BYOL versus license included

License included bundles the Oracle licence into the metered cloud price, so an estate pays per hour or per consumption unit without holding separate entitlements. It suits short lived migration test environments and variable workloads, because it scales to zero when the instance is stopped. BYOL suits steady, long lived production because owned entitlements are cheaper over time than perpetual metered consumption.

A common and effective migration pattern uses license included for the temporary test and staging instances, avoiding the need to buy entitlements for short lived environments, and BYOL for the production target that will run indefinitely. Choosing per environment rather than per project is the kind of optimisation the cloud and OCI licensing service models.

Retiring on premises capacity cleanly

The single most important migration discipline is retiring source capacity in lockstep with each workload that moves, and documenting the date each on premises database is decommissioned. A clean retirement record converts the dual running window from an open ended liability into a defined, dated overlap that can be explained and, where necessary, covered by a negotiated allowance.

Where the business needs the source available as a fallback for weeks after cutover, that decision has a licence cost, and it should be made knowingly with either temporary entitlements or a contractual migration clause covering the overlap. Reconstructing this sequence after the fact is far harder than recording it as it happens.

Migration licensing models compared

How to contain migration exposure

Containment combines a migration licence plan with disciplined record keeping. The plan sizes each cloud instance within the vCPU allowance of the licences assigned to it, chooses BYOL or license included per environment, and schedules source retirements against target go lives. The record keeping captures the decommission date of every source database and the start date of every cloud instance, producing a defensible timeline.

Where the overlap cannot be eliminated, it should be negotiated into the contract before migration begins, because a migration allowance agreed up front is far cheaper than entitlements bought reactively. This forward planning is the core of what the database licensing service brings to a cloud move.

The buyer side view

The buyer side position on cloud migration is that the licence plan is part of the migration plan, not a clean up task afterward. Size cloud instances within the vCPU equivalent of owned licences, use license included for short lived environments and BYOL for steady production, retire source capacity in step with each cutover, and document every date. Negotiate the dual running window into the contract rather than absorbing it. Done this way, a migration lowers licence cost instead of creating a hidden overlap. Start with the database pillar, read the cloud specific rules, and where a migration is being planned request a consultation. For a related scenario, see the audit trigger events.