A ULA grants unlimited deployment only to the legal entities named in the customer definition. Deployment outside that boundary does not count at certification, and after corporate change the entity list is where compliance gaps quietly form. Reconcile it against reality before you certify.
By the Meridian advisory team · Ex Oracle licensing analysts · Updated June 2026
Only the legal entities covered by the customer definition in your agreement. A ULA does not grant unlimited deployment to a brand, a group, or everyone who shares your logo. It grants it to a named customer, and the contract defines exactly who that customer is. Sometimes the definition is a single legal entity. More often it extends to affiliates and subsidiaries, but on terms: a stated entity list, or an ownership threshold such as majority control, that decides which related companies are in scope. The crucial point is that the boundary is legal, not organisational. Two divisions that feel like one company to staff may sit in different legal entities, and only those captured by the customer definition hold the unlimited right. Anyone outside it is, for licensing purposes, a separate party who happens to be related to you.
The customer definition and entity list decide whose deployments count. Read the definition precisely, map your real Oracle footprint to the legal entities running it, and reconcile the two before certification. Deployments by entities outside the definition do not become entitlement at exit; they surface as compliance gaps. This is contract specific language that bites hardest after acquisitions, divestitures, and restructurings, so it must be managed against the ULA clock.
No. Certification converts the deployments of in scope entities into a perpetual entitlement. A deployment by an entity that falls outside the customer definition is not licensed by the ULA and does not count toward the certified number. This asymmetry is where buyers are caught. During the term, unlimited deployment feels boundless, and teams stand up Oracle wherever the business needs it, often without checking which legal entity owns the server. At certification the boundary reappears. Deployments inside the definition become owned licenses; deployments outside it become a question to answer. What felt like covered usage turns out to be unlicensed usage by a related but out of scope party, and at exit that is a remediation discussion, not entitlement. The unlimited right was always bounded by the entity list; certification is simply the moment the boundary is enforced.
The entity list rarely causes trouble while everyone assumes coverage is total. It causes trouble because deployment decisions are made operationally and licensing scope is defined legally, and the two are managed by different people who rarely compare notes. An engineer provisioning a database for a sister company is solving a technical problem, not reading the customer definition. Multiply that across a term, and a meaningful share of the estate can end up running in entities the ULA never covered. None of it looks like a problem until exit forces the reconciliation, which is exactly why the reconciliation should happen well before exit.
Sharply, and in both directions. The customer definition was written for the corporate structure that existed when the ULA was signed, and structures move. An acquisition brings in a new legal entity that is usually not automatically covered, even though the business now thinks of it as part of the group. Its Oracle deployments may sit entirely outside the unlimited right unless the agreement is addressed. A divestiture does the reverse: a unit leaves the group but may keep running Oracle under an entity that is now out of scope, or it may need to carry entitlement with it that the ULA never contemplated. Internal restructuring can move workloads between legal entities without anyone realising a licensing boundary was crossed. In each case the ULA clock keeps running, and the gap between the definition on paper and the reality on the ground widens. Corporate change during the term is one of the most common sources of certification surprises, and it is manageable only if the entity list is treated as a live document rather than a signed and forgotten one.
| Event | Effect on the entity list | The disciplined response |
|---|---|---|
| Acquisition | New entity usually not in scope | Assess its estate against the definition early |
| Divestiture | Departing unit may fall out of scope | Plan entitlement and exit before separation |
| Internal restructure | Workloads cross entity boundaries | Track which legal entity runs each deployment |
| No change, but loose provisioning | Deployment drifts to related entities | Reconcile footprint to scope before certifying |
Consider a group, figures and facts indicative only, that acquired a mid sized company midway through its ULA term. The business integrated operations quickly, and Oracle workloads for the acquired unit grew under the assumption they were covered. At certification, the customer definition did not include the acquired entity, so those deployments did not count and instead raised a compliance question. Identifying the issue a year earlier would have allowed the entity to be brought into scope or its estate planned deliberately, rather than discovered at exit. The lesson is to read the definition the moment the structure changes.
The entity list is one of three scope clauses that bite at exit, alongside territory and the treatment of acquired estates. Read the acquired company's Oracle estate for how M&A specifically reshapes your count, and the scope sweep after corporate change for what happens when restructuring outpaces the contract. Our ULA exit strategy guide is the pillar that frames scope, territory, and timing together. When you want your entity list reconciled against your real footprint before certification, the next step is a confidential assessment.
Only the legal entities covered by the customer definition in the agreement. A ULA names a specific customer, often with an entity list or an ownership threshold that defines affiliates and subsidiaries in scope. Deployment by any entity not covered by that definition is not licensed under the ULA, even if it sits inside the same corporate group. The definition, not the brand, sets the boundary.
No. Certification converts deployments by in scope entities into perpetual entitlement. Deployment by an entity outside the customer definition does not count toward the certified number and is not covered by it. At exit, such deployments can surface as a compliance gap rather than as entitlement, which is why the entity list must be reconciled against where Oracle actually runs before you certify.
Sharply. Acquisitions, divestitures, and restructurings change which legal entities exist and which are in scope, often without anyone updating the ULA. A newly acquired company is usually not automatically covered, and a divested unit may fall out of scope while still running Oracle. Corporate change during the term needs to be managed against the customer definition and the ULA clock, not assumed to be absorbed.