Oracle licenses are entity-bound and do not follow a divested unit, so a carve-out is two licensing events, not one. This page shows which entitlements can travel, how the support repricing policy quietly destroys expected savings, and how to structure the split before the deal closes.
Oracle licenses are entity-bound and do not follow a divested unit, so a carve-out is two licensing events, not one. This page shows which entitlements can travel, how the support repricing policy quietly destroys expected savings, and how to structure the split before the deal closes.
Start from the fact that decides everything else: Oracle licenses are bound to a legal entity and are non-transferable without written consent. When a parent sells a business unit, the Oracle licenses that unit ran on do not travel with it. They were granted to the parent, and they remain with the parent. On day one after close, the divested entity can be running Oracle software with zero entitlement of its own, while the parent holds licenses it no longer needs but cannot freely reassign.
The contractual anchor is the definition of the licensed customer. Oracle defines that as your company and its majority-owned (greater than 50 percent) subsidiaries. A departing entity loses its rights the moment it is no longer majority-owned. There is no automatic grandfathering, no implied license, and no goodwill carry-over. If you have not built an accurate Oracle effective license position before the deal, you are negotiating the split blind, and Oracle knows it.
In our experience across 25 years of these transactions, buyers consistently underestimate how one-sided the starting position is. The clauses that govern the outcome, the assignment clause, the change-of-control clause, the affiliate definitions, and any ULA merger language, were signed years before anyone contemplated a divestiture. By the time the corporate event is announced, the leverage has already been distributed. Your job is to work within it, not to wish it away.
In a divestiture the licenses do not follow the unit. The carve-out needs its own agreement, and the parent must right-size the estate it keeps.
For every Oracle workload the divested unit relies on, there are three ways to resolve the gap, and you should choose deliberately for each one:
The critical discipline is to decide path by path, not to treat the whole estate as one transaction. A large, stable production database may justify a negotiated transfer because migration risk is high. A portable middle-tier application may be far cheaper to move than to license. Bundling everything into a single ask hands Oracle the pricing power to inflate the entire package. Deciding workload by workload produces the lowest total cost, which is why a clean reconciliation of entitlements to deployment is a prerequisite, not a nice-to-have.
Partial transfers, which is exactly what a carve-out is, are the hardest case Oracle will consider. Oracle contracts commonly prohibit transferring licenses to another entity without prior written approval. Some agreements permit assignment on a full merger, but partial transfers to a spun-off company are rarely permitted contractually. Oracle resists writing the transfer right into the paper, yet it does grant transfers ad hoc in practice. Gartner's long-standing read (G00211213) is consistent with ours: this is a business decision Oracle makes case by case, sometimes yes, sometimes no.
Where Oracle agrees to a transfer, the mechanism is a formal license assignment agreement executed with Oracle Sales that moves specified entitlements from the parent to the divested entity. This is not a self-service process, and it is not something the transaction lawyers can paper on their own. The entitlements have to be identified precisely, usually down to the ordering document and CSI number, and Oracle has to countersign.
Expect Oracle to attach conditions. The most common is a true-up: before consenting to the split, Oracle audits both sides to confirm the deployed footprint matches entitlement. If either the parent or the carve-out is over-deployed, that gap becomes a purchase order as a condition of consent. This is why a divestiture is one of the highest-audit-risk moments in the Oracle relationship. Build your defensible position first. A license position built before the event beats one built during it every time, because the transfer request itself functions as a soft audit trigger.
Divestitures usually include a Transition Service Agreement (TSA) that keeps the carve-out operating on shared systems for a period. Oracle sometimes grants a matching divestiture period, but the default is short. A typical window is around 90 days, after which the divested entity must stop using the parent's licenses and acquire its own.
Ninety days is rarely enough to negotiate a new Oracle agreement, stand up a certification, or complete a migration. Gartner's guidance, which matches what we see, is to build a longer runway into your Oracle contracts before any deal is contemplated: include the right to process for a divested entity for 12 months. The real ordering-document language is instructive. In the Taleo divestiture-period template filed with the SEC, the divested entity may use the programs during the divestiture period, but at the end of that period it has no rights, and to continue it must acquire licenses and support at Oracle's then-current prices under a mutually agreeable license agreement. Read that as: the clock is a wall, and on the other side of it you pay list.
| Element | Typical default | Buyer target |
|---|---|---|
| TSA / divestiture use period | ~90 days | 12 months, written into master agreement |
| Right to transfer to divested entity | Not in contract, ad hoc consent | Pre-negotiated assignment right |
| Pricing basis for carve-out's new deal | Oracle then-current list minus standard discount | Discount and metric parity carried forward |
| Support repricing on parent's retained set | List minus standard discount on remainder | Structured to avoid triggering the clause |
This is where most carve-outs lose money they never budgeted for. When you divest part of the estate, you naturally want to drop support on the licenses that leave the parent. Oracle's Software Technical Support Policies (dated 17-Aug-2026) state that if a subset of licenses on a single order is terminated, or support is reduced, support for the remaining licenses on that order is repriced at Oracle's list price for support in effect at the time, minus the applicable standard discount.
Read that carefully. Your remaining licenses get repriced from list, stripping away the negotiated discount you accumulated over years. The Matching Service Levels policy compounds it by blocking you from de-supporting only part of a license set. The practical outcome is brutal: dropping 37.5 percent of an estate can cut the support bill by nothing at all, because the repricing of the remainder claws back exactly what the termination saved.
Dropping 37.5 percent of an estate can cut the support bill by nothing, because repricing the remainder claws back every dollar the termination saved.
There is one protection worth knowing: the repriced cost cannot exceed the previous total support cost for that order. But that cap frequently means there is simply no saving, in which case it can be more advantageous to retain the licenses you intended to cancel rather than terminate them for nothing. Understanding where your shelfware sits and what it is actually worth is central to this call, because the repricing math changes which licenses you should keep.
The single most useful structural fact is that repricing is limited to the licenses within a single order, and orders are identified by CSI numbers. Support terminations on one order cannot affect the price of licenses on a separate order. This is the lever.
If the licenses the divested unit uses sit on their own order or CSI, cleanly separated from the parent's retained licenses, you can terminate or transfer that set without repricing the parent's remaining support base. If everything is commingled on one large order, you are exposed. The buyer-side move is to negotiate single-product license sets wherever possible and to split sets along the business-unit boundary well before the divestiture, ideally at renewal. Only granular sets open a partial-termination path; a single monolithic set forces full-footprint coverage under Matching Service Levels.
Practically, this means working the CSI structure at least twelve months ahead of any anticipated corporate event, folding it into your normal license position refresh cadence. If you already know a unit is on the block, treat CSI re-alignment as the first workstream, before you ever open a transfer conversation with Oracle Sales.
If your estate is under a Unlimited License Agreement (ULA) or Perpetual ULA (PULA), a divestiture collides directly with certification rules and can strip value overnight. ULA certification is a hard window, commonly 30 to 90 days around term end. Miss it, or certify a weak count, and you can revert toward your original pre-ULA entitlement. A divestiture that happens near certification forces you to certify a footprint that is about to change, and Oracle will not let you count deployments in an entity that is leaving your majority ownership.
Entity scope is where this goes wrong. Redress work found entity scope was drawn too narrowly at signature in roughly half of cases reviewed, leaving recent acquisitions outside the certifiable estate. The same defect blocks a clean divestiture: if the covered-entity definition does not clearly bound what the divested unit can certify or take, you enter the negotiation with an ambiguous position that Oracle resolves in its favor.
PULAs are worse by default. The PULA assignment clause is the most underused lever in the document, because the default position in most PULAs is that a divested entity loses all PULA rights immediately on divestiture. If you do not negotiate the assignment terms up front, the carve-out walks away with nothing and must buy a fresh agreement at current pricing. Plan the certification timing and the entity carve-out language before the corporate event closes, never after.
Sequence the work in this order, and start no later than twelve months before an anticipated event:
The overriding principle: a carve-out is two licensing events handled at once, the parent right-sizing and the carve-out standing up its own position. Both cost far less when planned before the deal signs. Once the transaction closes and the divested entity is running Oracle with no entitlement, every option you had shrinks to whatever Oracle chooses to grant, at whatever price it chooses to set.
No. Oracle licenses are bound to the legal entity that holds them, and in a divestiture they remain with the parent. The divested unit has no entitlement of its own on day one unless Oracle executes a formal license assignment agreement, which it grants case by case and usually conditions on a true-up and current pricing.
The default divestiture or TSA period is short, often around 90 days, after which the unit must stop and acquire its own licenses at Oracle's then-current prices. We advise negotiating a 12-month process window into your master agreement before any deal is contemplated, because 90 days is rarely enough to complete a new agreement or a migration.
Oracle's support policy reprices the remaining licenses on the same order at list minus the standard discount when a subset is terminated, and Matching Service Levels blocks de-supporting only part of a set. The repricing can claw back the entire saving, so dropping a large share of an estate can reduce the bill by zero. The saving is capped at the prior total, so retaining the licenses is sometimes cheaper than terminating them.
Support repricing is limited to the licenses within a single order, identified by CSI number. If the divested unit's licenses sit on their own order, you can terminate or transfer them without repricing the parent's retained support. Splitting sets along the business-unit boundary ahead of the divestiture is the main structural lever for protecting your discount.
ULA certification runs on a hard window, and a divestiture near term end forces you to certify a footprint that is about to change while excluding the departing entity. Most PULAs default to stripping the divested entity of all rights immediately. Confirm entity scope, plan certification timing, and negotiate the assignment clause before the corporate event closes, not after.
Oracle generally resists putting a divested-entity transfer right in the paper, treating it as a business decision it makes at the time. You can and should negotiate the right to process for a divested entity for a defined period, up to 12 months, and clarify affiliate and change-of-control definitions. That reduces the leverage Oracle holds when the event actually arrives.
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.
