Client Profile
The client is a major integrated telecommunications operator headquartered in South-East Asia, providing mobile, fixed-line, broadband, and enterprise connectivity services to a subscriber base of over 40 million customers. The organisation employs approximately 12,000 staff and maintains a substantial technology estate built to support real-time billing, network operations management, customer relationship management, and financial systems across multiple countries of operation. Oracle software has been a core component of the client's enterprise stack since the late 1990s, with Oracle Database underpinning billing and CRM platforms, Oracle E-Business Suite supporting finance and HR, and Oracle Exadata infrastructure deployed for analytics and reporting workloads.
The client entered its Unlimited License Agreement three years prior to the engagement with Redress Compliance. The ULA covered Oracle Database Enterprise Edition, Oracle Real Application Clusters, Oracle Advanced Compression, and Oracle Partitioning. The ULA had served its original purpose — enabling the organisation to expand its Oracle footprint during a network transformation programme — and the organisation had no commercial rationale for a further unlimited term at Oracle's proposed renewal price of $9.6M per year in support obligations.
The Challenge
Oracle's certification process is not a neutral audit. Oracle's account team typically produces a pre-certification estimate of the organisation's deployable processor count using data drawn from the organisation's own environment via Oracle's licence management tools or from Oracle's network discovery tooling. These estimates frequently overstate the actual qualifying deployment count because they apply Oracle's standard processor counting rules in the most expansive interpretation possible, without accounting for technical restrictions, virtualisation configurations, or legitimate counting exceptions.
In this case, Oracle's pre-certification assessment identified 480 processor licences across the client's estate, based on a sweep of the organisation's VMware virtualisation environment. Oracle's standard position on VMware is that all physical cores in a VMware cluster must be counted as licensed for Oracle software if any virtual machine in that cluster runs Oracle software — a rule that Oracle applies aggressively and that can produce counts many times larger than the actual Oracle software deployment.
The client's internal team had not previously engaged with Oracle's virtualisation counting rules and had no independent basis to contest Oracle's 480-processor estimate. At Oracle's standard support rate, 480 processors implied an annual support obligation of approximately $9.6M — a figure the client's technology leadership regarded as unsustainable and commercially unjustifiable given the organisation's actual Oracle usage profile. The client engaged Redress Compliance nine months before the ULA expiry date to conduct an independent pre-certification audit.
The Approach
Redress Compliance's ULA certification advisory engaged on two parallel workstreams. The first was a technical deployment audit, conducted independently of Oracle's tooling, to establish the actual processor count for Oracle software running across the client's VMware estate. The second was a contractual and policy analysis to identify legitimate arguments for counting fewer processors than Oracle's default methodology would imply.
The technical audit reviewed the client's VMware configuration at the cluster level. Key findings included: first, that several VMware clusters contained no virtual machines running Oracle software and were incorrectly included in Oracle's sweep; second, that a number of Oracle Database installations were running on virtual machines that had been hard-partitioned using VMware's CPU affinity settings in a way that met Oracle's own technical requirements for reduced-scope counting; and third, that Oracle Exadata deployments within the estate were covered by separate capacity-based licences and should not have been counted as standard processor licence usage.
The contractual analysis identified three additional arguments that further reduced the legitimate certification count. Oracle's ULA agreement with the client included a product-specific schedule that limited the ULA scope to on-premises deployments at defined data centre locations. One significant Oracle Database deployment that Oracle's sweep had included was operating in a colocation facility not listed in the ULA schedule — a deployment that had been contracted under a separate direct purchase and should not have been counted in the ULA certification at all.
Working from these findings, Redress prepared a detailed technical certification letter with supporting evidence for each processor count reduction. The certification was submitted to Oracle with 240 processor licences — exactly half of Oracle's pre-certification estimate of 480 — with a full technical and contractual justification file. Oracle's GLAS team reviewed the submission, conducted follow-up questions, and accepted the certified count without proceeding to a formal challenge.
The Outcome
The difference between Oracle's 480-processor estimate and the certified 240-processor count represented $4.8M in annual support obligations that the client avoided locking in at the point of certification. At Oracle's 22% annual support rate, 240 fewer processors on a standard Oracle Database Enterprise Edition licence base eliminated $4.8M per year in support cost that would otherwise have compounded at Oracle's annual uplift rate for the foreseeable future.
Post-certification, the client's annual Oracle support obligation was structured around the correctly certified 240-processor count. The organisation transitioned to a direct support arrangement at a cost of $5.5M per year — $2.1M below Oracle's pre-certification projected level. The certified licence position also gave the organisation a clean, documented licence inventory that it subsequently used to negotiate a commercial discount on Oracle cloud services as part of a broader enterprise agreement, leveraging its defined perpetual position as a negotiating anchor.
Key Takeaways
- Oracle's pre-certification estimates are negotiating positions, not technical facts. Oracle's GLAS team produces pre-certification counts using the most expansive interpretation of Oracle's counting rules. An independent technical audit consistently produces materially lower — and contractually defensible — processor counts.
- VMware cluster counting is Oracle's largest source of overcounting. Oracle's position on VMware creates an inflated count when applied without technical scrutiny. Hard partitioning, cluster scope analysis, and the identification of non-Oracle clusters are all legitimate mechanisms that reduce the qualifying count.
- ULA scope matters at certification. Products and deployments not covered by the ULA product schedule should be excluded from the certification count, but they rarely are unless an expert reviews the contractual scope before submission.
- Certifying at the right count locks in value permanently. The savings from an accurate certification are not a one-time event. They compound at Oracle's annual support uplift rate and set the floor for all future commercial negotiations with Oracle.
- Independent pre-certification advisory should start nine months before expiry. The technical and contractual analysis required to challenge Oracle's count takes time. Engaging three months before expiry — as many organisations do — leaves insufficient time to build a complete and defensible certification position.
Oracle ULA expiring in the next 12 months?
Redress Compliance can independently audit your deployment count and build a defensible certification position before Oracle sets the terms.