When you sell a business unit during an Oracle ULA, the unlimited right normally stays with the named customer and the divested deployments fall outside scope on completion. That gap can strand the buyer without licenses and leave you with a remediation question at exit, so the licensing position has to be settled in the deal, not discovered at certification.
A divestiture is one of the few events that can quietly damage an Oracle ULA from the inside. The agreement was scoped around a set of entities at signing, and selling one of them changes who is entitled to deploy without changing the contract that says so. The result is a mismatch between where Oracle products are running and who holds the right to run them. This article explains how that mismatch arises, who keeps the unlimited right, and what to settle before a sale completes. Because every outcome here turns on the exact customer definition and assignment language in your agreement, treat the structure as the map and confirm the route against your own contract.
It depends on the customer definition and the assignment clauses in your agreement. The unlimited right usually attaches to the legal entity named as the customer, together with whatever affiliates the definition includes. When a business unit is sold, it leaves that group on completion, and the deployments that travel with it are no longer covered by the ULA from that date. On your side, those deployments may have already inflated expectations of the count. On the buyer side, the same systems can become unlicensed the moment the deal closes. Neither outcome is automatic in your favour, and neither is visible unless someone reads the scope language against the transaction perimeter before signing.
A ULA is scoped to entities, not to servers. When an entity leaves, the servers do not keep their rights. Settle the licensing in the deal while you still control both sides of the table.
Not automatically. A ULA is rarely transferable without Oracle consent, so a buyer cannot inherit unlimited deployment rights simply by acquiring the business. The Oracle products the buyer takes usually need their own licenses, a transition services arrangement that keeps them inside your scope for a defined window, or a fresh agreement negotiated directly with Oracle. Each of those is a commercial item with a cost and a deadline, and each one belongs in the sale and purchase agreement rather than in a side conversation after close. Where the deal is silent, the buyer carries unlicensed deployments and the seller carries a representation risk, and Oracle holds the leverage to resolve both on its terms.
| Structure | Where the unlimited right sits |
|---|---|
| Asset sale of a unit | Stays with the named customer; divested systems fall outside scope on completion |
| Share sale of a subsidiary | Turns on whether that subsidiary is inside the customer definition; if it leaves the group, it leaves the ULA |
| Carve out with transition services | Buyer may run inside scope for the agreed window only, then needs its own licenses |
| Spin off to a new entity | New entity is outside the customer definition unless Oracle agrees otherwise |
Outcomes are indicative and depend on your customer definition and assignment terms.
The count you can certify is the deployment inside scope when the term ends, so the question is whether the divested systems are still yours on that date. If the sale completes before certification, those deployments leave with the buyer and cannot be counted toward your perpetual entitlement, which lowers the number you carry forward. If certification falls first and the term allows it, the deployments may still be inside scope on the certification date and count toward your entitlement, although you then hold perpetual licenses for systems you are about to sell. Neither path is automatically better. The right sequence depends on the value of the deployments to each side, the timing against the ULA clock, and whether the buyer is paying for the licensing certainty you can provide.
It depends on timing against the ULA clock and the deal calendar, and the honest answer is that you should model both before either is fixed. Certifying ahead of completion can lock a larger count while the divested deployments are still inside scope, but only where the term permits certification at that point and the evidence file is ready to defend the number. Waiting until after completion produces a cleaner count that matches the business you are keeping, but forfeits the divested deployments. The decision is a commercial one disguised as a procedural one, and it is best made with the deal team, the licensing position, and the contract language on the same table. Leaving it to whoever signs the certification letter last is how value leaks out of a transaction.
A divestiture is a scope event, and scope events are won or lost in the contract reading, not the system count. Pair this with notifying Oracle of corporate change for the disclosure mechanics and the M&A clause language that protects you for the wording to fight for at signing. For the end to end view of getting out cleanly, read the ULA exit strategy guide.
It depends on the customer definition and assignment clauses in your agreement. The unlimited right usually stays with the entity named as the customer, so a divested unit typically loses access to the ULA on completion unless the contract or a negotiated carve out says otherwise. Deployments that leave with the buyer can become unlicensed on their side and a remediation question on yours.
Not automatically. A ULA is rarely transferable without Oracle consent, so the buyer cannot inherit unlimited rights simply by acquiring the business. The deployments they take usually need their own licenses or a transition arrangement agreed with Oracle. Selling without addressing this leaves both sides exposed, which is why the licensing position belongs in the deal terms.
It depends on timing against the ULA clock and the deal calendar. Certifying before completion can lock the count while the divested deployments are still inside scope, but only if the term allows it and the evidence is ready. The decision turns on your contract and the sequence of events, so model both paths before the transaction closes rather than after.
Book a confidential assessment and we will map your scope against the transaction, protect the count, and keep both sides clear of remediation.