Oracle divestiture licensing is one of the most expensive blind spots in carve-out transactions. Oracle's licenses stay with the contracting parent — they do not follow the divested business unless Oracle consents in writing. Get the transfer mechanics wrong and the carve-out entity can open Day One with no Oracle rights at all, while the seller carries audit exposure for serving it. This guide is the buyer-side and seller-side playbook.
Short answer: In an Oracle divestiture or carve-out, Oracle licenses remain with the seller — the original contracting entity — and do not transfer to the divested business without Oracle's prior written consent. The carve-out entity has no right to run Oracle software at close unless transfer or fresh licensing has been negotiated into the deal first.
A divestiture is the sale or separation of a business unit, subsidiary, or asset group from a parent company. A carve-out is the operational and contractual work of standing that unit up as an independent business — replicating the IT estate, contracts, and entitlements it relied on while inside the parent. Oracle divestiture licensing is the discipline of making sure the separated unit has the legal right to run the Oracle software it depends on from the moment it leaves the parent's corporate boundary.
The trap is structural. Oracle contracts are signed by a named legal entity, and the rights they grant attach to that entity and its qualifying affiliates — not to whoever happens to be running the software. When a unit is carved out, it stops being an affiliate of the seller at close. Every Oracle Database EE instance, every WebLogic deployment, every Diagnostics Pack option that the unit was using under the parent's agreements becomes, at close, unlicensed software running on a company that has no Oracle contract. This is not a technicality Oracle overlooks; it is a back-license claim waiting to be made.
For broader transaction context, see our Oracle licensing in M&A due diligence guide, which covers acquisitions and combined-entity exposure. This guide focuses on the seller's side — the separation event itself.
Short answer: No — not automatically. Oracle's Master Agreement prohibits assignment of licenses without Oracle's prior written consent. In a divestiture, the licenses remain with the seller, and the divested entity acquires no Oracle rights unless Oracle agrees, in writing, to transfer or re-license those entitlements to the new owner.
This single restriction governs the entire transaction. It means a carve-out cannot be planned as if Oracle entitlements move with the people and servers that use them. Three outcomes are possible, and the deal team must choose deliberately between them: the seller secures Oracle's consent to transfer specific entitlements to the buyer; the buyer licenses the relevant Oracle products fresh under a new agreement; or the unit migrates off Oracle entirely before separation. Doing nothing is the fourth, default — and worst — outcome: an unlicensed entity at close.
Transfer is also rarely clean even when granted. Oracle typically transfers only the specific quantities and products named in the consent, recalculated against the divested unit's actual deployment. Support contracts (CSIs) must be split, which Oracle uses to reset support fees to current rates. And Oracle will not transfer a discount — the divested unit inherits Oracle's current list-price posture, not the parent's historically negotiated rates.
| Separation structure | License treatment | Oracle consent required? | Primary risk |
|---|---|---|---|
| Asset sale of business unit | Licenses stay with seller; do not transfer automatically | Required for each license transferred | Buyer unlicensed at close unless consent secured |
| Spin-off / new independent entity | New entity is outside the parent's agreements at close | Required to license the spun-off entity | No Oracle rights for the new company on Day One |
| Equity carve-out / partial IPO | Depends on whether entity remains a controlled affiliate | Review affiliate definition in the Master Agreement | Loss of affiliate status ends coverage |
| Sale to existing Oracle customer | Buyer may fold deployments into its own agreements | Required to add to buyer agreements | Buyer's own compliance gap and pricing reset |
Transfer consent is where Oracle's commercial agenda meets your deal timeline — and the timeline favors Oracle. Once a transaction is signed and announced, the divested unit needs Oracle rights by a fixed close date. Oracle knows this, and Oracle's playbook is to condition consent on terms that benefit Oracle: migration to current pricing, conversion of perpetual licenses to subscription, mandatory support reinstatement, and the quiet loss of any legacy discount or favorable metric.
The defense is sequence. The right time to push back is before signing, when the deal can still be structured around what Oracle will and will not allow. Buyer-side advisors model Oracle's likely consent position during diligence, price the transfer realistically, and build the cost into the deal economics rather than letting it surface as a post-signing surprise. Our Oracle contract negotiation service runs the transfer-consent negotiation directly, and the tactics in our Oracle negotiation guide apply with full force here: never let Oracle set the clock, and never negotiate consent and pricing as separate conversations — Oracle will.
The consent clock: Oracle's standard tactic is to slow-walk transfer consent until the close date is near, then present terms knowing the buyer has no time to walk away. Open the consent conversation early, in parallel with diligence, and keep the migration-off-Oracle option visibly on the table to preserve negotiating leverage.
A Transition Service Agreement (TSA) is a short-term arrangement under which the seller continues to provide IT services — including access to Oracle-licensed systems — to the divested entity for a defined period after close. TSAs are standard in carve-outs because the buyer rarely has independent IT stood up on Day One. For Oracle, though, a TSA is a compliance question: the seller is now running Oracle software on behalf of a company that is no longer its affiliate.
Oracle's position is that its licenses are granted for the licensee's own internal business operations, not for providing services to a third party. A TSA that runs too long, covers too much, or looks like an ongoing managed-service arrangement can be challenged as an impermissible sub-license — putting the seller in breach. The exposure sits with the seller, who holds the licenses, even though the benefit flows to the buyer.
The practical controls are duration and scope. Keep the TSA to a defined, short transition window — long enough to migrate, not long enough to look permanent. Limit it to the specific systems being transitioned. Where possible, secure Oracle's acknowledgment that the TSA period is covered, and time the license transfer or fresh licensing to land before the TSA expires. Where the seller continues running shared infrastructure, our license optimization advisory helps right-size the residual estate after the unit departs.
A ULA (Unlimited License Agreement) is a fixed-term Oracle contract granting unlimited deployment of named products within the contracting entity and its qualifying affiliates, in exchange for a single upfront fee. The unlimited right is bounded by the corporate boundary — and a carve-out moves a unit outside that boundary at close.
Two consequences follow. First, the divested unit loses its unlimited deployment rights at close; from that moment its Oracle usage is unlicensed unless separately addressed. Second, the seller cannot certify the divested unit's deployments at the end of the ULA term — those deployments are no longer inside the entity being certified, so they do not convert into perpetual licenses for anyone. The unit gets neither unlimited rights going forward nor a certified license snapshot. Both sides lose unless the deal handles it.
Some ULAs contain explicit divestiture clauses that grant the divested entity a limited, perpetual snapshot of deployments as of the separation date — but this is the exception, and the language must be read precisely. If you are managing a ULA through any corporate event, our Oracle ULA guide covers certification mechanics and the divestiture and merger provisions that determine what, if anything, the separated unit walks away with.
Our compliance review advisory delivers a forensic, buyer-side Oracle exposure assessment for divestitures and carve-outs — before you sign, while you still control the terms.
Divestiture licensing is a workstream, not a checkbox. The sequence below is what an evidence-based separation looks like; run it before signing wherever the deal allows.
For sellers, an independent Oracle license review 6–12 months before a planned sale pays for itself: it identifies gaps that can be remediated before buyer discovery, produces a clean position that reduces diligence friction, and gives you the documentation to engage Oracle proactively rather than under deal pressure.
Oracle's Global Licensing and Advisory Services (GLAS) team monitors public divestiture and spin-off announcements the same way it monitors acquisitions. A separation announcement signals that one or both entities may now be using Oracle software outside their entitlements — and that is precisely the trigger Oracle looks for. Expect the possibility of a compliance review of the parent, the divested entity, or both within 90–180 days of a public announcement.
The carve-out entity is the more exposed party: a company running Oracle Database EE or Java SE with no Oracle contract is a clean back-license claim, and Oracle will price it aggressively. The seller's exposure runs through the TSA — continued service to the separated unit beyond Oracle's tolerance. The defense in both cases is to have closed the gap before Oracle makes contact. If Oracle has already initiated a review, our Oracle audit defense service provides forensic, buyer-side representation, and our guide to how corporate transactions trigger Oracle audits explains the mechanics Oracle uses to time its contact.
None of this requires conceding to Oracle's agenda. It requires sequence, evidence, and independent advice that sits on the buyer's side of the table. Start with the home of our Oracle licensing advisory or talk to a former Oracle insider through our contact page.
No. Oracle perpetual licenses are non-assignable without Oracle's prior written consent. In a divestiture or carve-out, the licenses remain with the seller — the original contracting entity. The divested business has no right to use Oracle software at close unless Oracle has agreed in writing to transfer or re-license those entitlements to the new owner.
A Transition Service Agreement lets the seller keep running Oracle-licensed systems for the divested entity for a defined period after close. Oracle's terms restrict this: continued use by a separated, non-affiliate entity can be challenged as an impermissible sub-license if the TSA runs too long or its scope is too broad. Match TSA duration and scope to Oracle's contractual tolerance.
A ULA covers the contracting entity and its qualifying affiliates. When a unit is carved out, it leaves the ULA's corporate boundary at close and loses unlimited deployment rights. Deployments at the divested unit are not certifiable by the seller and are not licensed for the buyer. Some ULAs grant a limited license snapshot to the divested entity, but this must be confirmed in the contract language.
Yes. Oracle's GLAS team monitors public divestiture announcements and routinely opens compliance reviews of the parent, the separated entity, or both. A carve-out entity running Oracle software without transferred entitlements is exposed to a back-license claim; the seller is exposed if it continues to serve the divested unit under a TSA beyond Oracle's tolerance.
Inventory the divested unit's Oracle deployments before signing, decide product by product whether licenses transfer or the buyer licenses fresh, secure Oracle's transfer consent in writing during the deal, and size any TSA to a defined, short transition window. Negotiate consent and pricing together as part of the deal — not after close, when Oracle holds the leverage.
Almost never. Oracle does not transfer historical discounts. When it consents to a transfer or licenses the divested entity fresh, it resets pricing to its current posture — list price less whatever the divested entity can independently negotiate. Buyer-side negotiation at the point of transfer is the only practical way to recover meaningful discount for the new entity.
The complete independent due diligence framework for Oracle licensing in mergers, acquisitions, divestitures, and carve-outs — transfer rules, ULA mechanics, TSA risk, and post-close integration.
Download Free Checklist →Independent analysis on Oracle licensing in divestitures, audit defense, and contract negotiation — for enterprise buyers, PE sponsors, and corporate development teams.