The deployment inventory is the foundation of every certification. What is in it can be certified, and what is missing is lost. This is what a complete inventory captures, how each instance is evidenced, and why building it well is the single highest leverage task before an Oracle ULA exit.
Every instance of the named products deployed within the term: production, test, development, and disaster recovery, on premises, in OCI, and in public cloud where the contract counts it. Each entry records the host, the processors and core factor, the licensing metric, the deployment date, and the evidence source. The inventory is the master list from which the certified count is built, so it has to be complete and provable.
What is not in the inventory cannot be certified. The inventory is not paperwork. It is the difference between the count you are owed and the count you can prove.
Certified counts often land well above the first estimate, sometimes 1.5 to 2.5 times higher, once cloud, disaster recovery, and non production deployments are handled properly. That uplift does not come from clever interpretation. It comes from a complete inventory that surfaces deployments routinely overlooked. A thin inventory certifies a thin number, no matter how strong the rest of the engagement is.
Test, development, and disaster recovery instances deployed within the term count, yet they are the environments most often left out because they sit outside the main production estate. A complete inventory reaches into every environment where the named products run, because each one is potential permanent entitlement.
For each host the inventory records the processor count, the applicable core factor, and the metric the product is licensed under, whether processor or Named User Plus. Getting the core factor right matters, because it translates physical cores into the licensable processor number that the count is built on.
Only deployments live within the ULA term count. The inventory records when each instance was deployed, so the count rests on a clear timeline rather than a snapshot. This timeline is what defends the count if a deployment is later questioned.
Cloud instances need the detail that proves they meet the contract's conditions, for instance a 365 day continuous run where the agreement requires it. Virtualized estates need the configuration that shows how the VMware footprint was measured, because Oracle's partitioning stance treats soft partitioning as not limiting scope.
A healthcare provider's first internal estimate counted only its production database hosts. A full inventory added disaster recovery instances, a development cluster, and a set of virtualized hosts that had been deployed within the term, all evidenced with server lists and deployment dates. The certified count rose well above the initial figure, and because every addition was documented, the position held under later review. Figures are indicative and depend on the specific contract language.
Each entry in the inventory should be backed by evidence that stands on its own. That typically means server and configuration lists, output from inventory or discovery tooling, and records that show the instance was live within the term. Where cloud is counted, the evidence should demonstrate the contract conditions were met. The evidence file matters as much as the number, because audit risk rises in the first two years after certification and the file is the defense.
The recurring losses are predictable. Disaster recovery instances left uncounted. Non production environments treated as out of scope when they are not. Virtualized hosts measured loosely. Cloud deployments excluded because no one checked whether the contract would count them. Each gap is permanent entitlement forfeited, and each is avoidable with a disciplined inventory built early.
Which environments count, how cloud is treated, and how virtualization is read all come from the specific agreement. Two organisations with identical estates can build different inventories because their contracts differ. In ULA work the answer almost always depends on the specific wording, so the inventory is built against your own contract, not a generic template.
If certification is ahead, start the inventory early and build it to evidence standard. Begin with the Oracle ULA certification guide, then read Named User Plus counting at certification and counting across data centers and regions.
Every instance of the named products deployed within the term: production, test, development, and disaster recovery, on premises, in OCI, and in public cloud where the contract counts it. Each entry records the host, processors and core factor, the metric, the deployment date, and the evidence source.
Certified counts often land well higher than first expected because a complete inventory surfaces deployments routinely overlooked, such as disaster recovery, non production, and virtualized environments. What is not in the inventory cannot be certified, so completeness directly converts to permanent entitlement.
Server lists, configuration and tool output, and records showing the instance was live within the term. Where cloud is counted, evidence should show the contract conditions were met. The evidence file matters as much as the number, because it defends the count in any later audit.
Book a confidential assessment and we will build the deployment inventory and evidence file that turn your full estate into certified entitlement.