Oracle ULA Certification 90-Day Checklist: The Complete Action Plan

Why the 90-Day Window Matters

Oracle ULA certification is not an administrative formality. It is the moment that determines whether your organisation exits the ULA with a defensible perpetual licence portfolio — or faces compliance exposure, a forced renewal, and years of 8% annual support cost escalation on a suboptimal licence count.

The 90-day window before the certification date is the last realistic opportunity to: discover and document the full Oracle estate; deploy additional covered products that will increase the perpetual licence count at zero cost (the ULA support fee is fixed regardless of deployment volume); resolve virtualisation and cloud coverage ambiguities; and prepare the documentation that makes Oracle's verification process straightforward.

Organisations that begin certification preparation in the final two to three weeks typically miss deployments, under-count licences, face Oracle challenges they cannot rebut, and frequently end up renewing the ULA at Oracle's preferred price rather than exiting with their maximum perpetual entitlement. Starting at 90 days is not excessive caution — it is the minimum required for a thorough and commercially optimal outcome.

One financial point that cannot be overstated: every Oracle Database deployment that occurs before the certification date is a perpetual licence obtained at zero marginal cost. The ULA annual support fee does not change regardless of how many Oracle products are deployed during the term. Every deployment that does not happen before certification is a licence that must be purchased post-certification at current Oracle prices, with 8% annual support increases applied from the outset. The 90-day window is your final chance to maximise this value.

Days 90 to 61: Contract Review and Estate Discovery

Step 1: Obtain and Review the Full ULA Contract Package

The starting point is a complete review of the contractual framework governing your ULA. This means the Oracle Master Agreement, the relevant Ordering Document (the contract that defines your specific ULA terms), all amendments and addenda, and any subsequent agreements that modified the original terms. The Ordering Document is the critical instrument — it defines which products are covered, the certification mechanism, how deployments are counted, and whether cloud or virtualised environments are included.

Specific provisions to identify and review in detail: the list of covered programmes (which products and versions are within the ULA scope); the certification deadline and the procedure for submitting the declaration; any provisions addressing cloud, virtualisation, or third-party infrastructure; the definition of "Deployment" or "Installed" as used in the certification context; and the certification dispute resolution process.

Step 2: Engage an Independent Oracle Licensing Advisor

If you have not already done so, engage an independent Oracle licensing advisor before beginning the estate discovery. This is not a cost to be avoided — it is the investment that determines whether the 90-day process produces an optimal outcome or an expensive mistake. An independent advisor with direct LMS certification experience will interpret the contract provisions correctly, identify the discovery scope, and prepare the documentation standards that Oracle's verification team expects.

Critically, an independent advisor represents your interests — not Oracle's. Oracle's account team is not a neutral party in the certification process. Their commercial incentive is renewal, not your optimal perpetual licence count. Redress Compliance represents buyers exclusively and has no commercial relationship with Oracle.

Step 3: Run Full Estate Discovery

The estate discovery must identify every Oracle Database deployment within the ULA scope, including environments that internal teams may not be aware of. In enterprise environments, Oracle deployments accumulate organically — application teams deploy Oracle for new projects without notifying central IT, acquired subsidiaries run Oracle on isolated networks, and operational technology environments in manufacturing or utilities may run Oracle databases outside the corporate software asset management system.

Discovery methods to employ in parallel include Oracle's own LMS collection scripts (run in a controlled internal environment, not shared with Oracle until the full analysis is complete); SAM tool outputs; network scanning for Oracle listener processes; VMware vCenter or Hyper-V inventory exports; AWS, Azure, and GCP instance inventories; and direct queries to application teams and business units. Do not rely on any single discovery method alone.

Step 4: Identify Deployment Opportunities Still Within Reach

The discovery will typically reveal two categories of findings: deployments that exist and are within ULA scope (to be documented and certified), and deployment opportunities that have not yet been executed but remain within the ULA term. The second category is commercially critical. Every covered Oracle product deployment that can be completed and operational before the certification date adds to the perpetual licence count at zero cost.

Common under-deployed areas in Oracle estates include database options such as Advanced Security TDE, Partitioning, and Multitenant — features that may be licensed under the ULA but not deployed at scale; development and test environments running on shared infrastructure that could be moved to dedicated instances; disaster recovery databases that may be unconfigured or incomplete; and new application environments planned for post-certification deployment that could be brought forward.

Days 60 to 31: Licence Counting, Documentation, and Deployment Execution

Step 5: Apply Oracle Licence Counting Rules to the Full Estate

The licence count submitted at certification must be calculated using Oracle's licence metrics and counting rules — which are significantly more complex than most IT teams assume, particularly in virtualised and cloud environments.

For on-premises processor licensing: identify the physical host configurations for all servers running Oracle software; apply Oracle's Core Factor Table to convert physical cores to Oracle Processor Licences (the factor varies by processor type and architecture); for VMware environments without Oracle-approved hard partitioning, count all physical cores in the cluster, not just the VM allocation; for other virtualisation technologies, determine whether they qualify as Oracle-approved hard partitioning that permits sub-capacity counting.

For AWS and other cloud deployments (where covered by the ULA): apply the vCPU-to-Processor Licence ratio (typically two vCPUs per Processor Licence); check whether any averaging provisions in the contract affect the certification count; document the instance types, sizes, and deployment durations for all cloud Oracle instances.

The counting methodology must be consistent with Oracle's published licensing policies and defensible under challenge. An error in counting methodology — even an unintentional one — can result in Oracle challenging the certification and treating undercounted deployments as unlicensed post-certification.

Step 6: Execute Planned Deployment Maximisation

With the deployment opportunities identified in Step 4 and the certification date still 30 to 60 days away, this is the execution window for any additional deployments that will increase the certification count. Priority should be given to deployments that: are straightforward to implement within the timeframe; deliver genuine operational value so they can be justified to Oracle at certification; and produce a meaningful increase in the certified licence count given the deployment economics.

All new deployments during this phase must be documented with configuration records, deployment dates, hardware or instance specifications, and evidence of operational use. Oracle's verification team will scrutinise any deployments that appear to have been created specifically for certification purposes — the documentation must demonstrate that these are real, operational environments.

Step 7: Assemble Virtualisation and Cloud Documentation

Virtualisation and cloud configurations are the most common source of Oracle certification challenges. For every virtualised environment running Oracle within the ULA scope, assemble the following: the hypervisor platform and version; the physical host specifications (processor model, core count, core factor); VM configuration details (vCPU allocation, memory, storage); whether Oracle-approved hard partitioning is implemented and the evidence for it; and configuration records showing that Oracle software is confined to specified VMs or hosts.

For cloud deployments, assemble EC2 or equivalent instance records, deployment dates, the evidence of continuous operational use, and the contractual basis for including these instances in the certification count. If your ULA includes an averaging provision for cloud deployments, calculate the average deployment count over the relevant period and document the data underpinning that calculation.

Days 30 to 1: Certification Preparation and Submission

Step 8: Prepare the Certification Declaration

The certification declaration is the formal document submitted to Oracle's License Management Services team to initiate the certification process. It must include the complete deployment list in the format Oracle specifies — typically a spreadsheet listing each deployment with product name, version, metric (Processor or Named User Plus), quantity, physical host or instance details, and deployment location.

Every line item in the certification declaration must be supported by the documentation assembled in the preceding phases. The declaration itself should be reviewed by your Oracle licensing advisor before submission. A declaration submitted without adequate supporting documentation creates openings for Oracle to challenge individual deployments and reduce the certified count — or to use the challenge as leverage to reopen renewal discussions.

Step 9: Establish Your Oracle Communications Strategy

The 30 days before certification will typically involve increased contact from Oracle's account team. Renewal proposals, requests for meetings, compliance risk warnings, and audit-adjacent communications are common Oracle tactics in this window. Your communications strategy should be clear before any of this contact arrives.

All substantive Oracle communications should be routed through your legal and commercial advisory team. Responses to Oracle's renewal proposals should acknowledge receipt without conceding the commercial framing Oracle is trying to establish. Oracle's account team may imply that certification is complicated, risky, or likely to fail — these are sales tactics, not objective assessments. The certification is your contractual right. Whether you exercise it is a commercial decision, not a compliance risk.

Do not share any certification documentation with Oracle before the formal submission. Early sharing allows Oracle to identify challenges and prepare counter-arguments before your declaration is formally on record. Submit the complete, documented certification declaration on the contractually specified date — not before.

Step 10: Submit the Certification and Manage Oracle's Verification

Submit the certification declaration to Oracle LMS on the contractual date, via the specified submission mechanism. Retain confirmation of submission with a timestamp. Oracle's standard verification window is 30 days, during which they may request additional information about specific deployments.

Respond to Oracle's verification requests within the specified timeframes, providing only the information specifically requested and ensuring that all responses are consistent with the certification declaration and supporting documentation. If Oracle disputes any deployment category, the formal dispute resolution process in the contract is the appropriate mechanism — not ad hoc negotiation with the account team.

The certified licence count, once accepted by Oracle, represents your perpetual entitlement. Oracle support will be payable on that count at the agreed annual rate, increasing at 8% per year from the certification date. Ensure the support contract terms are documented and that future support renewals are managed against the certified count — not against Oracle's attempt to expand the support base in subsequent years.

Common Certification Mistakes to Avoid

Based on more than 60 ULA certification engagements, the following mistakes consistently cost organisations the most value:

• Starting too late: Beginning the certification process within 30 days of the deadline typically means missing deployments, rushing documentation, and accepting an avoidable outcome. Start at 90 days minimum.
• Relying on internal IT counts without independent verification: Internal Oracle estate inventories are frequently incomplete, particularly for acquired entities, OT environments, and cloud deployments. Independent discovery is essential.
• Running Oracle's LMS scripts and sharing outputs before internal analysis: Raw LMS script outputs frequently overcount due to virtualisation rules and management pack detection. Analyse all outputs internally before sharing anything with Oracle.
• Not deploying covered products before certification: Every Oracle Database deployment that could have been executed before the certification date but was not represents a perpetual licence that must now be purchased at current Oracle prices.
• Negotiating with Oracle's account team without independent advisory: Oracle's account team is incentivised to maximise renewal revenue. Independent advisory creates the commercial balance required for a rational outcome.
• Confusing Oracle's commercial structures: Oracle does not offer Enterprise Agreements. The relevant structures are the ULA, PULA (Perpetual ULA), Oracle Cloud Services (OCS), and standard Customer Support Identifier (CSI) contracts. Understanding which applies to your situation is fundamental to the certification strategy.