A deal that closes during your ULA term can put Oracle deployment outside the entities your contract covers. That gap is invisible until certification, when it turns from a corporate event into a licensing bill.
By Daniel Voss · Ex Oracle LMS · 4 June 2026
A ULA covers a defined customer, usually a named legal entity and its majority owned affiliates as they stood at signing. An entity acquired during the term is covered only if the customer definition reaches it, and often it does not by default. Deployment in an out of scope acquired entity is unlicensed from the day the deal closes, and certification cannot convert it, because you can only certify deployment inside the definition. The merger that looked like a corporate matter becomes a remediation demand at the exact moment the count is frozen. Every deal during the term needs checking against the customer clause.
Every ULA names a customer, and that name does more work than it appears to. It usually means a specific legal entity plus its majority owned affiliates, fixed as they existed when the agreement was signed. Everything inside that boundary enjoys the unlimited right. Everything outside it does not. For a stable organisation this is a quiet clause that never causes trouble. For an organisation that buys, sells, or restructures during the term, it is one of the sharpest edges in the whole contract.
The reason mergers and acquisitions interact so badly with the customer definition is timing. The definition is anchored to the signing date, but the business keeps changing. An acquisition adds a new legal entity that did not exist within your group when the ULA was signed, and whether the unlimited right extends to it depends entirely on the wording. Some definitions automatically include later acquired affiliates. Some include them only up to a revenue or employee threshold. Some exclude them unless formally admitted. The same acquisition can be fully covered, partly covered, or wholly outside scope depending on a sentence you may not have read since signing.
Sometimes, and the wording decides. There is no universal rule, so the only reliable answer comes from reading your own customer definition against each deal. Three patterns are common, and they produce very different exposures.
Some definitions extend to any entity that becomes a majority owned affiliate during the term. Under this wording an acquisition is generally inside scope, and its Oracle deployment can be certified at exit. Even here, the detail matters, because a threshold or a notice requirement can sit alongside the automatic language and quietly limit it.
Other definitions admit acquired entities only up to a size limit, expressed as a percentage of your revenue, headcount, or processor count at signing. An acquisition under the threshold is covered. One above it is outside scope for the excess, or excluded entirely. A large acquisition can therefore breach the cap and leave a significant block of deployment unlicensed while a smaller one would have been fine.
The tightest definitions cover only the entities listed at signing and admit nothing new without a formal amendment. Under this wording every acquisition is outside scope until you act, and deployment in the acquired entity is unlicensed from day one. This is the most dangerous pattern, because nothing happens automatically and the gap grows silently until certification forces it into view.
Check the customer definition against every deal, on the day it closes, not at exit. The merger and the ULA live in different parts of the organisation, and the gap between them is where the exposure hides. A deployment that is perfectly normal inside the acquired company becomes an unlicensed liability the moment it sits outside your customer definition. The clock is the ULA term, and the deadline is certification. Reconcile corporate change against the clause as it happens, while there is still time to bring deployment into scope or manage it out.
During the term, an out of scope acquisition causes little visible pain, because the unlimited right keeps the in scope estate comfortable and nobody is counting. Certification ends that comfort. You can only certify and convert deployment that sits inside the customer definition, so any Oracle running in an out of scope acquired entity is stranded. It cannot be added to your perpetual entitlement, and Oracle can treat it as unlicensed usage requiring remediation. The unlimited right you were paying for never reached it, and now the conversion cannot either.
Consider an anonymized healthcare group that acquired a regional provider eighteen months into its ULA term. The customer definition admitted acquired affiliates only up to a threshold, and the new provider was comfortably under it, so its deployment was in scope and certified cleanly at exit. A second anonymized healthcare group held a ULA with an exclusion by default definition, acquired a larger business, and let its Oracle deployment run for two years assuming the unlimited right covered it. At certification, that deployment was outside scope, could not be converted, and became a remediation conversation. The figures are indicative, but the contrast is the lesson: the same kind of acquisition produced a clean certification or a stranded liability depending only on the customer clause and whether anyone read it in time.
If a deal has closed or is in flight during your term, reconcile it against your customer definition now. Learn how to build the flexibility in before signing in negotiating M and A flexibility into the ULA, see how to assess ULA exposure inside a transaction in due diligence on ULA exposure in a deal, and ground your scope planning in our ULA exit strategy guide.
Book a ULA assessment and we will map your customer definition against every deal in the term, so acquired deployment is certified, not stranded.