Oracle Unlimited license agreement

Oracle ULA Certification

Oracle ULA Certification

Certification Process (Step-by-Step Guide)

Certifying a ULA means formally ending the unlimited period and converting your deployments into perpetual licenses. This process is critical; when done correctly, you secure the rights to continue using your deployed Oracle software indefinitely.

Done poorly, certification can leave you with compliance gaps or legal issues. Below is a step-by-step guide to ULA certification:

Review Your ULA Contract

Start by understanding your obligations and rights. Read the contract’s certification clause and any related provisions. This clause typically states that on the Certification Date (the day the ULA term ends), you must provide Oracle with a certification, signed by a C-level executive, stating the number of processors (or named users, if applicable) on which each Unlimited Program is installed and running, along with the locations (by country) of those processors.

Take note of special conditions (e.g., some ULAs might have an accelerated certification option or specific notice periods). Knowing exactly what you agreed to sets the foundation for compliance.

Mobilize a Project Team and Start Early

Treat the certification as a project. Six to 12 months before the ULA expires, assemble a team (licensing specialists, IT asset managers, relevant IT ops personnel) to begin preparations.

Starting early is vital; a common recommendation is to gather data at least six months before expiry. Early preparation gives time to address any discrepancies or shortfalls in license counting.

Inventory All Oracle Deployments

Compile a comprehensive inventory of all Oracle software deployments covered by the ULA. This means listing every installation of the ULA-covered products on every server (physical or virtual), including the number of processors each is using and the country of installation. If the ULA includes user-based licenses, gather the user counts.

Be thorough: include deployments in non-production environments if they count under your license metrics. Maintaining a proper deployment record throughout the ULA (as noted in Best Practices) pays off hugely here.

At certification, you don’t want to scramble to discover where Oracle products are installed. Ideally, you have been tracking this all along; now, it’s about consolidating and verifying the data.

Conduct an Internal License Audit

Before presenting anything to Oracle, perform an internal audit simulating what Oracle’s License Management Services (LMS) team would do.

Use Oracle’s measurement tools or third-party license auditing tools to scan your environment for Oracle software. The goal is to identify any deployment of Oracle products or options not covered by the ULA and verify the metrics for those covered.

Common issues to look for include:

  • Oracle database options or packs enabled that are not part of the ULA (e.g., Partitioning, Advanced Security, and tuning packs if they weren’t included) often get installed unknowingly and can trigger compliance issues.
  • Oracle programs installed in environments or by entities not covered (for example, a subsidiary acquired during the ULA term that wasn’t added to the agreement).
  • Use in cloud environments like AWS/Azure if your contract doesn’t permit it.
  • Any installations of entirely separate Oracle products that are outside the ULA.

By auditing internally, you can catch these compliance “landmines” and resolve them before Oracle’s team gets involved. If you do find non-compliant usage, you typically have two choices: remove/de-install it or prepare to license it separately.

Under a ULA, you cannot add it to the certification count if it’s not an included product, so it must be cleaned up to avoid problems.

Read about Oracle ULA Renewal Strategies.

Optimize and Maximize Deployment (if needed)

As you approach the end of the ULA, determine if you need to deploy additional instances of Oracle software to meet future needs.

One key advantage of a ULA is the ability to “sweat the license” – i.e., deploy as much as possible before it ends since those deployments turn into perpetual entitlements. Ensure that any remaining planned deployments are completed before the ULA expires so they can be counted.

For example, if a project requires 10 more Oracle databases next quarter and your ULA ends this year, it may be wise to spin them up now under the ULA umbrella.

This must be done in good faith (for real use, not fake deployments) – but you certainly want to maximize usage within the terms of the contract. Failing to deploy what you need by the end means you’ll end up with fewer perpetual licenses, potentially limiting you later (this is the “under-deployment” risk).

Many firms conduct a last-minute deployment push in the ULA’s final 1-2 months to capture any remaining needed capacity. Coordinate with business units to identify foreseeable growth and complete those installations under the ULA timeframe.

Engage Oracle (LMS) Carefully

Oracle’s LMS team typically contacts you about three months before ULA expiration to assist with the certification process. They will offer to help gather deployment data using Oracle’s LMS Collection Tool and populate a Global Deployment Report (GDR)—an Excel sheet summarizing all deployments.

While this might sound helpful, proceed with caution. It’s documented that Oracle’s scripts will collect data on all Oracle products in your environment, not just the ULA-covered ones, and “98% of technical measurements” done by Oracle LMS uncover some non-compliance issues outside the ULA.

To manage this:

  • You might do your measurement (as in step 4) and present Oracle with the results rather than letting them scan everything unchecked.
  • If you run Oracle’s tools, ensure you’ve removed non-ULA software first and are prepared to address any findings.
  • Consider having a third-party expert present to validate the findings.
  • Ultimately, you must provide Oracle with an official certification letter signed by a C-level executive with the numbers – but you are not obligated to allow a full-blown audit unless your contract specifies it. Many ULAs allow Oracle to verify your count, so some cooperation is necessary; just do so with your eyes open and after completing your data gathering.

Prepare the Certification Letter and Documentation

The core of ULA certification is a formal letter (often on company letterhead, signed by a CEO or CFO) to Oracle declaring your Certified Deployment numbers.

  • A statement that it is a certification under the ULA contract.
  • A list of each Unlimited Licensed Program and the number of processors (or named users) on which it is installed and running as of the ULA end date.
  • A breakdown by country (Oracle typically requires the count of processors per country). This ties to Oracle’s export regulations and supports alignment.
  • The date of certification (which should be the day the ULA term ends, unless an accelerated date was agreed).

Double-check these numbers with your inventory, and have a high-ranking executive ready to sign. Oracle requires C-level sign-off to ensure accuracy (and to underscore that overcounting intentionally would be a serious infraction, considered fraudulent).

Along with the letter, complete any Oracle-provided spreadsheet (GDR) with detailed data about each deployment (hostname, physical/virtual, processor counts, etc.), as Oracle’s auditors will review this for validation.

Ensure Accuracy and Compliance in Reporting

When finalizing your numbers, accuracy is paramount. Two failure modes to avoid:

  • Undercounting: If you certify fewer processors than you deploy, those extra deployments become unlicensed after the ULA ends—a direct non-compliance situation. Oracle could then demand additional license fees or legal remedies for those deployments.
  • Overcounting: If you claim more processors than you have in use, hoping to get “free” licenses, you are in breach of contract and could be accused of fraud. Oracle takes over-reporting very seriously and may investigate. If they find you inflated the numbers, the consequences could be severe (loss of all ULA benefits, legal action, etc.).

Because of these risks, triple-check the data. Have your internal audit team or a third party verify the counts, if possible. The executive signing the letter should be comfortable with the numbers being correct and defensible with data.

Submit Certification and Work with Oracle’s Verification

Submit the signed certification letter and your deployment details to Oracle on the certification date. Oracle will review the information. Often, there will be follow-up discussions or questions from Oracle’s LMS or account team.

Respond promptly with the documentation you prepared. If you’ve done your homework, this validation phase should go smoothly.

Post-Certification Actions

After successfully certifying:

  • Secure Documentation: Ensure you obtain formal documentation of your now-perpetual licenses from Oracle.
  • Update Internal Records: Adjust IT asset management records.
  • Assess Support Needs: Determine if you need all the support you’ve been paying for.
  • Learn and Improve: Conduct a retrospective on what went well and what challenges arose.

By following these steps, you can navigate ULA certification with confidence.

Do you want to know more about our Oracle ULA Optimization Service?

Please enable JavaScript in your browser to complete this form.
Author
  • Fredrik Filipsson has 20 years of experience in Oracle license management, including nine years working at Oracle and 11 years as a consultant, assisting major global clients with complex Oracle licensing issues. Before his work in Oracle licensing, he gained valuable expertise in IBM, SAP, and Salesforce licensing through his time at IBM. In addition, Fredrik has played a leading role in AI initiatives and is a successful entrepreneur, co-founding Redress Compliance and several other companies.

    View all posts