Full narration of the briefing. Click a section heading to jump the player to that moment.
A divestiture is often a moment of celebration for a company, but it is also where Oracle licensing quietly costs the seller money. If you do not plan for your Oracle footprint before the unit leaves, you may find yourself paying for licenses the buyer is already using. The complexity of these contracts means that simple business separations are rarely simple for software compliance. Today, we will walk through the five mechanics you must master to protect your balance sheet during an entity exit.
We will cover the mechanics, the reasons behind them, a concrete worked example for each, and the counter move you need to deploy. The first point is that Oracle licenses are entity specific and are not transferable without written consent. The mechanic is simple; your contract lists the specific legal entities authorized to use the software. When one is sold, it loses that authorization.
Oracle restricts these transfers because they view the software as a license to a specific customer group, not a permanent asset. By requiring consent for assignment, Oracle maintains control and ensures they can capture new revenue from the buyer. Consider a case where a parent company sells a subsidiary relying on an Oracle database. If they assume the licenses just follow the business, they are mistaken.
Without a formal assignment, the divested unit is suddenly running unlicensed software on day one of the new ownership. Your counter move is to start the assignment approval process as soon as the deal is viable. Do not wait for the closing date. Secure the written consent for the license transfer as a condition of the separation, ensuring the buyer is covered and the seller is released.
Our second point involves the Unlimited License Agreement, or ULA. The mechanic here is that a ULA cannot be split. It is a single, enterprise wide contract. If you divest a unit during a ULA, that unit cannot take those unlimited rights with them.
This happens because the ULA certification only counts deployments for entities remaining in the company at the point of certification. If an entity leaves before that certification, its usage effectively falls into a black hole where neither the seller nor the buyer has a clear right to those licenses. Imagine divesting a division with five hundred Oracle processors two years into a three year ULA. Those are not yet perpetual licenses.
The divested unit leaves with zero licensed cores and a massive compliance gap that the buyer will immediately inherit. The counter move is to either certify the ULA early for the enterprise or carve out the entity in a mid term amendment. This crystallizes the usage into perpetual licenses that can be assigned. This must be handled months before the actual divestiture takes place.
The third point is often the most painful; support does not drop cleanly. The mechanic is driven by matching and repricing rules. If you terminate a portion of a license set, Oracle can reprice the remaining support you keep at a much higher rate. Oracle implements these rules to protect their recurring revenue.
They want to prevent customers from dropping pieces while keeping discounted rates. In a divestiture, this means your support bill might not actually go down even though you have fewer users and fewer systems to support. Suppose you divest half a business and try to stop paying support on half the licenses. Oracle reprices the remainder at list price.
You could end up paying nearly the same total amount for half the coverage. The savings you expected simply vanish into the reprice. Your counter move is to model the support hit before you agree to anything. Calculate the exact repricing impact early on.
If the cost is too high, you might choose to keep the licenses or negotiate a specific support waiver with Oracle before closing. The fourth point is about the transition period. The buyer needs their own Oracle paper eventually, but there is often a gap. The transition license bridges the time between the deal closing and the buyer standing up their own independent Oracle environment.
This gap exists because the buyer is a new legal entity. The software license does not automatically follow just because a TSA is in place. Oracle views this as a separate licensing event that requires its own agreement. Using the seller's hardware does not grant software rights.
A buyer might need six months to migrate acquired data. During those months, they are technically using the seller's Oracle licenses. Unless a transition license is negotiated, the seller is effectively hosting an unlicensed third party, which is a major compliance violation for both. The counter move is to negotiate this bridge as part of the overall deal, ideally well before the close of the transaction.
Work with Oracle to define a fixed term and price. This avoids the buyer being held hostage by Oracle after the seller loses leverage. The fifth and final point is about timing and documentation. The mechanic here is the formalization of the entire entity exit.
Everything, including the assignment and the support treatment, must be in writing before the entity leaves your corporate control. This is critical because verbal assurances from an account manager do not hold any weight during a formal Oracle licensing audit. If the documentation is not signed before separation, Oracle can claim usage was unauthorized, creating a legacy liability for the seller. If you divest a unit during an active audit, Oracle will likely include that unit's usage in the final expensive settlement.
Wait until the audit is closed and you have a clean bill of health. The sequence of events is as vital as the events themselves. Your counter move is to audit proof your exit. Perform your own internal count of the divested unit's deployment before you talk to Oracle.
Get the written assignment and the support reprice finalized before closing day. Ensure the unit leaves with a clean slate and no ties. When we talk about licensing quietly costing the seller money, we are often talking about the erosion of the total deal value. If a divestiture is worth one hundred million, but carries five million in hidden licensing fees, that is a direct financial loss.
These are not one week conversations. They are multi month engagements requiring coordination across legal, procurement, and technical teams. Starting early is a necessity for a smooth transition. Global divestitures add layers of complexity across different regions and local laws.
The risk of non compliance is also a reputational one. A buyer who finds themselves in a dispute may lose trust in the seller. By spending the time now, before the separation, you are essentially buying insurance against future audits and ensuring peace of mind. If you take only one thing from this briefing, let it be this: secure Oracle's written assignment and support treatment before the unit separates.
Without that piece of paper, you are leaving your financial flank exposed. Do not rely on promises; rely on signed amendments. Managing an Oracle divestiture requires a steady hand and a clear plan. Following these five points ensures a clean and compliant exit.
Thank you for your time, and good luck with your transition. We are here to help if you need further guidance with your strategy. Remember that the best defense in an Oracle negotiation is always preparation. Take the time to model your footprint and document decisions.
Your future self will thank you for the diligence you show today. Goodbye for now.
Redress Compliance works on contingency: our fee is 25 percent of what we save you. Nothing saved, nothing paid. Independent, buyer side only, never vendor funded.
Talk to a Oracle negotiator