The cheapest place to solve a merger problem is the customer definition, before you sign. Win acquisition and divestiture flexibility at the table and corporate change never strands deployment at certification.
By Daniel Voss · Ex Oracle LMS · 4 June 2026
You negotiate merger flexibility into an Oracle ULA through the customer definition and the assignment language, before signing. Widen the definition to admit majority owned entities acquired during the term, remove or raise any size threshold that caps acquired deployment, set a clean notice mechanic that brings an acquisition into scope without a fresh negotiation, and secure terms that let a divested entity carry agreed entitlement out. These clauses cost little at signing and a great deal at certification, when the count is frozen and the leverage has moved to Oracle.
A ULA grants unlimited deployment of named Oracle products to a defined customer for a fixed term, and at the end you certify the deployed quantity into a perpetual entitlement. The customer definition decides who that unlimited right reaches. Everything inside the boundary can be deployed freely and certified at exit. Everything outside it cannot. When the organisation buys or sells businesses during the term, that boundary is where the money is won or lost, and the only time you set the boundary on favourable terms is before you sign.
The pattern we see is consistent. A ULA is negotiated hard on price and product scope, the customer definition is accepted close to Oracle's standard wording, and three years later an acquisition that everyone treated as a corporate success becomes a licensing liability because its Oracle deployment sits outside the definition. The remedy was a sentence in the contract that nobody priced. Flexibility negotiated up front is cheap insurance. Flexibility bought at certification, under time pressure, with the unlimited right already ending, is the most expensive way to acquire it.
You target four levers in the customer definition and the assignment terms. Each one closes a specific gap that corporate change would otherwise open, and each is far easier to win when Oracle wants your signature than when you want a clean certification.
Press for language that brings any entity which becomes a majority owned affiliate during the term inside the customer definition automatically. This is the single most valuable change, because it means an acquisition adds covered deployment rather than unlicensed deployment. Watch for riders that quietly limit the automatic language, such as a notice deadline or a carve out for entities above a stated size.
Many definitions admit acquired entities only up to a cap expressed as a percentage of your revenue, headcount, or processor count at signing. If a cap is unavoidable, negotiate it high enough to cover the acquisitions your strategy actually contemplates, and define the measurement date so a growing business does not breach the cap simply because the baseline is frozen at signing. A cap measured against your size at exit behaves very differently from one measured at signing.
Where automatic inclusion is not on offer, secure a simple, unilateral mechanic to admit an acquired entity by notice, with no consent right for Oracle and no separate fee. The danger in admission clauses is a hidden approval step that lets Oracle reopen commercial terms every time you grow. The mechanic should be administrative, not a negotiation in disguise.
Flexibility runs both ways. When you sell a business, the buyer often needs the Oracle entitlement that supports it. Negotiate assignment language that lets a divested entity carry an agreed, documented slice of entitlement out, or that gives it a defined transition window, so a divestiture does not leave the separated business unlicensed and does not force you to keep paying support for licenses you no longer use.
Negotiate the customer definition against your corporate strategy, not against a generic template. The right boundary is the one that matches the acquisitions and divestitures your organisation realistically expects across a three to five year term. Before you sign, the question to answer is simple: if we buy a business of the size we are likely to buy, does its Oracle deployment land inside this definition automatically, and if we sell one, can the entitlement leave cleanly. If the answer is no, that is the clause to fix now, while Oracle still wants the deal.
Consider an anonymized industrials group that expected to make two mid size acquisitions during a four year ULA. At signing it won automatic inclusion of majority owned affiliates with the size cap measured at the time of each acquisition rather than at signing. Both deals closed, both sets of Oracle deployment fell inside scope, and all of it certified cleanly at exit with no remediation. Now consider an anonymized services firm with a near identical estate that accepted a standard definition excluding new entities by default. It made one comparable acquisition, ran the acquired Oracle estate for two years, and at certification found that deployment stranded outside scope, where it could not be converted and instead became a remediation conversation. The figures are indicative, but the difference between a clean exit and a stranded liability came down to clauses negotiated, or not negotiated, years earlier. Whether any specific outcome applies depends entirely on the wording of your own customer definition and assignment terms.
If a ULA is being negotiated or renewed, treat the customer definition as a commercial term, not boilerplate, and shape it around your deal pipeline. Understand how the same clause behaves once a deal has already closed in the customer definition after a merger, learn how to surface this exposure inside a live transaction in due diligence on ULA exposure in a deal, and ground your scope and exit planning in our ULA exit strategy guide.
Book a ULA assessment and we will pressure test your customer definition against your acquisition and divestiture plans, so corporate change is covered, not stranded.