Telefónica Oracle ULA Aftermath: €40M in Support Savings with Strategic Shift to Third-Party Support

The ULA as a Launchpad, Not a Destination

Most large enterprises treat Oracle's Unlimited License Agreement as a procurement vehicle — a way to cap licensing costs during a period of rapid deployment. But the smartest organisations understand something Oracle would prefer you overlook: the ULA is most valuable not for what it permits during the term, but for the perpetual license bank it creates at exit.

Telefónica's Oracle ULA strategy illustrates this dynamic at enterprise scale. As one of the world's largest telecommunications groups, with operations across Europe and Latin America, Telefónica ran significant Oracle infrastructure: databases, middleware, applications, and the support and maintenance obligations that come with them. Like most global enterprises of its size, it had accumulated Oracle licensing commitments that carried annual support fees calculated at 22 percent of the original licence purchase price, rising by 8 percent every year under Oracle's standard pricing model.

The arithmetic of Oracle support compounding at 8 percent annually is unforgiving. An organisation paying €10 million per year in Oracle support today will pay approximately €21.6 million per year in support costs a decade from now — even if they add no new Oracle products. For a business of Telefónica's scale, the long-term support liability dwarfs the original software investment many times over.

What a ULA Actually Means for Support Fees

One of the most widely misunderstood mechanics of the Oracle ULA is its relationship to support costs. Oracle's support fees inside a ULA are fixed for the ULA term. The fee you agreed at signature is the fee you pay — regardless of how much additional Oracle software you deploy within the contracted product set.

This creates a structural opportunity that most organisations fail to exploit fully. If you can deploy additional Oracle products within the ULA scope at zero incremental licence cost, and those deployments generate zero incremental support cost during the ULA term, then every qualified deployment is essentially free. The business case for maximising deployment before the ULA certification date is not just logical — it is arithmetically compelling.

Consider the alternative: an organisation that certifies a ULA having deployed 2,000 processor licences of Oracle Database Enterprise Edition will receive 2,000 perpetual processor licences at exit. An organisation that invested 12 months in aggressive pre-certification deployment and certified at 4,500 processor licences walks away with 4,500 perpetual licences — but paid the same support fees during the ULA term. The licence bank is 2.25 times larger at no additional cost.

That licence bank then determines the support fee baseline at exit. If third-party support is priced at 50 percent of Oracle's rate, the organisation with 4,500 certified processor licences has a significantly higher support-fee baseline to reduce than the organisation that certified at 2,000. The absolute savings from moving to third-party support scale with the size of the certified licence estate.

Pre-Certification Deployment Maximisation: What It Looks Like in Practice

Maximising Oracle deployment before a ULA certification date is not a passive activity. It requires a structured programme running 12 to 18 months before the ULA end date, covering every Oracle product included in the ULA scope.

Audit the ULA Scope Precisely

The first step is to read the ULA contract with forensic precision. The unlimited deployment rights apply only to the specific Oracle products listed in the ULA — not to the entire Oracle product catalogue. Many organisations have ULAs covering Oracle Database Enterprise Edition and selected options, but incorrectly assume that Oracle Fusion Middleware, WebLogic, or Oracle Analytics are also covered. Deploying non-ULA products before certification and including them in the count is an audit risk, not a benefit.

A precise ULA scope inventory is the prerequisite for any deployment maximisation programme. This means correlating every product in the ULA contract against Oracle's official product list, confirming version eligibility, and establishing a clear boundary between ULA-covered and non-ULA Oracle products.

Identify Eligible Deployment Opportunities

With the ULA scope confirmed, the deployment programme identifies every workload across the organisation that could legitimately run on a ULA-covered Oracle product. This typically spans several categories: development and test environments that were previously running reduced or non-Oracle configurations; disaster recovery environments that were under-licensed or not counted; internal applications that had been running on alternative databases for cost reasons; and new development projects that can be directed toward Oracle platforms within the ULA term.

The goal is to create a deployment pipeline that converts organisational demand for computing capacity into certified Oracle licences. Every qualifying deployment that occurs before the certification date increases the perpetual licence bank Oracle must acknowledge at exit.

Establish a Deployment Counting Methodology

Oracle's certification process requires the customer to provide a written attestation — typically signed at C-level — stating the quantities of each ULA product in use as of the certification date. The methodology used to count deployment instances must be defensible. Oracle will scrutinise the count, and any ambiguity around installation versus active use, virtual machine deployment, or containerised environments creates negotiation risk.

Organisations preparing for ULA certification should establish their counting methodology 12 months before the certification date, document it clearly, and ensure that all deployment data is captured through a consistent, auditable process. This counting methodology becomes the foundation of the certification attestation Oracle signs at exit.

The Post-ULA Decision: Why Third-Party Support Changes the Economics

Once an Oracle ULA has been certified and the organisation holds perpetual licences for the deployed product set, a strategic decision point arrives that Oracle's account team will work hard to steer in one direction: renew Oracle's Premier Support and stay in the Oracle ecosystem.

But the ULA exit is precisely the moment when third-party support becomes most advantageous. Here is why.

The 8 Percent Compounding Problem

Oracle Premier Support is priced at 22 percent of the net licence investment, with an 8 percent annual escalation clause embedded in most Oracle support contracts. That 8 percent annual increase means an organisation paying €5 million per year in Oracle support today will pay €10.8 million per year in support costs within a decade. Compounded over a 10-year period, the cumulative support spend on a static licence estate approaches €75 million from an initial €5 million baseline.

Third-party support providers, including Rimini Street and Spinnaker Support, typically charge 50 percent of Oracle's annual support fee at the time of transition, with flat or minimal annual increases thereafter. The divergence between Oracle Premier Support costs and third-party support costs widens materially with every passing year.

The Telefónica Case: How €40M in Savings Accumulates

Telefónica's €40 million support savings figure reflects the cumulative differential between Oracle Premier Support costs and third-party support costs over the post-ULA support lifecycle. This type of savings does not materialise in a single year — it compounds across multiple years as Oracle's 8 percent annual escalation accelerates away from the flat or gently rising third-party support fee.

For a telecommunications group of Telefónica's scale, with Oracle deployments spanning multiple national subsidiaries, database environments supporting critical infrastructure, and Oracle applications underpinning operational systems, the annual Oracle support bill is measured in tens of millions of euros. A 50 percent reduction applied to that baseline, compounding over a multi-year horizon, produces savings in the range of hundreds of millions when considered across the full enterprise. The €40 million figure represents a meaningful but illustrative slice of the total long-term support saving available to an organisation of that scale.

What Third-Party Support Actually Covers

Third-party support for Oracle products provides technical support for the installed version of Oracle software — resolving bugs, configuration issues, performance problems, and interoperability questions — without requiring the customer to upgrade to new Oracle versions. Support is typically delivered by experienced Oracle veterans who provide named engineer access, faster response times than Oracle's own Premier Support, and coverage for heavily customised environments that Oracle itself often struggles to support effectively.

Third-party support does not include new Oracle product features, regulatory updates delivered as new product versions, or access to Oracle's online support knowledge base. For organisations that are not upgrading Oracle products and that have stable, mature Oracle environments — which characterises the vast majority of post-ULA licensees — these limitations are operationally immaterial.

The Five Post-ULA Third-Party Support Decision Criteria

Not every organisation should move to third-party support after a ULA exit. The decision framework rests on five practical criteria that reflect the organisation's Oracle roadmap, application architecture, and risk tolerance.

1. Version Stability

If the organisation is running Oracle Database 19c, Oracle WebLogic 12c, or Oracle EBS 12.2 and has no near-term plans to upgrade to newer versions, third-party support is a rational choice. The organisation is paying Oracle's annual 22 percent support fee for access to patches and updates it is not deploying. Third-party support delivers the technical support coverage it actually needs at half the cost.

2. Customisation Depth

Heavily customised Oracle EBS, PeopleSoft, or JD Edwards environments are poor candidates for Oracle-driven upgrade cycles. Oracle's Premier Support for these products increasingly pushes customers toward Fusion Cloud, which requires complete re-implementation. Third-party support providers specialise in supporting customised on-premises Oracle applications with no pressure to migrate — making them a natural fit for organisations with deep legacy Oracle customisations.

3. Migration Timeline

Organisations that have committed to migrating off Oracle within three to five years benefit from third-party support as a bridge strategy. Instead of paying Oracle's escalating support fees while preparing for migration, they pay third-party support rates and redirect the savings into migration investment. The cumulative saving over a three to five year migration period can fund a significant proportion of the migration programme itself.

4. Regulatory Compliance Requirements

Certain regulated industries require current Oracle security patches as a compliance obligation. If the organisation's security framework mandates Oracle's official patch bundles, third-party support cannot fully substitute for Oracle Premier Support in those domains. A hybrid approach — Oracle Premier Support for regulated Oracle components, third-party support for non-regulated Oracle products — is feasible and reduces cost without compromising compliance posture.

5. Oracle Cloud Migration Dependency

Organisations planning to migrate to Oracle's own cloud services — OCI, Oracle Fusion Applications — may find it strategically preferable to maintain Oracle Premier Support to preserve co-termination rights, cloud credits, and migration assistance. For these organisations, third-party support would eliminate access to migration support that Oracle offers as an inducement to remain within the Premier Support relationship.

Lessons from the Telefónica Outcome

The Telefónica case crystallises several principles that apply to any large enterprise navigating the post-ULA landscape. These are not theoretical — they are the product of executing this exact strategy across dozens of enterprise clients across multiple sectors.

The ULA Term Is the Last Free Deployment Window

Once the ULA has been certified, every additional Oracle deployment requires either a new licence purchase or a new ULA. The deployment maximisation window closes permanently at certification. Organisations that under-deploy their ULA before certification leave perpetual licence value on the table that they cannot recover.

Certification Timing Is a Negotiation Lever

The ULA certification date is not simply an administrative deadline — it is a negotiation moment. Oracle wants to renew the ULA at the certification meeting. The customer's leverage peaks at this point: Oracle knows the customer holds a large perpetual licence bank and is about to make an independent support decision. Using the certification moment to negotiate favourable terms — whether for new Oracle products, cloud services, or support discounts — is a legitimate and effective strategy.

Oracle's Q4 Window Creates Commercial Opportunity

Oracle's fiscal year ends on 31 May. The Q4 window from March through May is the period when Oracle sales teams are most motivated to close deals and offer meaningful commercial concessions. Post-ULA negotiations that fall within the Q4 window — or are timed to conclude during Q4 — routinely achieve better outcomes than those concluded in other quarters. This applies equally to new licence purchases, support renegotiations, and cloud migration discussions.

Third-Party Support Is Not One-Size-Fits-All

Rimini Street and Spinnaker Support are the two largest independent Oracle support providers. Both offer materially similar core propositions — 50 percent cost reduction, guaranteed support for existing software versions, and personalised service. The selection between them depends on the specific Oracle products in scope, the organisation's support response requirements, and the contractual flexibility each provider offers. Due diligence across multiple providers, conducted independently of Oracle's account team, is the minimum standard for a post-ULA support decision.

Practical Steps for Organisations Approaching ULA Certification

If your organisation has a ULA expiring within the next 18 months, the actions that maximise post-ULA savings begin now.

• Audit the ULA scope immediately. Confirm exactly which Oracle products are covered, in which versions, and for which deployment types. Ambiguity at this stage creates risk at certification.
• Run a deployment gap analysis. Identify all workloads within the organisation that could legitimately deploy ULA-covered products before the certification date. Quantify the licence value of each gap deployment.
• Build a certification counting methodology. Establish the technical process for enumerating deployed instances, confirm it is consistent with Oracle's measurement approach, and document it as an auditable record.
• Commission an independent third-party support assessment. Before the certification meeting, produce an independent analysis of third-party support costs, coverage, and provider quality across two or three shortlisted providers. This analysis becomes the anchor for post-certification support negotiations.
• Do not attend the certification meeting unprepared for Oracle's renewal pitch. Oracle will arrive at the certification meeting with a ULA renewal proposal. Having an independent cost analysis, a third-party support comparison, and a clear view of your Oracle roadmap is the minimum preparation required to negotiate from a position of strength.