EOFY Series Part III: Defining Oracle…

This is Part III of our six-part EOFY series on preparing for Oracle's fiscal year end — May 31.

In Part I we covered internal audit and data gathering. In Part II we walked through how to analyze your license usage and identify optimization opportunities. Part III picks up where those leave off — because knowing what you have and how you use it is only the beginning. The next step is defining what you actually want from a negotiation.

This is where most organizations fall short. They arrive at the table reactive rather than strategic, responding to Oracle's proposals instead of advancing their own position. If you don't define your goals before Oracle does, you're negotiating on their terms.

---

Why Understanding Oracle's Incentives Matters

Effective negotiation requires understanding what the other party is incentivized to do. Oracle's fiscal year ends May 31, and their sales teams have quotas to close. That creates leverage — but only for organizations who understand how to use it.

Several current Oracle priorities are worth understanding before entering any negotiation:

Cloud migration. Oracle is aggressively pushing Oracle Cloud Infrastructure (OCI). Cloud is a significant component of their quarterly earnings narrative, and they will offer favorable terms to customers who commit to OCI — sometimes dramatically so. That creates real opportunity, but it also creates risk: discounts tied to cloud commitments can lock you into a platform before you've fully evaluated it.

Subscription conversion. Oracle — like most major vendors — wants to move customers from perpetual licenses to subscriptions. The pitch is lower upfront cost and easier scaling. The reality: once you stop paying, you stop running. Perpetual license holders always have the option to keep using their software — even without support — as leverage in a future negotiation. Subscription holders don't.

Support revenue. Oracle support costs have historically increased 3–4% annually. In recent years they've moved that ceiling to 8% per year. Over five years, that compounds significantly. Any deal that locks in support costs below that escalator is worth understanding carefully.

---

Evaluating What's on the Table

The most important question to ask when Oracle puts something on the table: does this align with where our business is going?

That means assessing both the present and the future:

Now:

Are current licenses covering actual usage and operations?
Are you paying for products no longer in use?
Does current Oracle spend reflect real value to the business?
Are IT and business priorities aligned on what Oracle is needed for?

Three to five years out:

Can these licenses scale with anticipated growth or M&A activity?
Is there flexibility to shift strategies — cloud, third-party support, or platform alternatives — if Oracle raises prices significantly?
Do the licensing terms support your technology roadmap?
Will current agreement structures limit innovation or expansion?

Oracle Unlimited License Agreements (ULAs) are a useful example of how present-day decisions can create future constraints. ULAs work well for organizations that are growing — but for organizations that have plateaued or are contracting, they can represent significant ongoing cost without commensurate value.

"A lot of customers have Oracle Unlimited License Agreements, which are great for businesses that are growing. But for businesses that aren't growing, it's not necessarily the best arrangement." — Dr. Michael Corey, Co-Founder, LicenseFortress

A common ULA exit strategy is to certify as broadly as possible before the agreement ends — maximizing the license count that converts to perpetual. But this approach isn't without risk. Accepting Oracle's soft partitioning policies during certification sets a legal precedent. If you later add VMware nodes or additional virtualization, you may find yourself owning that policy — and the obligation to license accordingly. Business strategy and licensing strategy need to be aligned before you commit to any of these approaches.

---

Your Licensing Goals Checklist

The following checklist covers the core areas to assess before entering any Oracle negotiation. Work through these before the conversation starts, not after.

Support requirements. Can your organization run perpetual licenses without vendor support if necessary? Do your security and compliance policies allow for unpatched environments — even temporarily? The answer shapes how much leverage third-party support options give you.

Installed versions. What versions are deployed, and which ones are approaching end of life? Oracle database is transitioning away from the non-container model — if you're on Oracle 19c or below, understanding what that transition entails (and when extended support fees apply) is essential.

Support ticket utilization. How often are you actually using the Oracle support you're paying for? If usage is low and the environment is stable, third-party support may be worth evaluating — particularly for systems you're planning to migrate or sunset.

Competitive and third-party alternatives. Oracle doesn't make the only enterprise RDBMS. Third-party support providers can reduce annual support costs by 50% or more. These options are worth understanding even if you don't use them, because the knowledge of them changes the negotiation.

End-user impact. What does your helpdesk data show? If a product is generating low ticket volume and low user dependency, it's a stronger candidate for consolidation, third-party support, or removal from the renewal.

Business requirements. The procurement team's goal is often simple: save money. But savings at the cost of operational capability, security exposure, or flexibility isn't a win. Make sure the business requirements — not just the budget target — are the anchor for any decision.

Long-term technology roadmap. Are you planning a cloud migration? A data center consolidation? An application modernization? Your Oracle licensing decisions now should not create barriers to where you want to be in three years.

Vendor swap or "trade-up" proposals. Oracle will sometimes present bundled "modernization" offers — newer products that do what older products did, plus a few enhancements, at a higher price point. Treat these as requiring the same scrutiny as a new purchase. Anyone who has navigated VMware's transition under Broadcom understands what forced bundling looks like.

---

Common Contractual Pitfalls

The goals checklist covers what you want. But there's another layer: understanding what you might be giving up without realizing it.

Master agreement substitution. Every time you make an Oracle purchase, Oracle may try to introduce a new master agreement. Terms have changed significantly over decades — and not always in customers' favor. A contract from 2005 may include DR and failover provisions (the Oracle 10-day rule) that give you significant flexibility during testing without requiring additional licenses. Today's standard agreement may not. Protecting old master agreements requires explicitly declining to substitute them.

"As Dean said, it's so important — we recommend referencing the previous master services agreement. You've already agreed to that. There's no need to accept new terms." — Dr. Michael Corey, Co-Founder, LicenseFortress

Audit rights. Contract changes that expand Oracle's audit rights — even small, quiet amendments — can significantly increase your exposure. Watch for changes to how frequently Oracle can audit, what scripts they're permitted to run, and what data you're contractually obligated to provide. Running GLAS (formerly LMS) scripts is often in your interest if you understand what they'll show. But knowing what they'll show first is non-negotiable.

Cloud and hybrid provisions. Contracts written before cloud existed may not explicitly cover it. Oracle auditors have historically interpreted ambiguous contract language in Oracle's favor. Contracts that clearly separate on-premises and cloud licensing rights — with no cross-contamination — give you far more flexibility as your infrastructure evolves.

Territory and affiliate restrictions. Newer agreements are more likely to include territory limits or restrictions on affiliate use. If you're a multinational organization or one that acquires and divests entities regularly, these provisions can become very expensive very quickly. Don't accept limitations you didn't have before without understanding their full scope.

---