When a certification count surfaces Oracle deployments outside your customer definition or territory, those instances do not count and can trigger a remediation demand. Found early, the problem is usually manageable. Found in the window, it becomes leverage Oracle holds over your exit.
A ULA does not grant unlimited deployment everywhere and for everyone. It grants it to named entities, in defined territories, for listed products. When a thorough count reaches into the corners of the estate, it sometimes finds Oracle running where the agreement does not reach. These out of scope deployments are one of the most common surprises at exit, and how you handle them decides whether they become a quiet fix or an expensive concession. This is a place where the answer depends heavily on your specific contract language.
A deployment falls outside scope for one of three reasons. It may sit in a legal entity that is not named in the customer definition, the clause that lists which parts of your organisation may deploy under the agreement. It may run in a territory the agreement excludes, where the territory clause limits geography. Or it may be a product that simply is not on the ULA product list, in which case it was never covered at all. Each of these means the same thing for certification: the deployment does not count toward your perpetual entitlement, and it may represent unlicensed use that Oracle can ask you to remediate.
These clauses feel abstract when the ULA is signed. They bite at exit, and they bite hardest after corporate change. A merger or acquisition during the term frequently introduces entities and territories the original customer definition never contemplated, and Oracle deployed inside those new parts of the business is exactly where out of scope problems appear.
Customer definition decides which entities may deploy. Territory decides where they may deploy. The product list decides what is covered at all. A deployment that breaks any one of the three is outside scope, will not count at certification, and may carry a remediation exposure. Read all three clauses together, because a deployment can satisfy one and fail another.
The single biggest variable is when you find the problem. Discovered with a year or more of runway, an out of scope deployment is often something you can address quietly. Discovered inside the certification window, the same deployment becomes a card Oracle can play, because you now need to resolve it under time pressure while also trying to certify. The lesson is the same one that runs through all ULA work: the value is in finding things early.
The realistic paths depend on the contract and the calendar, but they tend to fall into a small set. The table below is an indicative summary, not contract advice, and the right answer for any specific deployment turns on the exact clauses in your agreement.
| Situation | Possible move | Depends on |
|---|---|---|
| Deployment in an unnamed entity | Move workload into an in scope entity before the window, where permitted | Customer definition and time remaining |
| Deployment in an excluded territory | Repatriate to an in scope territory, or negotiate inclusion | Territory clause wording |
| Product not on the ULA list | License separately or decommission before exit | Whether the product is in use and needed |
| Discovered inside the window | Negotiate as part of the exit, with care not to inflate exposure | Overall negotiating position |
The disciplined approach starts with a complete count run early enough to surface scope issues while there is still time to act. When something out of scope appears, the first step is to read the relevant clauses precisely, because the difference between a deployment that can be moved in and one that cannot often comes down to a single sentence. The second step is to decide whether the deployment is genuinely needed. A redundant instance can simply be decommissioned, which removes the exposure entirely. A needed one calls for a deliberate choice between moving it into scope, licensing it separately, or folding it into the exit negotiation.
Throughout, the goal is to avoid handing Oracle a larger problem than exists. An out of scope deployment described carelessly can be made to look like a broad compliance failure. Described precisely, against the actual clauses, it is usually a contained issue with a clear resolution. Precision protects you.
Consider an indicative example. A manufacturer acquires a smaller business during the ULA term and stands up Oracle databases inside the acquired entity, which was never added to the customer definition. A count 14 months before expiry finds them. With time in hand, the workloads are consolidated onto servers inside a named entity, documented, and brought into the count, so they convert to entitlement rather than becoming a liability. Had the same deployments surfaced during the window, the realistic options would have narrowed and the cost of resolution would likely have risen. The figures and outcome are indicative and any real case depends on the contract.
Scope issues sit alongside the rest of the exit mechanics in our Oracle ULA certification guide. To understand who attests to the final count once scope is settled, read who signs the certification letter and why. And to keep the certification itself a controlled declaration, read certification without an Oracle audit.
A deployment falls outside scope when it sits in a legal entity not named in the customer definition, in a territory the agreement excludes, or on a product not listed in the ULA. Such deployments do not count toward certification and can trigger a remediation demand.
Sometimes. Depending on the contract language and timing, a deployment can be moved into an in scope entity or territory before the window closes, or addressed through negotiation. The right move depends entirely on the specific clauses and the calendar.
We run the count early, read your clauses precisely, and resolve out of scope deployments before they become exit leverage.