OCI Migration Licensing: Getting the Move Right

Why migration changes the licence requirement

Moving an Oracle workload to OCI is not licence neutral, and assuming it is causes most migration overspend and compliance gaps. The requirement changes for three reasons: the on premise core factor disappears, both environments may run simultaneously during cutover, and options or packs that were licensed loosely on premise are exposed precisely in the cloud. A disciplined migration accounts for all three before the first workload moves, which is why migration planning sits at the centre of the Oracle OCI licensing model.

The single biggest driver is the core factor. On premise, a workload on Intel cores counts at a 0.5 factor; on OCI and the hyperscalers that factor is gone, as set out in OCPU versus vCPU. A like for like migration of the same compute therefore needs roughly double the processor licences in the cloud. A buyer who budgets for a flat transfer of licences will be short by half, and the shortfall surfaces as either an unbudgeted purchase or an audit finding.

There is a timing nuance that compounds these effects. Migrations rarely happen on a single date; they unfold over months as workloads are tested and cut over in sequence. The licence requirement therefore changes continuously through the project, not in one step, and a plan that models only the start and end states misses the peak in the middle when the most workloads are running in parallel. Modelling the requirement as a curve across the migration timeline, not as two snapshots, is what reveals the true peak entitlement needed.

The dual running trap

During any migration there is a period when the source on premise system and the target OCI system both exist, often both running, while data is replicated and the cutover is validated. In that window you are using Oracle software in two places, and Oracle expects both to be licensed. Under BYOL you cannot simply carry the same licences to the cloud while the on premise system is still live; the entitlement covers one deployment at a time, not both.

There are three ways to manage this. Keep the dual running window as short as possible so the overlap is minimal. Use a License Included target during cutover, paying the bundled rate only for the migration period and switching to BYOL once the source is retired. Or negotiate a migration provision with Oracle that permits a defined overlap. What you cannot safely do is run both under one set of BYOL licences and hope the overlap goes unnoticed, because feature usage data records both. The cloud and OCI practice plans this window explicitly.

Baseline before you move

The control that prevents migration surprises is a licence baseline taken before the move. You cannot know whether your entitlement covers the cloud target until you know exactly what you own, what is deployed on premise, and what the cloud deployment will require after the core factor is removed. The baseline establishes all three and turns the migration from a hopeful transfer into a planned reconciliation.

With the baseline in hand, the gap between owned entitlement and the cloud requirement is explicit, and you can decide whether to buy, to use License Included, or to re architect the target to fit existing licences. Without it, the gap is discovered after the workload is live, when the only options are an unplanned purchase or exposure. The baseline is the same artefact the audit defence practice builds, used proactively.

The baseline is also the moment to reconcile entitlement against the contract documents themselves, not just deployment data. Licence counts recorded in an asset system can drift from what the ordering documents actually grant, and a migration that relies on a phantom licence discovered only at audit is worse than one that knew its true ceiling from the start. Reading the entitlement from the source contracts during the baseline turns the migration plan onto solid ground.

Choosing the model for migrated workloads

Migration is the natural moment to choose the licensing model per workload, because you are touching every workload anyway. Stable production databases you will run for years, where you hold spare supported licences, suit BYOL. New, variable, or short lived workloads suit License Included, which avoids a perpetual purchase and bundles options. Defaulting the whole estate to one model misses the saving that comes from matching each workload to the cheaper option over its life.

Support Rewards enters the model choice here. Migrating workloads to OCI generates consumption that rebates on premise support through Oracle Support Rewards, which improves the BYOL case for retained licences. Modelling the rewards as part of the migration business case, rather than as an afterthought, can change which model wins for a borderline workload. The shape sizing that underlies both models is covered in OCI compute licensing.

Options exposed by migration

Migration frequently exposes option usage that went unmanaged on premise. A database that quietly used the Diagnostics Pack or Partitioning for years, without anyone tracking the entitlement, carries that usage into the cloud where it is precisely metered. The move is therefore a moment of truth for options: whatever the database actually uses becomes visible, and any shortfall that was tolerated on premise becomes a clear gap on OCI.

The right response is to run a feature usage analysis as part of the baseline, identify every option in use, and decide for each whether to licence it, disable it, or move to a License Included tier that bundles it. Treating migration as an opportunity to clean up the option position, rather than a process that merely transfers an existing mess, is what separates a controlled move from one that imports its own liabilities. The mechanics are in OCI database options.

How should you sequence the migration?

Sequencing controls both cost and risk. Migrate in waves rather than all at once, so dual running windows are small and contained per wave rather than spanning the whole estate. Move the workloads with the clearest licence position first to build confidence and free entitlement, and leave the option heavy or ambiguous workloads until the baseline questions on them are resolved. Retire each source promptly after cutover so the dual running cost ends.

The sequencing should be driven by the licence baseline, not only by technical dependencies. A workload that would double its licence requirement on a like for like move is a candidate for re architecture or License Included before it moves, not after. Letting the baseline shape the order of migration is how a buyer keeps every wave compliant and budgeted, and it is the planning the cloud and OCI practice runs alongside the technical migration team.

Governing the post migration position

Once workloads are live on OCI, the migration baseline becomes the standing reconciliation. Every migrated workload's OCPU count, model, and options are recorded against entitlement, and the source systems are confirmed retired so no dual running cost lingers. The reconciliation is dated and maintained, so the position that was correct at cutover stays correct as workloads scale and change. This is the same governance discipline applied across the OCI cluster.

The most common post migration failure is leaving a source system half retired, still licensable, while its cloud replacement also consumes entitlement, quietly recreating the dual running cost as a permanent state. Confirming and documenting retirement is therefore part of the migration, not a loose end after it. A clean, dated record of what moved, what was retired, and what is now owned is the deliverable that protects the estate.

A final governance step is to capture, for each retired source, the date of decommission and evidence that the Oracle software was removed or de configured, not merely powered off. Oracle counts installed and available to run software, so a source left installed on a dormant server can still be deemed in use. Recording genuine removal closes the dual running cost definitively and removes a finding that otherwise resurfaces in the next audit cycle.

The buyer side view

Migrating to OCI changes the licence requirement, usually doubling it as the core factor is lost, and creates a dual running window where both environments must be licensed. Baseline before you move, choose the model per workload, clean up the option position on the way, sequence in waves to contain dual running, and retire sources promptly. Let the baseline drive the order of migration so every wave stays compliant and budgeted. To baseline and sequence your OCI migration, request a consultation.