Oracle licenses are portable in theory but tightly constrained in practice, and every move creates an audit question about whether you double-counted. This page tells you exactly when a reassignment is compliant, when it is not, and what evidence keeps you out of a finding.
Oracle licenses are portable in theory but tightly constrained in practice, and every move creates an audit question about whether you double-counted. This page tells you exactly when a reassignment is compliant, when it is not, and what evidence keeps you out of a finding.
Oracle licenses are not welded to a physical machine. They attach to your organization and to a quantity of usage, measured in processor licenses (cores adjusted by the core factor) or Named User Plus (NUP) counts. That means you can, as a baseline right, move an Oracle deployment from one server to another without buying anything new. The problem is never the concept of mobility. The problem is the gap between the moment you install on the new server and the moment you fully decommission the old one, because Oracle's contract counts installed and/or running, not actively used.
In 25 years of negotiating and defending against this vendor, I have seen far more audit exposure created by clumsy migrations and VM mobility than by deliberate over-deployment. Customers assume a transition period is forgiven. It is not. This page walks the practical rules, the traps, and the buyer-side moves. For the wider framework, start with the pillar on Oracle license transfer and assignment.
You may reassign processor licenses from one server to another provided the original server is permanently decommissioned or no longer runs any Oracle software. For NUP, you may reassign a license from one user to another provided the original user no longer requires access. Both rules share the same logic: no overlap. If Oracle software is installed and/or running in two places at once, you need enough licenses to cover both places, full stop.
Worked example. You hold 4 processor licenses covering Server A. You decommission Server A and install Oracle on Server B. Those 4 licenses now cover Server B, provided Server B's licensable core count (cores multiplied by the core factor) does not exceed what 4 licenses cover. On an Intel or AMD chip at the standard 0.5 core factor, 4 processor licenses cover 8 physical cores. Move to a 16-core box and you now need 8 processor licenses, not 4. The move itself is legal. The capacity increase is what bites.
The counting event is installation, not active use. A binary sitting idle on a new server still requires licenses.
This is the single most common self-inflicted wound. Oracle requires licenses for all processors where programs are installed and/or running, even during a migration. There is no migration exception written into the standard agreement. The contractual trigger is precise: a server installed and/or running the program on 6 cores at a 0.25 core factor requires 2 processor licenses, whether or not a single query has run. So the natural migration pattern, stand up the new environment, test it, cut over, then tear down the old one, means you are running Oracle in two places simultaneously for the duration. That is the definition of unlicensed use if you do not own enough to cover both.
There are two legitimate ways to bridge the overlap. First, apply shelf licenses: unused entitlements you already own. Deploy those to the new environment during the migration window, then reassign the original licenses once the old server is decommissioned. Second, license the new environment on the NUP metric temporarily until the processor licenses free up, which can be dramatically cheaper for a short-lived test bed. Both approaches require that you actually have the headroom, and both require documentation showing the sequence.
| Migration approach | When it works | Cost exposure | Audit risk if undocumented |
|---|---|---|---|
| Sequential (decommission A, then deploy B) | Zero downtime tolerance is low | None if truly sequential | Low, but rare in practice |
| Overlap with shelf licenses | You own unused entitlements | None if entitlements suffice | Medium: prove the shelf licenses existed and were applied |
| Temporary NUP on new environment | Small user population during test | 25 NUP per processor floor applies | Medium: prove the NUP deployment and its end date |
| Overlap with nothing (assume grace period) | Never | Full second deployment | High: classic double-deployment finding |
Oracle does allow license mobility between on-premises and cloud, and between one on-prem site and another, provided you do not exceed the licensed count at any given time. The physical geography of the servers is not the constraint. The simultaneity is. Move a workload from your data center to another region, and as long as the source stops running Oracle before or as the target starts, you are compliant. Run both during a phased cutover and you have doubled your requirement for that window.
The defense here is documentation, not architecture. Keep dated records of every move: when the source stopped, when the target started, what was installed where. If you are moving to a cloud provider under bring-your-own-license, read the retention and metric rules first because the counting can shift; see the analysis of moving Oracle licenses to the cloud with BYOL. If a third party operates the target data center, the hosting rules change again and are covered in running Oracle in a hosting provider or managed datacenter.
Oracle does not audit your intent. It audits what its scripts find installed. Undocumented overlap reads as double use every time.
Virtualization is where reassignment quietly turns into a compliance liability. Because VMs can move between physical hosts, Oracle's position is that you must license every physical CPU in the cluster where an Oracle VM could potentially run. VMware vMotion performs live migration of running VMs between hosts, meaning an Oracle instance can land on any host at any moment. Dynamic migration features, if left unrestricted, mean Oracle software can move to a host you never intended to license. To Oracle's LMS scripts, that host now shows Oracle installed, and it becomes a finding.
Cross-cluster moves are worse. Migrating a VM between clusters can be treated as a distinct re-licensing event, forcing a reassessment of what you owe. The practical containment is strict and must be provable: restrict VM movement to a defined set of fully licensed hosts, and log every host on which an Oracle VM has executed and every inter-host move. Financial services buyers running Oracle on VMware should read the sector-specific defense in Oracle Database audit defense for banks, which covers VMware scope directly.
Oracle permits running programs on an unlicensed spare computer for up to a total of ten separate days in any given calendar year. This is the only meaningful free-movement allowance, and it is narrow. It applies only when machines, as defined in Oracle's Partitioning Policy, are arranged in a cluster and share one logical disk array located in a single data center. A DR site in a different data center or cloud region does not qualify: it is a separate environment requiring full licensing.
The counting is punitive. Any portion of a day counts as a full day. Activate the failover node for one hour and that is one of your ten days consumed. Exceed the ten cumulative days in a year and you lose the protection retroactively for that entire year: Oracle then treats the standby as a licensed deployment requiring full processor or NUP licensing on all its cores. If you run Active Data Guard on that standby, it is a paid option regardless, as covered in the note on Oracle Active Data Guard licensed the buyer-side way. The buyer move is to track failover activations with the same rigor as production uptime, because you are defending a ten-day budget where a single careless test consumes a tenth of it.
Reassigning a license across your own servers is one thing. Transferring it to a different legal entity is a separate and far more restricted act. Oracle's standard agreement states you may not assign the agreement or transfer the programs or any interest in them to another individual or entity. So a physical move of a server across a border within the same legal entity may be fine, subject to territory limits in your ordering document, but a move that crosses into a different subsidiary, an acquiring company, or a divested unit triggers the anti-assignment clause and requires Oracle's approval.
This matters most in mergers, acquisitions, and divestitures, where different entities hold different Oracle agreements with different metrics, usage rights, and territory limits. Do not assume you can shuffle licenses between affiliates freely; the rules are set out in sharing Oracle licenses across affiliates and subsidiaries, and a carve-out to a standalone business is its own project, covered in carving out Oracle licenses for a divested business unit. Buying or selling used licenses to escape a transfer restriction rarely works either; see the secondary-market reality.
Oracle often times audits to hardware refreshes precisely because that is when core counts jump. Replacing older 4-core servers with new 8-core processors can double your requirement overnight, and a refresh is a documented audit trigger. If you moved licenses during that refresh without documenting the decommissioning of the old hardware, Oracle's scripts may find Oracle installed on both the retired and the new boxes, and the raw output will read as double deployment.
Understand what the scripts do and do not do. Oracle LMS scripts report installed programs, enabled options, and feature usage history. They do not separate entitled use from accidental or default-enabled use, and they do not know that a server was decommissioned last month if the binary is still present. Raw output therefore overstates exposure. You must reconcile it against your own records before returning anything. Evidence of decommissioning, dated and specific, is the difference between a clean reassignment story and a seven-figure finding.
Keep dated decommissioning evidence for every move. Without it, a legal reassignment is indistinguishable from unlicensed double use.
The cost stakes justify the discipline. On the current price list, Enterprise Edition lists at $47,500 per processor and $950 per NUP with a 25 NUP per processor floor. Standard Edition 2 uses a socket-based metric at $17,500 per occupied socket, cores ignored, capped at two sockets, which changes the reassignment math entirely because a socket move can shift your requirement in ways a core move does not. And support runs at 22 percent of net license fee every year on every license you hold, whether or not it is actively reassigned. Over five years that support cost quietly exceeds the license itself, which is why terminating truly unused entitlements after a consolidation, as documented in the Costco support optimization case study, delivers more savings than most re-negotiations.
Yes, provided the original server is permanently decommissioned or no longer runs any Oracle software, and the new server's licensable core count does not exceed what your existing licenses cover. The move itself is free. A capacity increase (more cores, higher core factor) is not.
No. Oracle's contract counts licenses on every processor where programs are installed and/or running, with no migration exception. If Oracle is installed on both the old and new servers at once, you need enough licenses to cover both. Bridge the overlap with unused shelf licenses or a temporary NUP deployment.
Because VMs can live-migrate between hosts via vMotion, Oracle's position is that an Oracle VM could potentially run on any host in the cluster, so every physical CPU must be licensed. You can contain this by pinning Oracle VMs to a named, fully licensed subset of hosts and logging every migration to prove software never ran on an unlicensed host.
Oracle lets you run programs on an unlicensed spare for up to ten separate days per calendar year, but only when the machines form a cluster sharing one logical disk array in a single data center. Any portion of a day counts as a full day. Exceed ten days and you lose the protection retroactively for the whole year, requiring full licensing on the standby.
Not without Oracle's approval. The standard agreement prohibits assigning the agreement or transferring the programs to another individual or entity. Physical server moves within the same entity are portable; cross-entity transfers in mergers, acquisitions, and carve-outs trigger the anti-assignment clause and require written consent.
Dated records showing when the source stopped running Oracle, when the target started, and when the old hardware was decommissioned. LMS scripts report installed software but cannot tell that a server was retired, so without your own decommissioning evidence a legal move looks identical to unlicensed double use.
Oracle Exadata can lock you into full core licensing across X9M, X10M, and Cloud at Customer. The buyer side strategy to size the platform and cut the bill.
Gated with a work email on the download page. No sales follow up you did not ask for.
Get the White Paper →
500+ enterprise clients. 11 vendor practices. Industry recognized. One conversation can change what you pay for the next three years.
One buyer side briefing a week. Renewal signals, audit moves, and the levers that work. No vendor spin.
