When you sell a business unit that runs Oracle under a ULA, the unlimited right does not travel with it. The buyer leaves your customer definition, the deployments leave your count, and the separation has to be planned against your certification clock so neither side ends up with unlicensed usage.
A divestiture splits your estate, and a ULA does not split with it. The unlimited right stays with the entities your contract names, so a unit that is sold takes its Oracle usage out of scope on the day it leaves. Handle the timing of certification, the buyer transition, and the evidence before the deal closes, because afterwards the picture is frozen and the leverage is gone.
A ULA grants unlimited deployment of named Oracle products to a defined customer, for a fixed term, for a fixed fee. The customer definition is the boundary. It lists the legal entities that hold the unlimited right, and only those entities are covered. When you divest a business unit, you are changing that boundary. The unit you sell moves outside the definition the moment the deal closes, and with it goes any Oracle running there.
This matters because the unlimited right is not a property of the software, it is a property of the contract. A database that was perfectly licensed yesterday becomes unlicensed the day its host entity leaves your scope, unless the buyer has arranged its own entitlement. Oracle treats a divested unit as a new, separate customer with no ULA behind it. That is the gap a sale opens, and closing it is a buyer side problem for both companies.
A divestiture does not pause the ULA clock. Certification still arrives on its date, so the deal and the exit have to be sequenced together or one will undermine the other.
This is the question that decides the whole engagement, and the answer depends on your contract and the structure of the deal. There is no default. The two sequences produce very different outcomes, and the right one is a commercial judgement made on the facts.
Certify before close and the unit is still inside your customer definition, so its deployments are eligible to count toward your perpetual entitlement. That suits a carve out where you will retain the licenses, or where a transition services agreement keeps you running the systems for a period after the sale. Certify after close and you measure only what you actually keep, which gives a cleaner final count but forfeits any value tied to the departing unit. The trap is certifying departing deployments into a count you will not own, then losing them on close and having paid attention to a number that was never yours.
The figures below are indicative and exist only to show the mechanics. A manufacturer holds a ULA with roughly 900 processors deployed across the group. A unit representing about 250 of those processors is being sold. The table shows how timing changes the count the parent keeps.
| Approach | What counts for the parent | Risk |
|---|---|---|
| Certify before close, retain licenses | Full group count, including the 250, if a transition agreement keeps them in scope | Retained licenses for systems you no longer operate become shelfware to manage |
| Certify before close, licenses follow the unit | About 650 processors, the unit carved out by agreement | The carve out terms must be agreed with Oracle in advance |
| Certify after close | About 650 processors, measured clean | No claim to the departing deployments and a tighter window to act |
The point of the table is not the numbers, which are indicative, but the shape of the decision. The same estate produces a different perpetual entitlement depending on when you certify relative to the deal. That is leverage, and it only exists before the documents are signed.
The buyer inherits running Oracle systems with no license behind them, because your ULA does not transfer. Three paths exist, and which is realistic depends on the buyer, the deal value, and Oracle's appetite. The buyer can negotiate an assignment or partial assignment of entitlements as part of the transaction, subject to Oracle's consent, which Oracle rarely gives without commercial discussion. The buyer can buy its own perpetual licenses for the inherited deployment. Or the buyer can migrate or decommission the Oracle workloads within a transition period so the exposure never crystallises.
None of these is automatic, and the assignment of Oracle agreements almost always requires Oracle's written consent, which is a negotiation in its own right. The cleanest deals settle the Oracle position in the purchase agreement, with a defined transition window and a clear allocation of who licenses what. The messiest leave it to be discovered after close, when both sides have lost the leverage that the open deal gave them.
Whether entitlements can be assigned, and on what terms, is governed by your specific agreement and Oracle's consent. Treat assignment as a thing to be negotiated, never as a right you already hold.
Audit risk rises in the first two years after certification, and a divestiture makes the evidence harder to hold. When a unit leaves, the servers, the discovery data, the administrators who knew the estate, and the records that prove what ran where all leave with it. If your certified count included deployments that have since moved to the buyer, you need to be able to show that they were in scope on the certification date and that they left cleanly afterwards. Without that record, a later audit can read a departed deployment as a current shortfall.
The fix is to capture the evidence file before separation, not after. Snapshot the deployment, the entity each system sat in, and the date of transfer, and keep that record on the parent side even as the systems leave. The evidence behind a certified count is the defense, and a divestiture is exactly the kind of corporate change that erodes it if no one is watching the licensing clock alongside the deal clock.
If a divestiture is on the table and Oracle runs inside the unit, the first move is a scope and timing reconciliation: map every Oracle deployment to a legal entity, identify what leaves and what stays, and model certification before and after close so you can see the count each path produces. Two companion notes connect directly: acquisitions during the ULA term on how scope expands when you buy rather than sell, and the corporate change checklist for ULA holders for the controls that keep every entity move visible. The wider method sits in our ULA exit strategy guide.
No, not once it leaves your customer definition. The unlimited right belongs to the entities named in your ULA. When a unit is sold and exits that definition, its Oracle usage is no longer covered, so the buyer needs its own license position and you need to handle the separation before it becomes unlicensed usage.
It can. If you certify before the divestiture closes, deployments in the unit can count toward your perpetual entitlement, but only for systems that remain yours. Deployments leaving with the buyer should not be certified into your count because you will not keep them. The timing of certification against the deal close decides the outcome.
It depends on your contract and the deal structure. Certifying before close locks the count while the unit is still inside scope, which suits a carve out you will retain licenses for. Certifying after close gives a cleaner picture of what you actually keep. The right sequence is a contract and commercial question, not a default.
We map what leaves with the unit, model certification before and after close, and settle the Oracle position while the deal is still open. Book a confidential assessment.