Oracle's default answer is no: licenses sit with the named legal entity, and a merger, acquisition, or carve-out is a trigger event Oracle prices rather than a formality it processes. This page shows exactly which clauses block the transfer, what Oracle demands in exchange for consent, and the assignment language to secure before you ever sign a deal.
How to Negotiate Your Oracle SaaS Renewal: The Five Moves at the Table
Scope before price: strip the 18 to 32 percent of inactive bundle modules first. Kill the escalator with a 0 to 3 percent cap that survives the term, trade term for protections, refuse the easiest-path module bundling, and close on Oracle's May 31 clock.
Oracle's default answer is no: licenses sit with the named legal entity, and a merger, acquisition, or carve-out is a trigger event Oracle prices rather than a formality it processes. This page shows exactly which clauses block the transfer, what Oracle demands in exchange for consent, and the assignment language to secure before you ever sign a deal.
Oracle grants licenses to a named legal entity, not to a business, a brand, or an IT estate. The grant in your Oracle Master Agreement, or the older OLSA, plus the ordering documents that hang off it, is personal to "Customer" as defined on the signature page, and it is non-transferable absent Oracle's prior written consent. That single sentence does more damage in M&A than any audit clause, because both sides of a transaction routinely assume the opposite. Absorbing an acquired company into your environment can itself be deemed an unauthorized transfer, and there is precedent of a merger being ruled an illegal license transfer. The most common failure mode I see is the "it's all internal now" assumption: two entities complete a deal, the shared services team consolidates the database estate, and licenses start serving users of a legal entity that was never a party to the contract. That is a breach, not an integration efficiency, and Oracle treats it as one.
The exposure is asymmetric, which is why one deal produces two separate problems. The acquirer inherits running deployments it has no entitlement for, often discovered months later when support renewal or a CSI reconciliation surfaces unfamiliar programs. The divesting parent holds the mirror image: entitlements it no longer needs, sitting on a support contract it keeps paying, that it cannot move to the buyer without Oracle's signature. Neither party can self-remediate. The parent cannot simply reassign, the buyer cannot simply claim, and Oracle is under no obligation to be helpful, particularly during the window when your team is consumed by integration work. Confirm before signing whether your agreements define "Customer" to include affiliates and subsidiaries, and read the assignment clause alongside your Oracle contract clause redline priorities rather than as an afterthought in the legal appendix.
Absorbing an acquired company into your Oracle estate is not integration; without written consent it is an unauthorized transfer.
Diligence teams frequently examine the wrong provision, then report a clean position that is anything but. The governing distinction is whether a new legal party joins the contract. In a share purchase, the contracting entity survives with the same name and the same registration; ownership above it changes. A general anti-assignment provision is typically not triggered, because no new entity becomes party to the agreement. The real question shifts to whether the contract contains a separate change-of-control consent clause, or language deeming a direct or indirect change of control to be an assignment. Many do. Asset purchases and carve-outs are the opposite case: the licenses are being moved to a different legal person, so the assignment clause fires directly and consent is unavoidable. Partial transfers, splitting a subset of licenses out to a spun-off entity while the parent retains the rest, are the hardest structure of all and are rarely permitted without Oracle's written agreement, because Oracle must be persuaded to divide a single CSI and support stream in two.
| Deal structure | Clause that fires | Oracle consent required | Typical Oracle ask | Residual risk |
|---|---|---|---|---|
| Share purchase (target entity survives) | Change-of-control clause, if present; general anti-assignment usually not triggered | Only if the agreement has CoC consent or deems CoC an assignment | Support repricing, removal of legacy discounts, entity re-scoping | New parent's affiliates using the target's licenses without contractual scope |
| Asset purchase (licenses move to buyer entity) | Anti-assignment clause, directly | Yes, prior written consent | Formal license assignment agreement, new order, transfer or uplift fee | Buyer runs unlicensed between close and executed assignment |
| Carve-out or spin-off (subset of licenses split) | Anti-assignment plus divestment clause | Yes, and Oracle may refuse a split | New agreement for the NewCo at current list-based pricing | Day-one gap at NewCo; parent still paying support on unusable licenses |
| Merged entities sharing one estate | Definition of "Customer" and assignment clause | Yes, unless affiliates already in scope | Retroactive true-up on the out-of-scope entity | Unauthorized-transfer breach claim, audit trigger |
Practical instruction: pull every Oracle agreement, ordering document, and CSI number in scope, then map each one against the structure actually being executed, not the structure described in the press release. Where multiple agreements exist across regions, assume the weakest assignment language governs the transaction and price accordingly. Feed that mapping into your Oracle M&A due diligence checklist before the purchase agreement is signed, because after close your only remaining lever is Oracle's goodwill.
Treat a merger or a carve-out as an administrative filing and you have already lost the negotiation. Oracle contracts are not built to accommodate corporate change; industry practitioners consistently describe M&A, acquisitions, and divestitures as trigger events that hand Oracle leverage to renegotiate on its own terms, and Oracle will force new agreements even where the underlying IT estate did not change by a single core. The mechanism is paperwork, not a courtesy notification: carving licenses out to a divested entity requires working with Oracle Sales to execute a formal license assignment agreement moving entitlements from parent to new entity. That document is the toll booth. Oracle knows you have a signed SPA, a separation date, and a board expecting synergy numbers, so the price of a signature is rarely just a signature.
Expect a demand set, not a request. In our experience across these transactions, the four asks are consistent: a true-up of the combined estate (every ambiguous deployment resolved in Oracle's favor), an uplift on the support base rather than a clean transfer of the existing stream, migration off legacy pricing and legacy policy documents onto current ones, and cloud or subscription conversion as the stated condition of consent. That last one is the real objective. Repricing to current list matters because the anchors are steep: Database Enterprise Edition at $47,500 per processor and $950 per named user plus, Partitioning at $11,500, Real Application Clusters at $23,000, with support at 22%, roughly $10,450 per EE processor per year. A 40 processor combined estate re-papered at current list is a nine figure conversation before options.
The second monetization channel is timing. Oracle launches audits precisely when integration or separation teams are consumed by other work, and the shift from legacy ordering documents to current terms is where policy exposure compounds, which is why the policies incorporated by reference problem deserves attention before you sign anything transactional. Run the entitlement reconciliation yourself, on your own timetable, using the Oracle M and A due diligence checklist, and hold the assignment request until your numbers are defensible. Never open with "we need consent by close."
Oracle does not process a merger, it prices one, and the price is usually a subscription you did not want.
The separation day mechanics are brutally simple and routinely missed. Entitlements were granted to the parent legal entity and they stay there. On day one after close, the divested unit is running Oracle Database, middleware, and options with no license of its own, while the parent holds licenses it no longer needs and cannot freely move. Both sides are exposed simultaneously: the buyer is using unlicensed software, and the parent is paying 22% support on a base it has functionally handed away. Nothing in the SPA fixes this, because Oracle is not a party to your SPA.
Two contract variables govern how fast the clock runs. The divestment clause sets the number of days before the divested unit's license rights terminate and specifies who must notify Oracle. The assignment clause sets the restrictions on any entity acquiring you and what rights survive if those conditions are met. Read both before the deal team commits to a close date, because a 30 day termination window and a 90 day carve-out plan cannot coexist. Where no grace language exists, rights end the moment the unit leaves your control.
Continuity pressure almost always forces a transition services arrangement under which the buyer temporarily runs on the parent's licenses. That is workable, but only if it is papered against Oracle, not merely between the two companies. A TSA schedule signed between seller and buyer creates no license rights whatsoever; it creates a documented admission that a third party used the parent's entitlements. Get a written Oracle acknowledgment of the TSA period, its end date, and the permitted user population, and attach it to the assignment request rather than negotiating it later under audit pressure. Standard buyer-side redlines on Oracle contract clauses should have anticipated this.
One more complication: the parent's own position is frequently ambiguous before Oracle is even contacted. Multiple ordering documents, multiple CSI numbers across regions, and inconsistent "Customer" definitions mean nobody can state cleanly which legal entity holds what. Resolve that internally first. You cannot assign what you cannot evidence.
If you hold an Unlimited License Agreement, that document is your largest single M&A exposure, and it is the one most executives assume is safest. The logic fails because "unlimited" describes deployment volume, not corporate membership. Standard ULA language scopes the grant to the named licensee and its majority-owned subsidiaries as of the effective date. That date is fixed. Every entity you acquire after signature sits outside the certifiable estate unless you negotiated explicit M&A scope expansion, and every entity you divest falls out of scope on the closing date, not at certification. Deployment teams read "unlimited" and provision freely; the contract reads "these entities, on this date" and Oracle reads it the same way at certification, which is the only moment the interpretation gets tested and the worst possible moment to discover a gap.
The worked example is depressingly common. A customer in year two of a five-year ULA acquires a competitor and the integration team migrates 200 Oracle Database servers onto the assumption of ULA coverage. At certification in year five, Oracle excludes the acquired entity from the count and asserts separate license obligations for those 200 servers. Typical unbudgeted exposure runs $4M to $12M, and it lands on a certification timeline where you have no negotiating room left. Across 40 to 50 benchmarked ULA engagements in 2024 to 2025, entity scope was drawn too narrowly at signature in roughly half of them, leaving recent acquisitions outside the estate. Where the arithmetic favored it, certify-and-exit saved 30 to 50 percent on the forward license position, so the remedy is often to stop feeding the agreement rather than renew it wider.
| Corporate event | Default ULA outcome absent negotiated language |
|---|---|
| Post-signature acquisition | Excluded from certifiable estate; separate obligations asserted at certification |
| Divestiture of a covered unit | Rights end on closing date; 6 month grace only if explicitly negotiated |
| ULA holder is acquired | ULA usually does not transfer; new parent inherits only certified quantities, no refund for unused term |
| Certification with divested entity in scope | No pro-rata allocation right; parent keeps the full certified count |
Two consequences deserve separate emphasis. First, divested entities typically receive only a six month transition grace period, and only where a clause was negotiated in advance; with no explicit grace language, rights terminate the moment the unit leaves your control, meaning day one unlicensed use. Second, when a ULA holder is itself acquired, the ULA generally does not travel to the acquiring parent. The parent inherits what was certified, with no refund for the unused portion of the term, so an acquirer paying for a target mid-ULA is often paying for an asset that evaporates at close. Model this in diligence using the Oracle licensing M&A due diligence checklist before you price the target.
The negotiable middle path exists and Oracle will discuss it: allocate a subset of the final certified quantities to the divested entity at certification, prorated by measured usage, and bar termination of the divested unit's rights before certification completes. For organizations running an active acquisition program, the PULA assignment clause is, in our negotiating experience, the single most underutilized lever on the paper. A PULA has no expiry, so the assignment terms govern indefinitely; the default position is that a divested entity walks away with nothing, and almost nobody redlines it at signature.
"Unlimited" describes deployment volume, not corporate membership, and the effective date freezes the membership list.
Every one of these clauses is cheap before a transaction exists and expensive afterward. Oracle prices consent against your urgency, and once a deal is announced, your urgency is a matter of public record with a closing date attached. Secure this language at initial signature or at renewal, when the leverage is a support renewal Oracle wants rather than a transaction you need. Fold the requests into the broader redline set covered in the Oracle contract clause negotiation playbook so assignment is not the only item on the table and can be traded against price rather than conceded for it.
Benchmark your position against general M&A drafting practice, because Oracle's counsel will argue anti-assignment language is market standard. It is: roughly 78 percent of mid-market M&A purchase agreements require prior written consent to assignment. But affiliate carve-outs appear in about 65 percent of those agreements, which is precisely the concession you are asking for. Oracle's default paper gives you neither the carve-out nor the reasonableness standard, putting it well behind ordinary commercial practice. Say that in the negotiation, in those terms, and make Oracle explain why its contract should be more restrictive than the market it operates in.
Start with document custody, not with Oracle. Pull every Oracle Master Agreement, legacy OLSA, ordering document, ULA, and PULA across every region and every CSI number, and extract the assignment, change-of-control, and divestment language into a single clause register keyed to CSI and legal entity. In practice, the exposure hides in the oldest paper: a 2009 OLSA with a bare anti-assignment clause sitting under a 2023 ordering document that inherits it. Read the Customer definition next, because that single sentence decides more than the assignment clause does. Confirm whether named affiliates, majority-owned subsidiaries, and post-signature acquisitions are inside scope, and note the effective date used to freeze that scope, since standard ULA language ties subsidiary coverage to the entities owned at signature.
Then baseline the estate before anyone notifies Oracle. Run deployment versus entitlement separately for the retained business and the separating business, on the assumption that entitlements stay with the parent and the divested unit starts day one with nothing of its own. Where the split is inside a ULA, model certify-and-exit against renewal, and model the allocation of a prorated subset of certified licenses to the divested entity, because that is negotiable and rarely offered. The CIO due diligence checklist for Oracle licensing in M and A sequences the diligence questions in the order counsel will ask them.
The sequencing rule is absolute: never open the assignment conversation with Oracle Sales until your own baseline is defensible and your redlines are drafted. Work the language cold, using the buyer-side Oracle clause redline guide, months before a deal exists.
Yes, if your agreement has a bare anti-assignment clause with no 'consent will not be unreasonably withheld' qualifier. Oracle is under no contractual obligation to approve a partial carve-out of licenses to a spun-off entity, and in practice it uses that position to price consent, typically as a true-up, a new agreement at current list, or a cloud commitment. The fix is negotiated in advance, not at deal time.
Usually not directly, because no new entity becomes a party to the contract, so a general anti-assignment provision is not triggered. The real question is whether your agreement contains a separate change-of-control consent clause, or language deeming a change of control to be an assignment. Read both provisions before concluding a share deal is clean.
Standard ULA language scopes the agreement to the named licensee and its majority-owned subsidiaries as of the effective date, so acquisitions made after signature are commonly outside scope. Oracle typically excludes the acquired entity's deployments at certification and asserts separate license obligations, which in benchmarked cases has run $4M to $12M unbudgeted. You need negotiated M&A scope expansion, ideally with a defined revenue or headcount threshold, at signature.
Only as long as your agreement says. Where a grace period has been negotiated it is often around six months; with no explicit divestment clause, the divested unit's rights end the moment it leaves your control. Ask for 12 to 24 months of transition rights plus a pro-rata allocation of certified licenses at ULA certification.
Establish your own deployment-versus-entitlement baseline first, then notify in line with whatever the divestment or change-of-control clause requires. Notifying early without a defensible baseline invites an audit at the exact moment your team is consumed by integration or separation, which is when Oracle's leverage is highest.
It is rarely free. Oracle Sales executes a formal assignment agreement, and the consideration is typically a true-up on the combined estate, repricing to current lists, migration onto current policy documents, or a subscription and cloud commitment. Pre-negotiated permitted-assignment language is the only reliable way to keep that price at zero.
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.
