Oracle's ULA certification process is deceptively simple on the surface — you count your deployments, submit a Compliance Declaration, and Oracle converts that count into perpetual licences. In practice, the process is a high-stakes negotiation where Oracle's team systematically challenges your count, disputes your methodology, and attempts to reduce the perpetual entitlement you certify. Enterprise teams approaching certification without independent support routinely certify lower counts than their deployment activity justifies. This guide explains exactly what happens at each step — and how to protect your position.
During an Oracle ULA, the enterprise has unlimited deployment rights for the specified products. There is no licence counting, no compliance review, and no exposure to LMS audit claims for those covered products while the ULA is active. The ULA functions as a compliance safe harbour — and Oracle's LMS team knows better than to audit covered products during the term.
At ULA expiry, everything changes. The unlimited rights cease. From the certification date onward, the enterprise must hold valid perpetual licences for every deployed instance of the covered products. The quantity of those perpetual licences is determined by the Compliance Declaration the enterprise submits at certification — and the count you certify becomes your permanent, irrevocable entitlement.
This transition is Oracle's primary commercial recapture mechanism. The account team that was relatively quiet during the ULA term reappears at certification with detailed questions about your deployment methodology, evidence standards, and infrastructure. Oracle has every commercial incentive to certify you at a low count — the lower your certified processor count, the lower your perpetual entitlement, the more likely you are to need additional licences in the future, and the more leverage Oracle retains.
The certification process typically runs over four to eight weeks from the date you notify Oracle of your intent to certify. Enterprises that are unprepared find themselves submitting declarations under time pressure, with inadequate evidence, accepting Oracle challenges that reduce their count rather than fighting them.
Enterprise sends formal written notification to the Oracle account team or LMS/GLAS contact that it intends to certify the ULA. Most ULA agreements require this notification 30–60 days before the intended certification date. Notifying early gives you more time to prepare your evidence package and manage Oracle's challenge process. Do not notify Oracle until you have completed your internal audit and have a defensible preliminary count.
Oracle assigns an LMS or GLAS team to manage the certification. In most enterprise certifications, Oracle's team is led by a License Management Services consultant who has specific experience in ULA certification reviews. This team's objective is to validate — and where possible reduce — your declared count. They will request evidence, challenge methodology, and scrutinise every deployment claim.
Enterprise runs a complete internal software discovery using Oracle-approved tools (typically USMM or equivalent) or a credible third-party discovery. The discovery must cover every server, virtual machine, or cloud instance that could be running covered Oracle products. This is your opportunity to capture every deployment that contributes to your certification count.
Apply the Oracle Core Factor Table to each server running covered Oracle products. For each host: identify the processor model, look up the Core Factor (between 0.25 and 1.0 depending on chip architecture), multiply by the physical core count, and round up to the nearest whole number. The sum of all host calculations is your preliminary Processor licence count.
For each server contributing to your count, compile: the server hardware specification (manufacturer model number, processor model, socket count, core count per socket), the Oracle Core Factor Table reference, the calculated licence count, Oracle software installed and edition, installation date, and evidence of active deployment (support record, USMM scan output, or Oracle licence order history). This evidence package is what you submit alongside the Compliance Declaration.
The Compliance Declaration is the formal document in which you certify your Oracle product deployment count to Oracle. It is legally binding. Once Oracle countersigns, the declared count becomes your perpetual entitlement. Most declarations include a statement confirming that the count represents all deployments of covered products within covered entities on the certification date. Never submit the declaration without independent review.
Oracle's certification team reviews your declaration and evidence package, typically within two to four weeks. Expect written questions about specific deployments, requests for additional evidence on servers where the documentation is incomplete, and potentially formal challenges to deployments Oracle claims are outside ULA scope. This is the negotiation phase. You may need to defend specific deployment decisions and methodology choices.
Once Oracle accepts the Compliance Declaration (with or without adjustments), Oracle issues a new Order Form or equivalent document confirming the perpetual licence entitlement. This document becomes your Oracle licence record going forward. Annual support invoices will be calculated as 22% of the net licence value of this perpetual count.
Our Oracle ULA Advisory team guides enterprise clients through every step of ULA certification — building the evidence package, managing Oracle's challenge process, and ensuring your Compliance Declaration reflects the maximum defensible count. 40+ ULAs certified. Zero failures.
Oracle's standard Compliance Declaration form requires the enterprise to certify the following: the name of each covered Oracle product, the deployment metric (almost always Processor), the total deployed count for each product across all covered entities, a statement that the count is accurate as of the certification date, and an authorised signature from a senior officer of the enterprise.
The declaration must cover all covered entities listed in the ULA Order Form. If you have subsidiaries that were added to the ULA through contract amendments, those entities must be included. If you have subsidiaries that are not listed, any Oracle deployments within those entities are not covered by the ULA — and you must ensure those deployments are separately licenced.
Oracle increasingly requests a breakdown of the certified count by legal entity, by site, and by infrastructure type (physical, virtualised, cloud). This granularity allows Oracle's team to challenge specific sub-components of your count rather than the aggregate. Prepare your evidence package at this level of detail — a single aggregate count with no breakdown is a target, not a defence.
Critical: The Compliance Declaration is not a starting position in a negotiation — it is the enterprise's formal legal statement of its Oracle deployment. Submitting a declaration you cannot defend creates exposure; submitting a declaration that understates deployments gives Oracle an audit claim post-certification. The declaration must reflect the highest count you can genuinely defend with contemporaneous evidence.
Oracle's certification team uses a structured challenge methodology that targets four areas: infrastructure eligibility, option coverage, entity coverage, and evidence quality. Understanding the challenge approach allows you to pre-empt it in your evidence package.
Infrastructure eligibility challenges are the most common. Oracle claims that specific deployments — typically those on VMware virtual machines, certain cloud environments, or servers owned by non-standard entities — fall outside the ULA scope. Their argument is usually that the ULA terms do not explicitly authorise those infrastructure types and therefore the deployment is not certifiable. Counter-argument: review the ULA Order Form and Master Agreement for any language that limits permitted infrastructure, and build a clear legal argument that the deployment falls within the agreed scope.
Option coverage challenges arise when Oracle claims that a specific Oracle Database option — RAC, Partitioning, Advanced Security — was not included in the ULA coverage, and therefore the processors running that option cannot be included in the certification count for that option. Review your Order Form precisely: ULAs often list options by product code, and a missing product code is grounds for an Oracle challenge even if the option was discussed in the commercial negotiation.
Entity coverage challenges target deployments in subsidiaries or affiliates that Oracle claims are not listed in the covered entity schedule. If you acquired a company after ULA signing and added it to the covered entities through an amendment, ensure the amendment is explicit and on file. Oracle will not accept verbal assurances or email confirmations — the legal documents control.
Evidence quality challenges arise when Oracle disputes specific deployment counts because your supporting documentation is inadequate. A server listed in your declaration but without a corresponding hardware specification and Oracle installation record is an easy target. Oracle's standard response is to exclude that server from the certified count pending additional evidence — and if you cannot provide it, the exclusion stands.
See also our guide on Oracle Audit Defence Playbook for the challenge-response framework that applies equally to ULA certification disputes.
The Oracle Core Factor Table is the foundation of ULA certification counting for Oracle Database and most other products licensed on a Processor metric. The table assigns each processor model a Core Factor between 0.25 (typically lower-power processors) and 1.0 (Intel Xeon, AMD EPYC, and most enterprise server chips). The formula is: Physical Core Count × Core Factor = Processor Licences required, rounded up to the nearest whole number per host.
For physical servers, this calculation is straightforward. The complications arise in virtualised and multi-socket environments. For a dual-socket server with Intel Xeon processors (1.0 Core Factor) and 24 cores per socket, the licence count is 48 Processor licences. For a single-socket AMD EPYC server with 64 cores at 0.5 Core Factor, the count is 32 Processor licences. The Core Factor can significantly affect the total certification count — and enterprises that have not verified their Core Factor assignments against the current Oracle table frequently discover errors in their preliminary counts.
The Oracle Core Factor Table is version-controlled. Oracle updates it periodically to reflect new processor releases. The version applicable to your ULA certification is generally the version current at the certification date — but if Oracle has updated the table to increase Core Factors for processors you deployed early in the ULA term, you may be able to argue for the table version applicable at the time of deployment. This is a technical area where independent advisory support can identify significant licence count differences.
For Named User Plus metric ULAs (less common but used in some application scenarios), the count is based on the number of individuals authorised to use the product, with a minimum of 25 NUP per Processor licence. The complexity of NUP counting makes it an even richer target for Oracle challenge at certification.
Oracle's approach to virtualised environments at ULA certification mirrors its approach in LMS audits. Oracle's standard position — which it has maintained consistently for over a decade — is that VMware virtualisation does not constitute Oracle-approved hard partitioning and therefore a Processor licence is required for every physical core in the VMware cluster running Oracle products, not just the cores assigned to the specific VM.
For ULA certification, this creates a sharp dilemma. If your ULA deployments are running in a VMware environment and Oracle successfully argues that the entire VMware cluster must be licensed, your certified count could be dramatically higher than the core count assigned to your Oracle VMs — but that higher count becomes your perpetual liability, not just a certification benefit. Alternatively, if Oracle argues those deployments are outside ULA scope, your certified count is reduced.
The safe approach is to use Oracle Approved Partitioning methods — Oracle VM, LDOMs, Solaris Zones — for any deployments where you want to limit the licence scope to specific virtual machines. If you have VMware deployments within your ULA, work with an independent advisor before certification to determine the most defensible count and scope approach.
For OCI (Oracle Cloud Infrastructure) deployments within the ULA, licensing rules differ: OCI uses an OCPU-based count for many services and has its own licence equivalency rules. AWS and Azure are generally not covered by standard ULAs unless specifically negotiated. Verify cloud infrastructure rules with independent legal and technical analysis before your Compliance Declaration.
Our detailed guide on Oracle Software Compliance in Virtualised Environments covers the full technical landscape. For cloud-specific rules, see our Oracle Cloud Advisory service.
Complete guide to ULA structuring, deployment maximisation, certification methodology, and evidence standards. Used by enterprise licensing teams worldwide — download free.
Once ULA certification completes, the enterprise exits the unlimited rights model and enters standard perpetual licence compliance. Your certified count is your entitlement; deploying beyond that count without additional licence purchase is a compliance exposure identical to any other Oracle licence shortfall.
Oracle will typically issue new Order Forms or CSI (Customer Support Identifier) records reflecting the certified perpetual licence quantities. Your annual support invoices will be recalculated based on 22% of the net licence value assigned to those perpetual positions. For large certifications — particularly Oracle Database EE with multiple options — this annual support figure can be substantial. See our guide on Oracle Support Cost Reduction for strategies to challenge and reduce the post-certification support burden.
The post-certification period is also Oracle's primary window for re-engagement. Having just certified your Oracle position, you are now, in Oracle's commercial view, at risk of growing beyond your entitlement as your IT environment evolves. Expect Oracle's account team to become active again quickly, offering additional licences, cloud migrations, and new contract structures. Approach all post-certification Oracle engagement with the same caution you applied during the certification process.
If your certified count creates an immediate compliance gap — meaning you already have deployments that exceed your newly certified position — you need to address that gap urgently. The Oracle Compliance Review service provides the forensic assessment of your post-certification position and identifies the fastest path to a defensible compliance position.
Oracle's certification team is experienced, commercially motivated, and well-resourced. They have certified hundreds of ULAs and know every challenge technique in the playbook. Enterprise IT and procurement teams, encountering the certification process for the first time, are structurally disadvantaged from the moment Oracle assigns its LMS or GLAS lead.
Independent Oracle licensing advisors — former Oracle insiders who have been inside the LMS process from the other side — provide the knowledge parity that certification requires. We know the challenge methodology because we used to apply it. We know the evidence standards because we wrote the requests for evidence. We know which Oracle assertions are legally defensible and which are negotiating positions designed to reduce your count without contractual justification.
On a typical mid-sized enterprise ULA with 250–400 certifiable processors, the difference between an unmanaged certification and an expert-supported one can be 50–150 processors. At Oracle Database EE list prices, that represents $4M–$12M in perpetual licence value. Our advisory fee on a certification engagement is a fraction of that variance.
Our Oracle ULA Advisory service has guided 40+ ULA certifications to completion — zero failures, and a consistent track record of certifying the highest defensible count against Oracle challenge. Contact us for a confidential consultation before your certification process begins.
For more Oracle ULA intelligence, see the Oracle ULA Guide, the ULA Maximisation Strategy article, and the ULA Certification Case Study.
The complete enterprise guide to ULA lifecycle management — from structuring and deployment through certification and post-ULA compliance. Download free.
Download Free White Paper →Independent Oracle licensing intelligence for enterprise buyers. ULA tactics, audit alerts, contract benchmarks — delivered weekly.
Free Research
Download our Oracle OCI Licensing Guide — expert analysis from former Oracle insiders, 100% buyer-side.
Download the OCI Licensing Guide →