Optimizing Your Oracle License Footprint Before Renewal to Reduce Costs
Executive Summary:
Before entering an Oracle support renewal, CIOs and IT Asset Managers should optimize their Oracle license inventory to avoid paying for what they don’t use.
This article guides enterprise leaders through identifying unused Oracle licenses (“shelfware”), understanding Oracle’s restrictive policies (like Matching Service Levels), and rightsizing license metrics (e.g., Named User Plus vs Processor licenses).
Organizations can dramatically reduce support costs while staying compliant by eliminating shelfware and adjusting license counts before renewal.
Audit Your Oracle License Usage Early
The first step in optimizing your Oracle footprint is a thorough internal license audit before the renewal date. Inventory your organization’s Oracle products and licenses, then map that against actual usage in production, development, and test environments.
Engage application owners and database administrators to determine which systems are in use and at what capacity.
This audit often reveals surprising facts—for example, you might discover a legacy Oracle database no longer used in operations or modules of an Oracle application suite that the business stopped using.
By uncovering these instances, CIOs clearly understand which licenses deliver business value and which are idle. It’s also important to check license deployment against contract entitlements to ensure you’re not unintentionally using more licenses than purchased (which could pose compliance risks).
This audit sets the foundation: you can’t optimize what you haven’t measured. The goal is to spotlight opportunities to trim the fat – i.e., licenses and support fees that can be shed.
Read Negotiating Oracle Support Renewals: Strategies for CIOs to Cut Costs.
Identify “Shelfware” and Unused Licenses
In many large enterprises, a significant portion of Oracle licenses are shelfware – purchased capacity that sits unused or underutilized.
Common culprits include: modules from Oracle E-Business Suite that were never implemented, extra database licenses bought for a project that scaled down, or middleware products that have been retired but are still technically licensed.
Shelfware is costly because for every unused license, you still pay 22% of its cost in annual support. For example, if each Oracle Database Enterprise Edition license costs $47,500, its support is about $10,450 per year – paying that for a database you’re not actively using is pure waste.
Begin by pinpointing these candidates for elimination:
- Analyze usage data: Look at Oracle audit logs, monitoring tools, or SAM (Software Asset Management) data to see when each instance or feature was last used. If a database hasn’t been started in 12 months, it’s a strong shelfware candidate.
- Interview stakeholders: Sometimes, applications tied to certain licenses have been decommissioned. Confirm with business units whether an Oracle product is still needed or can be fully retired.
- Estimate potential savings: Calculate the support dollars tied to each underused license. Highlight that eliminating 10 unused licenses could save roughly 10 × 22% of the yearly license price in maintenance fees. This builds the business case for action.
Compiling a list of unused licenses and their annual support costs will clarify the financial upside of terminating them. Many firms find that 10–30% of their Oracle spend is tied to shelfware, which presents a huge opportunity to reinvest those funds elsewhere once addressed.
Oracle’s Matching Service Level Policy
Before you drop any Oracle support, you must understand Oracle’s Matching Service Levels policy (sometimes called the “all or nothing” support rule).
This policy stipulates in Oracle’s support contract that all product licenses must be supported at the same level.
Practically, this means you cannot simply drop support on a subset of your licenses for a product while keeping support on others, at least not without terminating those licenses entirely.
For example, if you have 100 Oracle Database Enterprise Edition licenses under one agreement, you can’t stop supporting 30 of them to save money while still using those 30. Oracle would require that you either continue supporting all 100 or, if you insist on not renewing support on some, you must terminate (give up) those licenses.
This prevents customers from paying support only on the licenses they actively use and shelving the rest—Oracle wants to avoid that scenario.
As a CIO, factor this in: any reduction in support scope will likely involve contractually relinquishing the unused licenses (we’ll discuss how to do that next).
It’s a tough policy, but knowing it upfront prevents costly mistakes. You can’t “halfway” drop support on a product – it’s all or nothing for each product family. Plan your optimization accordingly, product by product.
Terminate Unused Licenses to Cut Costs
Given Oracle’s rules, the primary way to stop paying support on truly unused licenses is to terminate those licenses. Termination means you formally notify Oracle (usually via a “Termination Letter”) that you are ending your right to use specific licenses.
Oracle then removes them from your support entitlement, and you will no longer be billed for maintenance on them.
However, termination is a one-way door: you give up any rights to use those licenses in the future, despite them originally being “perpetual” licenses.
If needs change later, you’d have to purchase new licenses (or attempt a costly reinstatement, which Oracle heavily penalizes – more on that in the contract article).
Because of this finality, evaluate carefully which licenses you can live without permanently.
Best practices for termination:
- Target clearly unused licenses: Only terminate licenses you are confident have no foreseeable use. For instance, if you decommissioned an Oracle PeopleSoft module because your company moved to a different solution, those licenses are good termination candidates.
- Obtain internal approvals: Work with finance and business stakeholders to get buy-in that certain licenses can be shed. There may be internal resistance (“What if we need it again?”), So present the cost of keeping them vs. the low likelihood of future use.
- Follow Oracle’s process: Have your legal or procurement team engage Oracle for the formal termination request. Oracle typically drafts an amendment or letter listing the licenses to terminate for you to sign. Review it carefully to ensure only the intended licenses are included and there are no unexpected terms.
- Document everything: Keep records of your terminated licenses and their effective dates. This is important for compliance—if Oracle audits you later, you must demonstrate that unsupported licenses are not deployed in your environment post-termination.
Terminating unused licenses can yield immediate savings (you won’t pay support for them in the next cycle), but it can be balanced against future needs.
If there’s even a moderate chance a license might be needed in a year or two (for example, a module needed if the business expands), consider alternatives like keeping it one more year while monitoring.
Or see if Oracle will allow a “shelf” arrangement (rare, but sometimes Oracle has allowed customers to suspend support on certain licenses without terminating, typically in special cases negotiated in writing).
In most cases, though, cutting the cord on shelfware is cleaner.
Optimize License Metrics and Configurations
Beyond removing unused licenses, examine whether your current licensing model is the most cost-effective for each Oracle product. Oracle often offers multiple metrics (e.g., Processor vs. Named User Plus (NUP) for databases), and the optimal choice can change as your usage patterns change.
For instance, Oracle Database Enterprise Edition licenses can be based on processors (unlimited users per CPU) or Named User Plus (a specific number of users, with a minimum per processor).
If your environment has few distinct users or devices but runs on a multi-core server, you might save money with NUP licenses instead of processor licenses.
Real-world example:
Imagine you have a database running on a server with two processors. Oracle’s license rules require 25 Named User Plus licenses per processor.
So, for two processors, the minimum NUP count is 50. Oracle’s price list (as of recent years) pegs a processor license at roughly $47,500, and a Named User Plus at roughly $950. That means:
- Processor licensing: Two processors × $47,500 is $95,000 in license costs (support ~$20,900/year at 22%).
- Named User Plus licensing (50 users): 50 NUP × $950 = $47,500 license cost (support ~$10,450/year).
For a system with, say, only 40 actual users, NUP licensing meets the requirements (50 is the minimum) and costs about half as much as processor licensing in both license and support terms. In this scenario, switching to NUP licenses could save tens of thousands in support fees annually.
On the other hand, if the user count were in the hundreds, processor licensing is more economical. The key action item is to review your current Oracle products and check if the license metric still fits your usage.
Perhaps years ago, you licensed processors for flexibility, but today, only a small group uses the software. You might negotiate a transition to NUP at renewal or purchase new NUP licenses to replace processor licenses (while terminating the old ones).
Also consider technical optimization: consolidating workloads onto fewer cores or servers (where feasible) to reduce the required licenses, or using Oracle-approved virtualization technologies carefully to partition and limit Oracle software to specific processors.
Always adhere to Oracle’s licensing rules when reconfiguring (e.g., be mindful of Oracle’s hard partitioning vs. soft partitioning rules) – but if you can legitimately run the same workload on half the cores, you could cut your license and support count by 50%.
Any architecture changes should be planned well before renewal so that you can adjust license counts in the new contract.
Plan for Future Needs (Don’t Cut Too Deep)
While cost reduction is crucial, optimization should be balanced with foresight. Before making final decisions on terminations or metric changes, consider your organization’s future roadmap for the next few years:
Are there projects that might require those Oracle products you’re about to drop? Will a user base grow, making Named User licensing less viable later?
Engage enterprise architects and business unit leaders to forecast demand. Suppose you anticipate needing certain Oracle software again shortly.
In that case, you might decide to retain some licenses (and their support) as a strategic reserve rather than incur higher costs to re-buy later. In other cases, you might plan to migrate off an Oracle product entirely in a year or two, so cutting back now and potentially dropping all licenses later could make sense.
Also factor in Oracle’s rules like reinstatement fees (if you drop support and later want it back, Oracle will charge backdated fees + 50% penalty, making it very expensive). The optimization process should thus also deliver a long-term license plan, not just a short-term cost cut.
The outcome might be a mix: some licenses are terminated now, some are kept but may not be renewed next cycle, some are converted to a different metric, etc. By thinking a few years out, CIOs can avoid over-optimizing for the present and then scrambling (and paying through the nose) for licenses later.
Your pre-renewal optimization will result in a leaner Oracle license portfolio that meets current needs with minimal waste.
Recommendations
- Conduct a comprehensive license usage audit at least 6+ months before renewal. Catalog every Oracle license and verify how, where, and if it’s being used.
- Identify shelfware early. Pinpoint Oracle licenses (databases, applications, options) that are deployed but not actively used. Quantify the annual support cost tied to these unused licenses.
- Engage stakeholders to confirm that unused licenses can be safely eliminated. Double-check with application owners and future project plans to ensure an unused product is not needed.
- Comply with Oracle’s policies. Remember that you generally cannot drop support on a subset of licenses without terminating them. Review the Matching Service Levels policy and plan reductions accordingly (product-by-product).
- Terminate genuinely unused licenses to immediately stop the maintenance fees. Follow Oracle’s formal process and timing for termination (often needs a 30-90 day notice before renewal). Ensure you receive written confirmation of the termination from Oracle.
- Optimize licensing models—evaluate if a different license metric (user-based vs. processor, etc.) would lower costs given your usage. Where feasible, re-license more cost-effectively at renewal (even if it means buying under a new metric and retiring old licenses).
- Consider technical optimization. See if consolidating Oracle workloads or limiting CPUs could reduce the required licenses without impacting performance. Work with your infrastructure team to create right-sized environments before true-up and renewal.
- Document all changes—Maintain an internal record of what licenses you decided to drop or change, along with the business justification. This helps defend the decision internally and in case of any Oracle inquiry or audit later.
- Stay compliant during changes. If you plan to remove or downgrade licenses, ensure they are not actively used once support is dropped. Implement controls so that no users or servers continue running software for which support was not renewed.
- Evaluate third-party support as an interim – for products you still use but cannot justify full Oracle support costs, you might consider third-party support (which often costs 50% of Oracle’s price) as a bridge. This allows you to drop Oracle support fees but keep a form of support for the software. Be sure to move all product licenses to a third party if you choose this route (to comply with Oracle policies).
- Revisit license needs annually – optimization is not one-and-done. Each year (or renewal cycle), re-check your Oracle license utilization. Businesses change, and a continual cleanup mindset ensures you only pay for what you need over time.
Read Oracle Support Renewal Contract Checklist: Key Clauses and Best Practices.
FAQ
What is “shelfware” in the context of Oracle licensing?
“Shelfware” refers to Oracle software licenses your organization owns but isn’t using (or using only minimally). They’re essentially sitting on the shelf. For example, if you bought 100 licenses of an Oracle product but only deployed 70, the remaining 30 are shelfware – yet you’re likely still paying annual support on all 100 until you take action to remove those unused licenses.
How do we find unused Oracle licenses in our environment?
Start by comparing your Oracle license entitlements to actual usage. Use tools and methods like Oracle’s LMS scripts, third-party license management tools, or internal monitoring to see what is installed and active. Check user counts, concurrent connections, or feature usage logs for each Oracle product. Additionally, speak with system owners – they often know if a particular instance or module hasn’t been touched in ages. This combined approach (technical data + human confirmation) will highlight licenses that are good candidates to drop.
Can we drop support for some licenses while keeping it for others?
It is generally not for the same Oracle product. Oracle’s Matching Service Levels policy means you can’t say “I’ll support 50 of my 100 licenses and not pay for the rest” unless you terminate the 50 you don’t want to support. You must maintain the same support level for all licenses of a given product family under a contract. The only way to reduce the count on support is to eliminate licenses from your agreement. You can, however, drop entire products – for instance, discontinue support for a product you no longer use, while keeping support on other products.
What is the process to terminate Oracle licenses we don’t need?
You must inform Oracle (usually in writing) that you wish to terminate specific license quantities. Typically, your Oracle rep or Oracle Contracts team will provide a simple “termination letter” or amendment listing the licenses to remove. You sign it, and Oracle countersigns. The timing is important – you should do this before the renewal quote is finalized (and as per any notice period in your contract, often 30-90 days before the support term ends). Once executed, those licenses are removed from your support coverage, and you won’t be billed for them in the next period. Remember, terminated licenses are gone for good, so be sure.
If we terminate a license now, can we re-license it later?
Yes, but it would mean buying a new license (or paying a hefty reinstatement fee to Oracle if you let support lapse and want it back). Oracle’s reinstatement fee usually requires paying all back support fees from the gap period, plus a 50% penalty. In many cases, that costs more than just buying a new license. So, practically, once you terminate, assume that returning to Oracle’s support for that product would require starting from scratch (which could be expensive). That’s why it’s important to only terminate licenses you’re confident you won’t need in the foreseeable future.
What is Named User Plus (NUP) licensing, and how is it different from processor licensing?
Named User Plus licensing means you license Oracle software based on the number of distinct users (or devices) that access it, subject to Oracle’s user minimums per processor. Processor licensing means you license based on hardware capacity (number of processors or cores, with core factor adjustments) and can have unlimited users. NUP is often cheaper for systems with a limited user population, whereas processor licensing is simpler and better for large or uncountable user bases. For example, suppose you only have 40 employees using an Oracle database on a 2-processor server. In that case, you might license 50 Named Users (minimum requirement) instead of 2 processors, which could cut costs dramatically, as illustrated in the article.
Can we switch an existing Oracle system from processor licensing to Named User Plus to save money?
In general, you can’t unilaterally change the metric on licenses you already own – those are sold as one metric or the other. However, you could approach this during a renewal or true-up: one strategy is to purchase new licenses under the preferred metric (NUP, in this case) for the same product and terminate the equivalent processor licenses. This effectively “converts” your licensing model. It requires an upfront purchase, but could reduce ongoing support costs if it lowers the supported license quantity value. Another approach is asking Oracle if they’ll allow a metric change for a specific deployment during a contract negotiation. They might be open to it if it results in them selling additional licenses or if it’s part of a broader deal. After any change, ensure you comply with user minimums and other rules.
How do we safely reduce the number of Oracle processor licenses?
If analysis shows you can run on fewer processors (for instance, your servers are underutilized), you have a few options. You could physically reconfigure or consolidate databases to use fewer CPU cores (making sure to use Oracle-approved hard partitioning or other methods compliant with licensing). You can terminate the excess processor licenses once you’ve reduced the needed cores. Alternatively, if moving some workloads to non-Oracle systems or the cloud, you might decommission certain processors’ worth of Oracle usage. Any reduction must be reflected in how the software is deployed, or you risk a compliance issue. In short: reduce usage first, then reduce licenses – never cancel licenses while still using the capacity they covered.
What about Oracle options and add-ons – can those be dropped separately?
Oracle’s database and some apps have options/packs (like Partitioning, Diagnostics Pack, etc.) that are separately licensed. Suppose you no longer need a particular option. In that case, you can indeed drop support on that option’s licenses (by terminating them) without dropping the base product licenses, as long as you stop using the option. This can save money because those options also carry 22% support fees. Just ensure that the option is not enabled or used anywhere (Oracle’s audit scripts will catch usage of options). The Matching Service Level policy applies within each product family: an option is considered its product for support purposes, so you can drop an option and keep the main product, or vice versa, as needed.
How soon before the renewal should we finalize license optimizations?
Aim to have your license optimization decisions (what to drop, what to keep, any metric changes) ready at least 2–3 months before the renewal date. This gives you time to notify Oracle of any terminations within the required notice windows. It also allows for the incorporation of changes into the renewal negotiation. For example, suppose you decide to terminate certain licenses from a support contract renewing on June 1 in March. In that case, you can inform Oracle in March/April and ensure the renewal quote they prepare reflects those licenses being gone. If you wait until the last minute, you might miss notice deadlines or face a scenario where Oracle has already issued an invoice for another year of support on stuff you meant to drop. Early decision-making is key to smooth execution.
