A global Oracle estate spans data centers, cloud regions, and legal territories, and each adds both entitlement and risk to a certification. Counting it well means capturing every deployment while keeping each one inside the contract's scope. This is how to do both at once.
Inventory every site where the named products run, count processors with the correct core factor at each, and confirm each deployment sits inside the contract's customer definition and territory scope. A deployment outside the permitted scope does not add entitlement and can trigger remediation. For a global estate, scope and count are checked together, region by region, because counting a deployment you are not entitled to deploy there creates exposure rather than value.
Across a global estate, every data center is both an opportunity and a question. The opportunity is entitlement. The question is scope. Count the first only after you have answered the second.
A single site certification is a counting exercise. A global one adds two layers. The first is breadth, because deployments scatter across data centers, disaster recovery sites, and multiple cloud regions, and any one of them can be overlooked. The second is scope, because the contract limits which entities and territories may deploy the software at all. A deployment can be perfectly real and still not count, if it sits outside the customer definition or the permitted territory. Both layers have to be worked at the same time.
The core of most estates is owned and colocated data centers. Each needs its production, test, development, and disaster recovery instances inventoried, with processor counts and the right core factor for the hardware in place. Disaster recovery sites in particular are easy to miss precisely because they are designed to sit quietly until needed.
Cloud deployment spreads the estate further. The same workload can run in several cloud regions, and each instance has to be inventoried and tested against the contract. Because cloud counting is contract specific, the treatment can differ by provider and even by how a region is used.
Estates grown through acquisition often carry deployments in entities that were never part of the original ULA. These are where scope risk concentrates, so they are inventoried with particular care, recording not just the deployment but the legal entity that operates it.
Many ULAs restrict use to defined entities and to named territories. A deployment in a region outside that scope does not add to the certifiable count, and worse, it can surface as unlicensed use and trigger a remediation demand. This is most acute after mergers and acquisitions, when newly acquired entities or territories may fall outside the customer definition. Reading the customer definition and territory language before counting is not optional for a global estate. It decides which of your deployments are entitlement and which are exposure.
For a multi region cloud estate, cloud counting has to be checked carefully rather than assumed. Some contracts require a deployment in AWS or Azure to run 365 continuous days to count toward the certification baseline. Some exclude public cloud entirely. Many are silent on Google Cloud, and silence is not inclusion. Where a region's deployment will not count, the workload can be repatriated on premises or moved to OCI before exit so that it does, provided there is time for any continuous run clock to complete. Across many regions this becomes a planning exercise as much as a counting one.
A multinational ran Oracle databases across four owned data centers and three cloud regions, with a recently acquired subsidiary operating in a territory not named in the ULA. The owned sites and OCI region counted cleanly. One AWS region met a 365 day continuous run clause and counted; another did not and was repatriated in time to qualify. The acquired subsidiary's deployment fell outside the customer definition, so rather than count it and invite remediation, it was addressed separately. The certified count rose substantially while the scope exposure was contained. Figures are indicative and depend on the specific contract language.
Where virtualized estates span sites, Oracle's partitioning stance applies in each. Soft partitioning does not limit scope, so a VMware cluster at any site can be swept into the count. In a maximization context that supports a larger count where deployment genuinely runs on a large cluster, but it also means clusters have to be measured and documented consistently across every data center, not just the primary one.
A global count is only as strong as its weakest site. The evidence file should hold server lists, deployment dates, and methodology for every location to the same standard, including the cloud conditions met and the scope confirmation for each entity. Inconsistent evidence across sites is exactly what surfaces in the first two years after certification when audit risk is highest, so uniformity across the estate is part of the defense.
Customer definition, territory clauses, and cloud counting language vary widely, and across a global estate they interact. Two multinationals with similar footprints can certify very different numbers because their contracts scope differently. In ULA work the answer almost always depends on the specific wording, so a global count begins with a close reading of the agreement, entity by entity and territory by territory.
If your estate spans data centers, regions, and entities, count it against the contract before you certify. Start with the Oracle ULA certification guide, then read building the deployment inventory and Named User Plus counting at certification.
Inventory every site where the named products run, count processors with the correct core factor at each, and confirm each deployment sits inside the contract's customer definition and territory scope. A deployment outside the permitted scope does not add entitlement and can trigger remediation, so scope is checked alongside the count.
Yes. Many ULAs restrict use to defined entities and territories. Deployment in a region outside that scope does not count toward certification and can create exposure. Reading the customer definition and territory language is essential before counting a global estate.
Cloud counting is contract specific. Some contracts require a deployment in AWS or Azure to run 365 continuous days to count, some exclude public cloud, and many are silent on GCP. For a multi region estate this has to be checked region by region and provider by provider.
Book a confidential assessment and we will count your global estate against your contract, capturing entitlement while keeping scope exposure contained.