Oracle ULA Certification Financial and Contractual Checklist
This article is tailored for procurement leaders and IT asset managers at large enterprises involved in Oracle ULA (Unlimited License Agreement) decisions. It provides a financial and contractual checklist to ensure a smooth ULA certification (exit) process from a cost and contract perspective.
Key points include understanding the total cost of the ULA, planning for post-certification support fees, scrutinizing contract clauses (like notice periods and auto-renewals), and negotiating terms to protect your organization’s interests.
Total Cost of an Oracle ULA: What Procurement Needs to Know
Before diving into the certification phase, procurement should have a clear picture of the ULA’s cost structure:
- Upfront Fee: ULAs involve a one-time license fee paid at the start (or spread in agreed installments). This fee gave your company unlimited deployment rights for specific Oracle products during the term. Procurement should reconcile this cost against deployment — essentially, how much did you pay versus how much software value was deployed? This helps in evaluating ROI. For example, if the company paid $4 million for a 3-year ULA and deployed what would have cost $6 million in licenses, you got more value than cost. If you only deployed $2 million worth, there’s unused value.
- Annual Support Fee (During ULA): During the ULA, you typically pay Oracle a yearly support fee. This support fee is often calculated based on a subset (or all) of your licenses before the ULA (or a minimum set in the contract). It usually increases by a small percentage annually (e.g., the standard 3-4% uplift Oracle adds each year on support). Procurement needs to know what support you were paying during the ULA, because it can change after certification.
- Certification and Perpetual Licenses: When you certify, you end up with perpetual licenses for all deployed copies of the software. Importantly, you do not pay Oracle any new license fees at certification – you’ve already paid via the ULA fee. However, all those licenses will now be under support (if you want to receive updates and stay in Oracle’s good graces for audit protection). Immediately after certification, Oracle will issue a support renewal quote for the now-fixed set of licenses.
- Post-ULA Support Costs: Here’s where procurement must be vigilant. If your ULA allowed massive deployment, your support costs can jump. Support is typically ~22% of the license list price annually. During the ULA, maybe you were paying support as if you had 500 licenses (just as an example). After certifying that you have finished with 1500 licenses, Oracle could present a new support bill reflecting those 1500 licenses. Unless capped by contract, the support fee might triple in this scenario. Procurement should forecast this number in advance. Use Oracle’s price list to estimate the perpetual license cost of each product you’ll certify and multiply by 22% to approximate yearly support. For instance, you might find that $500,000/year support could become $1.5 million/year. It’s better to know that early and plan for it in the budget, or look for ways to mitigate (like negotiating or dropping certain licenses from support if feasible).
- Secondary Costs: Consider true-up or compliance costs if something isn’t covered. Procurement’s role is also to handle purchasing licenses for products not in the ULA. If you discover that Oracle WebLogic was deployed during preparation but is not part of your ULA, you may need to buy those licenses separately to be compliant post-ULA. Those costs should be estimated and budgeted now rather than as an unpleasant surprise later. It could be more cost-effective to buy needed licenses while still under the ULA period (perhaps with Oracle giving a discount if it knows you’re trying to rectify a gap) than to be caught after certification with unlicensed usage.
Understanding these cost components helps procurement answer the big question: What will it cost us to exit this ULA immediately and over the next few years, versus if we had to renew or do something else? Having these numbers on hand strengthens your negotiation position and internal decision-making.
Read Oracle ULA Certification vs Renewal: Executive Decision Guide for CIOs and CTOs.
Budgeting for Post-Certification Support and Maintenance
One of the most important tasks for procurement in the ULA certification process is to budget for the post-ULA world:
- Projecting Support Costs: As discussed, use the deployment counts that will be certified to project support. Create a detailed list of each Oracle product being certified, the quantity (e.g., number of processor licenses or Named User Plus), and find the standard list price for each. Multiply quantity by list price, then take ~22% to get the annual support. Oracle typically won’t give you a huge discount on support – support is based on what you own and mostly sticks to that percentage. So, if you have certified many licenses, be prepared for a substantial support invoice annually. Double-check if your ULA contract had any clause about support cap at certification; if yes, apply that in your projection (e.g., support won’t increase more than 10% from what you were paying).
- Avoiding Shelfware Costs: Shelfware refers to licenses you own but don’t use in production. In ULA certification, shelfware can happen if you purposely deploy software to increase your license count but don’t need all of it operationally. Procurement should question overly aggressive last-minute deployments aimed purely at boosting numbers. Why? Because every license you certify will carry an annual support cost. If 30% of those licenses end up unused, you’re paying support for shelfware – effectively wasting OpEx budget. Work with IT to align deployments with genuine business needs. It might be better to certify a slightly lower number of licenses and avoid millions in support on unused licenses, especially if the support cost is uncapped.
- Plan for Support Renewal Timing: The first support bill after certification will usually be timed with your existing support renewal cycle. Ensure the finance team knows the budget support line item will change significantly after the ULA. For instance, if your support renewals are every January, and your ULA ends in July, Oracle might co-term the new licenses to align with January, meaning a prorated support charge for the months from certification to year-end and a full-year support charge. Budget the prorated amount in the current fiscal year and the full amount for the next year.
- Cost Optimization Options: Investigate if there are opportunities to reduce support scope. Oracle’s policies make it difficult to drop support on a subset of licenses (they often have restrictions like you must keep support on all licenses of a given product or terminate all and stop using them). However, third-party support providers (like Rimini Street, Spinnaker, etc.) are an alternative some companies consider after certifying. These firms sometimes offer support for Oracle products at 50% of Oracle’s cost, but it means you stop receiving official updates, and Oracle may not provide help. This is a significant decision involving risk, so it’s not for everyone, but procurement can evaluate it as a potential cost-saving measure once you own the licenses outright. Third-party support could save money if your support costs are skyrocketing and you have stable, older versions of Oracle software. This should be weighed against the value of Oracle’s updates and support. Certification allows you to choose support providers, whereas you had to stick with Oracle’s support under a ULA.
- Contingency for True-Ups: Although certification is meant to cover all usage, procurement should keep a contingency in the budget in case additional licenses need to be purchased during or after certification. If everything is done right, you won’t need it. But if an audit or internal review finds, say, you used an option or feature not in the ULA (and thus not certified), having funds earmarked to quickly remediate by purchasing that license can be prudent. It’s much easier to justify a contingency expense internally than to scramble for unplanned funds when Oracle comes knocking.
In summary, budget planning around ULA exit is about turning the one-time unlimited feast into ongoing, predictable costs and ensuring those costs are as efficient as possible. Procurement’s foresight here directly protects the organization’s financial interests.
Critical Contract Clauses: Notice, Auto-Renewal, and Other Gotchas
Procurement and legal teams should thoroughly review the ULA contract and note any clauses that impact certification and renewal.
Key clauses to check:
- Notice Period for Certification or Non-Renewal: Many ULA contracts require the customer to give Oracle advance notice of intent. For example, a clause might state that you must notify Oracle 30 days before the end of the term if you intend to terminate (certify out) the ULA. Missing this notice could trigger an automatic renewal or create a breach that Oracle could use as leverage. Mark this date on your calendar and send a formal, written notice to Oracle (typically to your Oracle account manager and the official notice address in the contract) stating that you intend to terminate the ULA and proceed to certification. Do this within the required window (better a bit early than late). Keep proof of submission (email records, courier receipts). This protects you from any claim that you didn’t follow procedure.
- Auto-Renewal Clauses: Although not extremely common, some ULAs have auto-extension language. For example, “If the customer does not certify by the end of the term, the ULA will extend for one year at a fee of $X,” or “lack of notice results in automatic renewal.” Identify if your contract has any such clause. If yes, deciding well before expiration is critical because the default might be a renewal you didn’t explicitly approve. If you want an extension or auto-renewal, fine – but most often, procurement will want to avoid accidental renewals. Ensuring the notice (above) is given neutralizes auto-renew clauses.
- Certification Process Details: Look for specifics on what the certification letter must include and who must sign it. Commonly, a clause will say a C-level officer (CEO, CFO, etc.) must sign, and it should list deployment counts by product and perhaps by geographic region or entity. Knowing this, procurement can schedule the executive sign-off in advance (no one wants to chase a busy CFO at the last minute with a legal letter they’ve never seen before). Also, check if the contract requires Oracle to confirm acceptance of the certification in writing – if yes, you’ll want to follow up with Oracle until they do so, and keep that confirmation document.
- Included Products and Exclusions: Ensure you have the list of products covered by the ULA (usually an exhibit or schedule in the contract). Procurement should verify this list against what IT believes is covered. Any products not on that list are out of scope – if you find usage of those, that’s separate from certification (and might need purchase or removal). Sometimes, geographical limits or specific named legal entities can also use the ULA. Highlight any such restrictions, as they could affect your certification counts (e.g., if a subsidiary in another country isn’t covered, its deployments might not count and need separate licensing).
- Cloud Use Clause: If your contract was signed in recent years, see if it mentions cloud or virtualization explicitly. A few ULA contracts now allow or specifically disallow usage on certain cloud platforms. For example, some may permit use in Oracle Cloud (OCI) as part of the ULA, but are silent or negative on AWS/Azure. If there’s a clause about cloud, procurement needs to flag that for the team: any usage outside what’s allowed might not be countable. It could impact decisions like moving workloads before certification or negotiating an amendment. Similarly, a virtualization clause might reference Oracle’s partitioning policy or require you to fully license certain environments. These technical clauses have a financial impact if misinterpreted.
- Pricing Uplift on Renewal: If considering renewal, check if the contract pre-stated a cap or fixed price for renewal (not common, but some deals have a right-to-renew at a certain price). Also, check if there’s a support increase cap at certification. For instance, some contracts say Oracle won’t increase support by more than 20% after certification, regardless of how many licenses you certify. Such a cap is a huge win for procurement because it means you can maximize deployments without fear of tripling support costs. If it exists, that would be great. Make sure Oracle adheres to it. If not, be prepared to negotiate or budget accordingly, as noted earlier.
- Currency and Tax Considerations: If your company operates globally, note the currency in which fees are denominated and any tax/VAT implications of transferring licenses to certain countries at certification. While more of a legal/financial detail, procurement might need to handle purchase order adjustments or internal chargebacks differently after certification if licenses are attributed to different regions.
Procurement ensures that the certification process doesn’t hit any legal potholes by creating a checklist of these clauses and their implications. It also arms you for any negotiation – for example, if you’re aware of a notice period, you can intentionally use or waive it as part of a discussion with Oracle (“We plan to give notice by X date unless we agree on Y”).
Negotiating with Oracle: Procurement’s Role
Procurement professionals excel in negotiation – the ULA certification phase is another time to employ those skills, even if you intend to exit.
Here’s how procurement can add value:
- Leverage the Market and Alternatives: Oracle wants to keep your business. Even as you prepare for certification, it’s worth exploring alternatives. Get quotes for third-party support as a benchmark, or evaluate if migrating some Oracle workloads to cheaper alternatives is viable. You don’t necessarily act on these, but knowing that, for instance, PostgreSQL or cloud-native databases could replace a portion of Oracle usage at a lower cost, gives you a story to tell. You can approach Oracle saying, “We’re certifying and considering third-party support or migrations to optimize cost.” This may pressure Oracle to offer a better deal (maybe a discounted support or a smaller follow-on ULA for just one product at a bargain price) to retain support revenue. Be careful: only use this if it’s credible – Oracle will know if you truly have leverage.
- Negotiating a Renewal or Extension on Your Terms: If your company is open to renewing the ULA (or doing a new one), let procurement lead those commercial negotiations. Aim for improvements over the last deal: lower fees, or the same fee but covering more products, including cloud rights, shorter term if that benefits you, or added services (training credits, cloud coupons, etc.). You can also negotiate the support cap as mentioned – for example, “We will renew, but you must agree that after the next certification, support fees will not increase more than 10%.” Get all negotiated terms documented in writing, ideally in the contract or an amendment.
- Reducing Support Costs: If renewing is off the table and you will certify, you might negotiate with Oracle on the support in the future. While Oracle is generally rigid on support pricing, there is some room right at certification time to discuss the support baseline. For instance, if you ended up with way more licenses than initially anticipated, you could ask, “Can we set the support at a level as if we had X licenses instead of Y, given we paid so much for the ULA?” Oracle might not reduce, but they might agree to freeze support at current levels for a year or two or offer a small discount to prevent you from considering third-party support. Procurement’s job is to push for any concession here, knowing the worst Oracle can say is no.
- Aligning Payment Terms: Whether it’s a final true-up purchase or ongoing support, ensure payment terms meet your company’s needs. Perhaps you want to align the support renewal date with your fiscal year or split payments. Oracle can be flexible with payment schedules if closing a deal is necessary. Don’t be afraid to ask for net-60 instead of net-30, or to split a large support bill into two fiscal quarters.
- Documenting Agreements: Any promise by Oracle (sales reps or even sales directors) must be reflected in writing. Procurement should insist on formalizing things. Verbal assurances like “We’ll give you a 20% discount on new licenses you buy next year since you’re certifying” are not enforceable unless written. Include them in a contract addendum or get an email from Oracle stating the agreed-upon points. Keep these communications filed.
Procurement’s involvement ensures that the business side of the ULA exit is optimized, not just the IT side. While IT focuses on counting installations, procurement minimizes cost and risk in the transition.
Internal Alignment and Process Coordination
Finally, from a procedural standpoint, procurement should coordinate closely with other teams to ensure nothing falls through the cracks:
- Cross-Functional Task Force: If not already formed, ensure there is a ULA exit team that includes procurement, IT/SAM, finance, and legal. Regular meetings should occur 6-12 months before expiration. Procurement can lead discussions on contract dates, costs, and vendor negotiations, while IT leads on data gathering. This task force approach ensures everyone is on the same timeline and considers all perspectives.
- Approval Processes: Identify what internal approvals are needed for various outcomes. If you might need to sign a new contract (renewal or extension), what’s the approval chain? If you must make an unplanned license purchase, how quickly can you approve a PO? Does your executive signer need a formal internal sign-off from the board or legal for the certification letter? Being proactive here avoids last-minute “stuck in approval” issues. For example, if your company requires a CFO’s signature on the letter, does the CFO need a briefing or board approval first? Plan for that.
- Supplier Management: Oracle is a key vendor. Procurement likely manages the Oracle relationship beyond just the ULA. Use this opportunity to update your vendor scorecard or profile: how has Oracle performed during the ULA, and what do you expect after? If you’re exiting, you may renegotiate your Oracle annual support agreement terms – perhaps consolidate support contracts or adjust support contract names. It’s almost like re-onboarding Oracle as a vendor for a different type of relationship (from unlimited license provider to standard support provider).
- Communication with Oracle: Typically, procurement or a senior executive will formally notify Oracle of your decision to certify (as part of that notice letter and eventually the certification letter). Plan who will be the single point of contact for Oracle during the certification process. Too many voices can confuse things. Many companies designate one person (sometimes a procurement contract manager or SAM manager) to funnel communications to Oracle’s team, ensuring consistent messaging. This person should be well-versed in the contract and the company’s stance (renewal or exit) so they don’t accidentally convey the wrong message.
- Risk Mitigation: Identify risks like “What if Oracle rejects our certification counts?” or “What if an unforeseen deployment appears late?” and have a plan. From the procurement side, risk mitigation is often about having budget or contract vehicles ready. For example, you might set up a rapid purchase mechanism for any last-minute licenses needed (perhaps an already negotiated discount on Oracle’s price list, just in case). You might also keep the renewal offer alive as a contingency up to a point. If a major compliance gap is discovered last minute that can’t be resolved quickly, an extension could be a fallback. Discuss these scenarios internally so you’re not caught off guard.
With thorough internal coordination led by procurement and supported by all stakeholders, the Oracle ULA certification can transition from a daunting event to a well-managed project with no surprises.
Recommendations
- Review the ULA Contract Line-by-Line: Procurement and legal should thoroughly read the contract months before expiry. Flag key dates and requirements (notice period, certification format, etc.) to ensure full compliance and avoid penalties.
- Model the Financial Outcomes: Create a detailed cost model for post-certification vs. renewal. Include license value, support costs, and any one-time purchases needed. This model can be used to brief executives and negotiate with Oracle using real numbers.
- Engage Oracle Early (but Carefully): Reach out to Oracle’s account reps to understand their stance. Express that you are evaluating options. This can prompt Oracle to present offers or concessions. However, be cautious not to reveal unpreparedness – keep the discussions professional and exploratory.
- Ensure Budget Allocation: Secure budget approvals for the expected support costs after certification. Communicate with finance that the support expense line will change. It’s better to over-budget slightly for support than under-budget and scramble later.
- Negotiate Support Terms: If a renewal or extension is considered, negotiate a cap on support fee increases at the next certification or get a fixed support period. If exiting, see if Oracle will agree to maintain support at current levels for a year as a goodwill gesture. Always ask – the worst outcome is the status quo.
- Coordinate Last-Buy Opportunities: If any Oracle products you might need were not in the ULA, consider negotiating a purchase just before the ULA ends. You could leverage the ongoing discussions for a better price (“We’ll buy these licenses now since they’re not in ULA, but only if you give a good discount because we’re exiting”).
- Keep Executives Informed: Provide the CIO, CFO, and relevant executives with periodic updates from a procurement perspective—costs saved, costs expected, and any negotiation developments. Their support will be crucial if tough choices or investments need sign-off.
- Maintain Documentation: Log all communications with Oracle—every email, proposal, and meeting minute. This paper trail can be vital if any disagreements arise about who said what. Also, document internal decisions (e.g., “team decided to certify, approved by CFO on X date”) for governance.
- Plan the Certification Letter Process: Work with legal to draft the certification letter early. Have it ready for the exec to sign. Procurement can add value by ensuring it contains exactly the info required (nothing more, nothing less), reviewed against contract language. This avoids Oracle rejecting it for formal reasons.
- Post-Certification Contract Management: Ensure Oracle provides updated agreements or support contracts reflecting your new perpetual licenses after certifying. Audit these documents for accuracy (correct quantities, products, support rates). Procurement should file these as the new “source of truth” for Oracle entitlements and use them for future vendor management and audit defense.
FAQ
Q: Will our Oracle support costs increase after ULA certification?
A: In many cases, yes – especially if you dramatically increased your Oracle usage under the ULA. You will now be paying support for the full number of certified licenses. However, if your ULA already had you paying a hefty support base (for instance, if it was built on a large initial license count), the increase might be modest or nonexistent. It depends on your contract’s terms. Check if your contract had a clause fixing support fees or capping the increase. If not, assume you’ll pay the standard support % on all certified licenses. You can try negotiating or optimizing (for example, dropping support on unused products or moving some systems to third-party support if it makes sense). Still, Oracle will aim to provide full support for everything. Always verify Oracle’s support quote post-certification against your expectations and the contract – mistakes can happen on their side too.
Q: Can we drop some of the licenses from support after we certify to save costs?
A: Oracle’s policies generally don’t allow dropping support on partial quantities of a license set. When you certify, if you want to remain in compliance and receive updates, you’re expected to put all those licenses under support (or at least all licenses of a given product family). If you try to terminate support on some of them, Oracle might assert that your remaining licenses are not valid for use with updates or could even threaten that dropping support means you lose the right to upgrade in the future. That said, some companies certify many licenses and later decide not to renew support for certain products entirely (for example, if you certified an Oracle product that you plan to decommission, you might drop support for that product line). This is a decision to make carefully, weighing cost vs. risk. Without Oracle support, you won’t get patches or help, and Oracle may flag it during audits. In summary, plan to maintain support on everything initially, and only consider dropping it for specific products if you have a decommissioning or third-party plan and fully understand the consequences.
Q: What if we discover usage of an Oracle product that the ULA does not cover?
A: This is a crucial discovery. If an Oracle product is not in your ULA contract, it cannot be included in the certification count. You have two main choices for any such product: remove or license it. Removing means uninstalling it or migrating off before the ULA ends (and ensuring it’s not in use as of the ULA expiration date). Licensing it means purchasing the appropriate licenses through a separate transaction with Oracle. From procurement’s perspective, you’ll want to obtain pricing and perhaps negotiate a deal for those licenses beforehand. Oracle might bundle this with a renewal discussion or sell it standalone. It’s often better to address it proactively rather than hoping Oracle doesn’t notice; if they audit later, the pricing leverage is all theirs. If the usage is minor, removal might be the easiest route (if it doesn’t hurt the business). If it’s critical usage, get quotes and be ready to raise a purchase order. You could also use it as a negotiation chip – for example, “We’ll buy licenses for Product X now, but we expect a discount since we’re handling this outside the ULA.”
Q: Are there any risks in using third-party support after we exit the ULA?
A: Third-party support can significantly cut costs (sometimes 50% or more off Oracle’s support fees) but comes with trade-offs and risks. The major risk is that you’ll no longer receive official Oracle patches, updates, or direct assistance. If a critical security patch comes out, you won’t get it from Oracle – you’d rely on the third-party provider to somehow support you, but they may not have the same resources to issue patches. Also, Oracle’s position is that if you leave their support, you can’t just resume it later without paying back support fees (and possibly penalties), meaning returning to Oracle support can be very expensive if you change your mind. In an audit scenario, using a third-party support provider is not a compliance issue per se (if you own the licenses, you’re allowed to self-support or use a third party). Still, Oracle auditors might scrutinize your usage to ensure you didn’t exceed your licenses. On the positive side, many organizations use third-party support for stable environments to save money and are satisfied. Procurement should do due diligence: evaluate the third party’s track record, get references, and understand which products are suitable. For example, it might be viable for older versions of Oracle products you don’t plan to upgrade. It’s a strategic decision – involve your IT leadership and possibly the CIO in weighing the benefits vs. risks.
Q: What can we negotiate with Oracle if we decide to exit (certify) rather than renew?
A: Even if you’re exiting, there may be things to negotiate. One is the support baseline (discussed earlier) – you might ask Oracle for a concession such as maintaining your current support spend for the next year despite certifying a larger number of licenses. Oracle has no obligation to agree, but if they sense that doing so might keep you a happy customer, they might offer a slight discount or a phased increase. Another aspect is future purchase discounts – you could ask Oracle for a discount on any additional licenses you might need post-certification (almost like a volume discount locked in, should you grow). Sometimes, as part of a smooth exit, Oracle might extend special pricing for 12 months if you need to buy something else. Ensure any such promises are documented. Finally, you could negotiate any transition services – for example, Oracle assistance in deploying their audit tools for your verification now (on your terms, not theirs), or a technical workshop to help your team optimize usage. These soft elements can be valuable and relatively easy for Oracle to grant if they mean goodwill.
Q: How do we handle Oracle’s attempts to push cloud subscriptions during the certification?
A: Oracle often tries to pivot the conversation to their cloud offerings (OCI – Oracle Cloud Infrastructure or cloud-based apps). They might propose a deal where you convert some of your usage to an Oracle Cloud subscription instead of certifying purely on-prem licenses. From procurement’s view, this complicates things because it changes the model (from owning licenses + support to a subscription service). If cloud is part of your IT strategy and Oracle’s cloud is appealing, you can entertain those discussions. Just evaluate cloud proposals on merit: What’s the cost for equivalent capacity in the cloud vs. on-prem support? Are there long-term contracts or lock-in? Oracle might offer cloud credits as a carrot (e.g., “renew the ULA or sign this new agreement and get $X in cloud credits”). Ensure those credits align with your desired services and the flexible cloud usage terms. If cloud is not in your plan or Oracle is not competitive, politely steer back to the matter: “We are focused on closing out this ULA; we can discuss cloud separately.” Oracle can sometimes bundle a small cloud deal to save face as you exit (so they can claim a win). If that doesn’t hurt and provides some benefit, procurement can structure it as a low-risk (like a pilot amount of cloud services). But be wary of any proposal that essentially replaces the ULA with a cloud subscription commitment of similar scale unless that was already a direction you wanted – you don’t want to swap one lock-in for another without due consideration.
Q: What internal metrics should we capture to measure the success of the ULA certification from a procurement perspective?
A: Good question – post-project, procurement should evaluate: Did we come under or within the expected budget for the process? (Compare projected support costs vs. negotiated actuals, license purchases made, etc.) What was the ROI of the ULA? (How much value in licenses did we certify relative to what we paid – that ratio is a measure of success; e.g., 2x value means money well spent, 0.5x means not so much). Compliance status: Ensure that the result is zero outstanding compliance issues (this is more binary – success is 100% compliant, no surprise costs). Also, regarding process efficiency, did we meet all deadlines (notice given, letter submitted on time)? If all these are green, procurement did a great job. Documenting any concessions gained (support caps, discounts, etc.) as achievements is also useful. This kind of metrics review can help in future negotiations with Oracle or other vendors – showing that procurement managed a multi-million dollar contract exit smoothly and saved $X or avoided a Y% cost increase is a strong story.
Q: Our CFO is concerned about the many licenses we’ll have. Is there a downside to having more licenses than we use?
A: The main downside is the support cost on those licenses (as we discussed about shelfware). Beyond that, there’s no direct penalty for having more licenses than needed – you’re effectively future-proofed for growth to some extent. The CFO’s concern is valid in that those extra licenses will appear as an asset (you paid for them via the ULA fee) and a liability for ongoing support fees. It might look like inefficiency to have, say, 1000 licenses but only actively use 800. Procurement can address this by quantifying the cost of those extra 200; are they truly adding support cost? If support is uncapped, yes, they do add cost, which is why you’d try to avoid far overshooting usage. If support was somehow capped, having extra licenses doesn’t cost more until you need support for them (which typically you pay for all anyway). You could also potentially terminate some unused licenses formally to reduce support, but Oracle rarely allows partial termination without terminating all and re-buying what you keep (an impractical approach). The best way to frame it is: during a ULA, you err on the side of certifying slightly above current needs to ensure headroom, and you manage the support costs via careful contract negotiation. If the CFO is worried, show the comparison of what it would have cost to buy licenses for those 800 used ones outright – likely far more than the ULA fee. The “extra” licenses can be considered bonus capacity that costs little marginally. Emphasize that procurement and IT will govern these assets so that if usage grows, no new spend is needed (saving future capital). And if usage doesn’t grow, you can reassess support strategy in a couple of years (maybe even trim support if certain they’re not needed, though again, Oracle’s policies limit that).
Q: How far in advance should procurement lock in any needed purchase orders or approvals for this process?
A: Aim to have all internal approvals for likely expenditures at least 1-2 months before ULA expiration. That includes approval for any true-up license purchases (if identified), approval for the support expenditure increase, and approval for any consulting services you might use (like hiring a third-party to assist with certification). By 3 months out, you should have identified potential spending and started the approval workflow. By 1 month out, you want POs ready (even if they’re contingent on something). The certification usually doesn’t involve paying Oracle money (unless you owe a support true-up or buy extra licenses), but any associated costs should be lined up. Also, ensure the certification letter signatory is prepped around that time – they may need to sign a document binding the company, so follow your internal policy for contract/legal approvals for that letter. Essentially, treat the certification project like a mini-sourcing project: you gather requirements (license needs), line up suppliers (Oracle or others for any purchases), get approvals, then execute at the right time.
Read more about our Oracle ULA License Optimization Service.
