Your perpetual processor licenses travel to the new appliance, but the new appliance's core count does not care what you own. This guide quantifies the true-up exposure across ODA generations and gives you the sequence of moves that keeps a refresh license-neutral.
Your perpetual processor licenses travel to the new appliance, but the new appliance's core count does not care what you own. This guide quantifies the true-up exposure across ODA generations and gives you the sequence of moves that keeps a refresh license-neutral.
The risk in an ODA refresh is not portability, it is capacity. Your perpetual processor licenses move; the new chassis does not know or care how many you hold. Oracle's own licensing documentation is explicit on this point: when you add the hardware Support Identifier (SI) for the appliance to your My Oracle Support account, you "establish a license for all the cores on your system." That is the default position, and on an X11 the default is expensive. An X11-S deploys with all 32 cores active. An X11-L deploys with all 64 active. An X11-HA deploys with all 128 active (64 per node, two nodes). Now put that beside what a typical refresh customer actually owns. A shop coming off an X5-2 that trimmed to 12 enabled cores holds 6 Enterprise Edition processor licenses at the 0.5 Intel core factor. Land that same entitlement on an untrimmed X11-HA at 128 enabled cores and, at a 0.5 factor, you need 64 processor licenses. That is a 58 license gap at roughly $47,500 list each, before support. The exposure is not created on cutover day. It is created the moment the SI is registered and the cores come up enabled, which is usually weeks earlier, during racking and validation, and usually by an infrastructure team that has never read a processor definition. Treat SI registration as a licensing event with a sign-off, not a support formality.
The exposure begins the day the Support Identifier is registered and the cores are enabled, not the day production cuts over.
Yes, subject to three conditions. Oracle does not node-lock perpetual database licenses. The entitlement sits with the legal entity named on the ordering document and is defined by a metric (Processor or Named User Plus), not by a serial number, so the same licenses you ran on an X6-2 can run on an X11-L. There is no re-purchase, no transfer fee, and no license migration form. What must hold is the arithmetic: enabled cores multiplied by the applicable core factor must not exceed the processor licenses you own, counted separately for each program and option. Second, the support contract lineage must stay intact. Keep the database CSI live and continuous; if you let it lapse to save a year of support during a hardware gap, reinstatement is priced punitively and Oracle will not simply restart it at the old rate. Third, and this is where refreshes actually fail, read the original ordering documents before you redeploy. Three restrictions recur in our client work. Territory clauses can limit use to a named country or region, which matters if the new appliance lands in a different data center. ULA-derived licenses are fixed at the certified quantity declared at exit, and that certification was measured against a specific deployed footprint, so a bigger box with more enabled cores consumes headroom you may not have. And discounted licenses tied to a named platform or program (engineered-systems promotions, migration credits, hosting-specific terms) sometimes carry a use restriction that survives the hardware they were bought for. Pull the ordering documents, not the price list, and confirm each SKU is unrestricted before you count it as portable. If you are also weighing edition, the SE2 versus Enterprise Edition math on ODA changes the carryover calculus entirely, because SE2 licenses one processor per 8 enabled cores rather than by core factor. For the underlying entitlement mechanics, see our ODA licensing buyer guide.
Every ODA generation has shipped more cores than the one it replaced, and Oracle's own licensing documentation records the escalator: ODA V1 activated 24 cores (12 per node), X3-2 activated 32, X4-2 activated 48, and X5-2 activated 72. The X6-2-HA pulled back to 40. The current line resets the ceiling again: X11-S is a single 32-core socket, X11-L is two sockets for 64 cores, and X11-HA is two nodes at 64 cores each for 128 cores total, all active with hyper-threading at deployment. At the standard 0.5 x86 core factor, full activation of an X11-HA is 64 Enterprise Edition processor licenses. At the published EE list price of $47,500 per processor, that is $3.04m in list license plus roughly $669k in first-year support at 22 percent. The trap is documented in Oracle's own words: adding the appliance's hardware Support Identifier to My Oracle Support "establishes a license for all the cores on your system." Nobody signs an order for 64 processors. Plenty of buyers create the same exposure by racking the box and registering it before trimming cores.
| Upgrade path | Old cores / EE licenses | New cores / EE licenses | Delta licenses | Delta at $47,500 list |
|---|---|---|---|---|
| X5-2 to X11-HA (full capacity) | 72 / 36 | 128 / 64 | +28 | +$1,330,000 |
| X4-2 to X11-HA (full capacity) | 48 / 24 | 128 / 64 | +40 | +$1,900,000 |
| X6-2-HA to X11-HA (full capacity) | 40 / 20 | 128 / 64 | +44 | +$2,090,000 |
| X3-2 to X11-L (full capacity) | 32 / 16 | 64 / 32 | +16 | +$760,000 |
| V1 to X11-S (full capacity) | 24 / 12 | 32 / 16 | +4 | +$190,000 |
Read the table as a risk register, not a purchase plan. Nothing forces you to enable those cores, and every path collapses to zero delta if you cap the new appliance at the core count you already own through capacity-on-demand core activation. What the table does show is the size of the audit finding waiting for anyone who deploys first and trims later. One more point kills a common refresh business case: X10 to X11 delivers roughly 10 percent per-core performance gain on identical 32-core sockets, so there is no generation where you consolidate the same workload onto materially fewer licensed cores. Do not let an account team sell the refresh as a license-reduction event, because the silicon does not support that claim.
Nobody signs an order for 64 processors, but racking an X11-HA and registering the Support Identifier creates that exposure by default.
X11-S and X11-L moved to AMD EPYC, while every ODA from V1 through the X9 line ran Intel Xeon. That chip change matters only through one document: the Oracle Processor Core Factor Table, which currently assigns 0.5 to both mainstream x86 lines. The arithmetic is enabled cores multiplied by the core factor, and Oracle rounds up to the next whole processor license. A 64-core X11-L at full activation is 64 x 0.5 = 32 Enterprise Edition processor licenses. A 24-core capped X11-L is 12. An odd activation of 26 cores is 13. Under Standard Edition 2 the factor table does not apply at all: X11 requires one SE2 processor license per 8 enabled cores, so a 16-core cap is 2 SE2 licenses, which is why the SE2 versus EE decision on an ODA changes the refresh math more than the chip vendor does.
Here is the buyer-side discipline. Oracle publishes and revises the core factor table unilaterally, and the factor that applies is the one in effect when the license is granted, not the one you remember from your 2016 purchase. Confirm the AMD EPYC entry against the live table on the day the order is signed, capture a dated PDF, and attach it to the ordering document as a referenced exhibit. In 25 years of negotiating this vendor, we have not seen a mainstream x86 factor move upward, but we have seen buyers budget a refresh on an assumed factor and discover the ordering document silent on the point. If the factor for EPYC ever moved from 0.5 to 0.75, that same 64-core X11-L would require 48 licenses instead of 32, a $760,000 list swing on one box. Fix the number in writing before you sign.
Treat Capacity-on-Demand as step one of the deployment runbook, not a tidy-up task after go-live. Oracle's own licensing documentation states that adding the hardware Support Identifier to My Oracle Support "establishes a license for all the cores on your system," and every X11 model ships fully enabled: 32 active cores on X11-S, 64 on X11-L, and 128 on X11-HA (two nodes, two sockets, 32 cores each). If your engineer racks the box, deploys, and starts testing before anyone runs odacli modify-cpucore, the default license position is full capacity. On X11 you can enable and license from a minimum of 2 cores upward in multiples of two, capped at the model maximum, and the same odacli modify-cpucore command governs bare-metal core trimming across X7-2S, X7-2M, X7-2-HA, X8-2S, X8-2M, X8-2-HA, X9-2S, X9-2L, X9-2-HA, X10, and X11. The mechanism is well documented in our explanation of how ODA core activation actually works; the discipline problem is organizational, not technical.
The trap that catches refresh projects is the low-water mark. Cores you enable during migration testing raise your permanent floor, and in practice you do not walk that number back without an Oracle conversation you would rather not have. So set the new appliance to the target core count on day one and test at that count, even if the migration runs slower. A four-week test at 32 cores on an X11-L that will run production at 16 cores has just doubled the licensed baseline for a temporary convenience. Standard Edition 2 shops run different arithmetic: one SE2 processor license per 8 enabled cores on X11, so the entry point is a single SE2 license at 8 enabled cores, and each additional 8-core step is one more license. That granularity is coarser but far cheaper, and it is worth revisiting during a refresh rather than assuming your edition choice from the previous generation still fits. Where one large X11 must serve several workloads with different license entitlements, KVM DB systems with dedicated CPU pools are Oracle-recognized hard partitioning and remain the only sanctioned way to sub-divide the box.
In 25 years of these engagements, the highest-probability audit finding in a hardware refresh is not the new appliance's core count. It is the overlap. Oracle's standard contract language requires licenses for every processor on which the programs are installed and/or running, and there is no migration grace clause anywhere in the OLSA, the OMA, or the ODA licensing documentation. A 60- or 90-day parallel run means both appliances are installed, both carry Support Identifiers, and both are countable. Oracle's position, which auditors state without embarrassment, is that a powered-off but still installed appliance remains licensable because the binaries are present. Do not rely on shutting it down.
| Refresh overlap scenario | Old ODA (X7-2M, 16 licensed cores) | New ODA X11-L (16 licensed cores) | Peak processor licenses required (0.5 core factor) |
|---|---|---|---|
| Cutover with no overlap | Decommissioned before deployment | 16 cores | 8 |
| 60-day parallel run, old box untouched | 16 cores installed | 16 cores | 16 |
| 90-day run with staged core trimming | Trimmed to 4 cores by week 4 | 16 cores | 10 at peak, falling to 9 |
| Old box powered off, software not de-installed | Oracle counts 16 cores | 16 cores | 16 (Oracle's position) |
Three bridge options actually work. First, buy short-term term licenses sized to the overlap only, typically 3 to 12 months, and insist the quote references the specific serial numbers and the end date; market experience is that Oracle will price these at roughly 20 percent of perpetual list per year and will discount them heavily when they are attached to a larger refresh order. Second, stage the core trimming on the old appliance as workloads move, so the combined licensed footprint peaks for days rather than months. Third, get written confirmation of the decommission date: a signed internal record showing de-installation of the Oracle software, not just power-down, dated and countersigned. Keep the ODA deployment evidence pack for the full audit window.
A powered-off ODA with Oracle binaries still on disk is an argument Oracle will make, and win, unless you can prove the de-installation date.
A hardware refresh is a purchase order Oracle wants to book, and that is the only moment in the ODA lifecycle when the buyer holds real leverage. The account team has a quota tied to the appliance and, usually, to any database licences attached to it. Do not sign the hardware order until the licensing consequences are documented in the same transaction. In my experience across refresh negotiations, the four items worth extracting are always available if you ask before the order is signed and effectively unavailable afterward: a written migration window (typically 90 days) during which both the old and new appliance may run the same programs without incremental licences, any shortfall quantities purchased at refresh-cycle discount rather than list, a support base recalculation on the licences you are redeploying rather than a straight carry-forward of an inflated legacy stream, and explicit removal of platform or system-specific restrictions embedded in the original ordering documents (older ODA orders sometimes name the appliance model, which Oracle can later read as a redeployment constraint). Get all four in the ordering document or an amendment, not in an email from a sales rep who will have moved territories by the time you are audited.
Expect two standard plays. The first is bundling the core-count shortfall into an Unlimited Licence Agreement you did not ask for, which converts a 12-core gap into a three-year commitment with a certification cliff at the end. The second is quoting the new appliance at full activated core count on the claim that "that is how ODA works." It is not: Capacity-on-Demand core activation lets you licence from 2 cores upward in multiples of two, up to 32 on X11-S, 64 on X11-L, and 128 on X11-HA. Ask the rep to point to the contract clause that requires full activation. There is none.
Sequence matters more than speed here, because two of these steps become irreversible once the hardware is registered or the cores are enabled. Work through them in order before the appliance leaves the loading dock.
Once the baseline is fixed, revisit the surrounding decisions with the same discipline. Confirm the activation arithmetic against the full ODA licensing and cost-trap guide, model whether KVM DB systems with dedicated CPU pools let you sub-divide a 64-core X11-L across workloads instead of licensing it whole, and check whether the retiring appliance can serve as a licensed disaster recovery target rather than being returned. A refresh handled in this order is licence-neutral. Handled in any other order, it is a true-up.
Yes. Oracle does not node-lock perpetual licenses, so you can redeploy the same processor licenses to the new appliance as long as the enabled cores multiplied by the core factor do not exceed the quantity you own. Check the original ordering documents first for platform or territory restrictions and for any counts certified under a ULA exit. No transfer fee applies, but you must keep the licenses under an active support contract if you want patches on the new box.
Oracle's licensing documentation states that adding the hardware Support Identifier to My Oracle Support establishes a license for all cores on the system. That makes SI registration a licensing act, not an administrative one. Trim cores to your target count before or immediately at deployment, and keep the odacli output as evidence of the enabled count.
X11-HA activates all 128 cores by default across two nodes. At a 0.5 core factor that is 64 Enterprise Edition processor licenses for the database alone, before options. Capacity-on-Demand lets you license from 2 cores upward in multiples of two, which is why the trimming step must happen at deployment rather than after go-live.
Yes. The Oracle contract requires licenses for every processor where the programs are installed or running, and there is no migration grace period. Either license both appliances for the overlap, buy short-term term licenses sized to the window only, or trim cores on the old appliance progressively as workloads move. Get the decommission date documented.
Both mainstream x86 lines currently carry a 0.5 factor in Oracle's Processor Core Factor Table, so the multiplier is unchanged for most buyers. Verify against the published table in force at the time of your order rather than assuming, because Oracle sets the table unilaterally. The factor applies to enabled cores, so the bigger variable is almost always the core count, not the chip vendor.
On licensing arithmetic, no. Per-core performance improves roughly 10 percent and socket core counts are identical at 32 per socket, so you cannot reduce your license count by moving to X11. Justify the refresh on support lifecycle, storage, and hardware reliability, then hold your enabled core count flat through the migration.
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.
