What counts as a deployment outside ULA scope?
A deployment outside ULA scope is any Oracle use that the unlimited license agreement does not cover, whether because the product is not on the named list, the legal entity is not a party, or the deployment sits in a territory the agreement excludes. A ULA grants unlimited deployment rights, but only for specific Oracle products, only for named entities, and often only within defined geographies and for a fixed term. Anything beyond those boundaries is governed by ordinary licensing, not by the ULA's unlimited grant.
This surprises buyers because the word unlimited reads as total coverage. In practice a ULA is a bounded box, and the boundaries are written into the agreement. A product the organisation started using after the ULA was signed but never added to the list is out of scope. A subsidiary acquired during the term that was never joined as a party is out of scope. Usage in a country the agreement does not name can be out of scope. Each is unlimited inside the box and unlicensed outside it.
Why do out of scope deployments matter at certification?
Out of scope deployments matter most at certification because a ULA lets you certify only the deployments that fall inside scope, so anything outside it cannot be counted and converts into an unlicensed liability when the term ends. At the end of a ULA the buyer declares the quantity of the named products deployed, and that declared number becomes the perpetual entitlement going forward. Deployments outside scope cannot be added to that count, because the agreement never covered them, so they drop out of the certification entirely.
The consequence is that out of scope use survives the ULA as raw exposure. The day after certification, those deployments are running Oracle with no entitlement behind them, and they are exactly what an audit is designed to find. Because ULA certification and the period just after it are common audit triggers, Oracle often looks closely at organisations leaving a ULA, knowing that scope gaps are frequent. The buyer who treats certification as a counting exercise without first checking scope walks straight into that finding.
| Boundary | Inside scope | Outside scope |
|---|---|---|
| Products | Named in the agreement | Any product not listed |
| Legal entities | Named parties | Unjoined subsidiaries |
| Territory | Defined geographies | Excluded regions |
| Term | Within the dates | Use after expiry |
How do out of scope deployments arise?
Out of scope deployments arise mostly through change the organisation did not map back to the agreement: new products adopted, businesses acquired, and workloads moved to new regions or to the cloud during the term. A team enables an Oracle option or installs a product that seemed natural to use but was never on the ULA list. An acquisition brings Oracle estate under the corporate umbrella without the legal work to bring it under the ULA. A migration places Oracle in a territory or environment the agreement does not reach. None of these feel like licensing decisions at the time, which is why they go unnoticed.
This is a contract dependent area, because the precise products, entities, and territories in scope are defined only in the signed agreement, and two ULAs are rarely identical. A change that is inside scope under one agreement is outside it under another. That is why the buyer cannot rely on general rules and has to read the actual document, then test each material deployment against its specific named boundaries, flagging anything uncertain as contract dependent for closer review.
What is the buyer move on ULA scope?
The buyer move is to map every Oracle deployment against the agreement's named products, entities, and territories early in the term, so that anything outside scope is corrected or relicensed deliberately rather than discovered in an audit. The map is a simple but disciplined exercise: list what the ULA covers, inventory what is actually deployed, and mark every item that does not match. The items that do not match are the exposure, and addressing them while the ULA is live and there is time to act is far cheaper than addressing them under a finding.
There are usually two routes for an out of scope deployment. Where the agreement allows, the buyer brings it inside scope, for example by joining an acquired entity as a party before certification. Where it cannot be brought in, the buyer either relicenses it on ordinary terms or removes it. Either way the decision is the buyer's to make on a timeline the buyer controls. Oracle's preliminary findings arrive inflated at list price, and an independent line by line review of findings typically cuts claims by 60 to 80 percent, but the strongest position is to have closed the scope gaps before the audit letter is ever written.
How do cloud migrations create out of scope use?
Cloud migrations create out of scope use when an Oracle workload moves to an environment or a counting basis the ULA never contemplated, so what was unlimited on premises becomes uncertain or uncovered in the cloud. Many ULAs were written before public cloud was central, and their scope language reflects on premises deployment. Moving the same product to a public cloud can raise questions the agreement does not answer cleanly, and some ULA terms restrict how cloud deployments count toward certification or whether they count at all. A migration that looks like a simple lift and shift can quietly change the licensing basis.
This is acutely contract dependent, because the answer turns on the specific cloud and certification language in the signed ULA, and two agreements can treat the same migration very differently. The buyer move is to test any planned cloud migration against the ULA scope and certification terms before it happens, not after, so that the deployment is either confirmed inside scope or handled deliberately. Reviewing the cloud terms early, and flagging anything ambiguous as contract dependent, prevents a migration from manufacturing the exact out of scope exposure that surfaces at certification or in a later audit.
The next step
This article is part of our ULA and Oracle Agreements cluster. Read the pillar, the Oracle license compliance guide, for the full picture, and these related reads: PULA basics for audit holders, and the clauses that decide audit outcomes.