This is Part II 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: mapping your contracts, understanding your entitlements, and building a clear picture of your Oracle estate. Part II picks up where that left off — analyzing how your organization actually uses Oracle products.
This step is critical not only for compliance, but for cost optimization. You cannot negotiate intelligently, plan a cloud migration, or prepare for a renewal without knowing exactly what you're using, where it's running, and whether it aligns with what you've licensed.
---
Why License Usage Analysis Matters
Oracle doesn't use license keys. That's not an accident — it places the burden of compliance tracking entirely on the customer, making it easy to be using more than you've licensed without realizing it.
There are four core reasons to conduct a thorough usage analysis before Oracle's fiscal year end:
- Cost savings: Understanding your usage reveals where you're over-licensed, where you're under-deployed, and where you can eliminate waste.
- Compliance assurance: In the decade LicenseFortress has been doing this work, we've yet to find a customer who is fully license-compliant. Software creeps into environments — through shadow IT, cloud sprawl, and infrastructure changes — without anyone flagging a licensing impact.
- Negotiation leverage: Usage data is your strongest negotiating asset. Concrete evidence of over-licensing in one area and under-deployment in another creates a factual basis for renegotiating terms.
- Strategic planning: Whether you're planning a cloud migration, a renewal, or a ULA certification, your usage data is the foundation every decision should be built on.
- Enhance performance and resource allocation: Usage analysis helps boost productivity and improve user experience by ensuring the right resources are allocated to the right workloads — eliminating bottlenecks caused by over-provisioned or misallocated licenses.
---
What to Analyze
Your Oracle entitlements
Before assessing usage, you need a clear view of what you're entitled to use. Pull together:
- All Oracle contracts, including Order Documents and Master Agreements
- License metrics for each product (processor, Named User Plus, employee-based, etc.)
- Support and maintenance terms
- Any special agreements — ULAs, ELAs, limited-use licenses, application-specific, and embedded software — all of which carry different terms and restrictions
Pay particular attention to agreement age. Older Oracle agreements sometimes contain entitlements — such as legacy backup and DR provisions — that can be leveraged significantly in cost optimization if they're identified and understood.
Also review your purchase orders carefully. Rights and restrictions can be embedded in POs from subsequent purchases in ways that materially affect your current compliance position. Document everything you find. This analysis is expensive to repeat — don't start from scratch next year.
How your usage compares to your entitlements
Once entitlements are mapped, the next step is comparing them against actual deployment. This means:
- Running Oracle scripts (GLAS (formerly LMS) scripts) across your environment to capture what's installed and running
- Identifying compliance gaps and potential license drift
- Checking not just the systems where Oracle is known to be installed, but environments where it might have appeared undetected
"I can't tell you the number of times we've gone into a customer who said, 'We only have Oracle deployed here and we're only using these options,' and once we do the review, we find things that have crept into their environment. Shadow IT, cloud environments make it very easy for these systems to appear. Check not just the places where Oracle is installed — but where you think it isn't installed." — Dean Bolton, Co-Founder, LicenseFortress
Shadow IT and cloud proliferation are the two most common sources of unexpected Oracle deployments. Any system that has touched an Oracle installer — even briefly, even in a test environment — may carry a licensing obligation.
Utilization trends
Entitlement coverage is one thing. Actual utilization is another. Trend data — ideally 12 months or more — tells you whether your deployments are genuinely necessary, over-provisioned, or candidates for consolidation.
For on-premises environments, track historical CPU, memory, and database usage across your Oracle estate. For cloud environments, usage analysis becomes even more important:
"In the cloud, you're buying by the drink. You really need to understand how many drinks — how much usage — you're actually doing in a one-week period, a 30-day period, a 12-month period. If you don't understand that, it can be a very costly exercise." — Dr. Michael Corey, Co-Founder, LicenseFortress
Peak usage analysis determines your actual licensing need. Don't optimize based on averages — Oracle licenses the peak, not the mean.
Underutilization
Underutilized systems are one of the most common sources of avoidable licensing cost. Common patterns include:
- Databases that are technically active but carry no meaningful workload
- Test and development environments licensed at production rates
- Standby or DR systems that haven't been exercised in years
Identifying these systems allows you to retire redundant infrastructure, consolidate workloads, and reallocate budget. Many organizations are running on decisions made 10, 15, or 20 years ago — environments that made sense at the time but no longer reflect how the business operates.
A practical warning: "decommissioned" systems that were never actually removed from the estate are a recurring audit finding. If Oracle software is still installed on a server — even if the server hasn't been used in years — Oracle can and will count it in an audit. Decommissioning must be verified, not assumed.
Business requirements
Usage analysis isn't purely technical. It should always be grounded in what the business actually needs.
Questions to work through with stakeholders:
- Which Oracle products are genuinely business-critical today — not just historically important?
- Are there workloads that could be served by a lower-cost edition or an alternative product?
- Are DR and backup configurations aligned with Oracle's contractual terms, or have they grown beyond what's licensed?
- What are the realistic growth projections, and do they change the licensing picture?
Optimizations emerge from combining Oracle licensing expertise, legal analysis, and technical architecture review — but only when all three are anchored to actual business requirements.
---
Case Study: ESSP's Strategic Shift to Oracle on Azure
One enterprise software service provider — a longtime Oracle customer — was running Oracle Database Enterprise Edition across two dedicated data centers: one for production, one as a passive standby for disaster recovery that had never been needed in 10 years.
Challenges:
- Running Enterprise Edition at significant cost for workloads that didn't require it
- Maintaining a full second data center as a DR environment that was never used
- Lack of clarity on whether the architecture could support a move to Standard Edition 2
After a thorough usage and requirements analysis, the path forward was clear:
- Oracle 19c (and now 21c) supports multi-tenant architecture in Standard Edition 2, enabling database consolidation onto a single server — something that required Enterprise Edition in earlier versions
- The passive DR data center could be replaced with Azure cloud infrastructure, consumed only when actually needed
- The workload profile confirmed that SE2 could support the business requirements
Results:
- ~$35,000/year saved by eliminating the second data center
- ~$100,000/year saved by switching from Enterprise Edition to Standard Edition 2
- A 90% reduction in total Oracle software expenses
- Streamlined operations: unified DR processes instead of separate Oracle and non-Oracle swim lanes
---
Oracle Policies Are Not Your Contract
A consistent theme across every LicenseFortress engagement: Oracle policies are not your contract.
Oracle's internal licensing policies — including the Partitioning Policy governing VMware environments — are frequently cited by Oracle GLAS (formerly LMS) during audits. These policies are not contractual. The Oracle Master Agreement defines your obligations: you must license Oracle programs wherever they are installed and/or running. What it does not dictate is how you control where they're installed and running. That is determined by your technical architecture and your contract — not by Oracle's internal policy documents.
The same principle applies to cloud environments. Oracle's demands for full infrastructure licensing in public cloud deployments are non-contractual unless explicitly included in your agreement. Understanding what your contract actually says — and what it doesn't say — is one of the most valuable things you can do before Oracle's fiscal year end.
---
Where This Series Goes Next
- Part III: Defining organizational goals
- Part IV: Building a negotiation strategy
- Part V: Mastering timing & execution
- Part VI: Post-signature safeguards
Watch the Part II webinar on Vimeo to see the full session, including live Q&A.
Schedule a consultation to start your EOFY preparation, or explore our Oracle Audit Defense services to understand your current exposure.
