- Erwann Couesbot
- Reading Time: 4 minutes
If your organization is considering Oracle for application or technology products, you’ll have to determine which licensing model best suits your organization’s needs. One option is the Unlimited License Agreement (ULA), which grants you the right to use an identified list of products on an unlimited basis for a limited period (typically a 3-year term). While ULA’s can provide a tremendous amount of value for some organizations, there is the possibility of over-paying support fees in perpetuity once the ULA expires. Fortunately, you can avoid making this mistake with these steps.
1. Carefully Consider If a ULA Is Right for You
If your organization is anticipating growth and unable to accurately forecast demand over the next 3 years, it is very likely that Oracle will propose a ULA with more appealing discounts than the traditional component-based model. But don’t let Oracle’s upfront pricing be your deciding factor. Oracle may paint a compelling case for the ULA, citing its simplicity, steep discounting, and unlimited licenses, but that doesn’t mean it is necessarily the best option. As seen with many other providers, Oracle will push the most profitable license model for them, which in some scenarios can be the ULA.
ULAs are best-suited for organizations expecting a tremendous amount of growth and license deployments resulting from projected initiatives over the term of the ULA. While the ULA may seem great at first glance, the traditional component-based model may be less expensive in the long-run if the projected growth and license deployments do not materialize. To determine ULA pricing, Oracle will look at the forecasted demand and then add in a growth factor percentage as a contingency for unexpected growth. This creates a demand baseline with which to price the ULA license and support fees. Once the ULA expires, the support fees remain the same, subject to standard annual increases, regardless of the number of licenses deployed.
Two Possible Outcomes Upon Exiting a ULA
When a ULA expires and a company elects not to renew, customers must certify how many licenses they have deployed under the ULA. This license certification becomes the customer’s license entitlements for those products moving forward, which will now be under a component-based model should the customer need to purchase additional licenses in the future. Exiting the ULA is when some Oracle customers first realize that the support fees paid during the ULA term will stay the same regardless of how many licenses are deployed and certified. This means there are two possible scenarios that can result from exiting and certifying deployed licenses at the end of a ULA.
Scenario A: You deploy and certify more licenses than you and Oracle forecasted when you negotiated the ULA, thereby receiving support at an even greater discount in perpetuity since you have the right to use more licenses than forecasted.
Scenario B: You deploy and certify licenses lower than forecasted and you end up paying a higher fee for support on a lower number of licenses in perpetuity.
If you end up with Scenario A, congratulations! This is the best-case scenario for you. However, finding yourself in Scenario B is much more common – and costly. Depending on the size of your organization and the level of under-deployment, this can potentially equate to millions of dollars in support fees that could have been avoided if you did not overestimate your expected utilization level in the proposal phase or if you would have decided to go with a component-based model.
Essentially, you’re paying for support on licenses that you did not deploy and are not entitled to deploy in the future. You do not receive license entitlements based on the forecasted demand, only on what is deployed at the time of certification. You’re simply paying higher support fees per deployed license since you were unable to deploy as many licenses as was forecasted. Of course, Oracle will defend the value of the ULA by claiming that your discount would have been substantially less if you bought via a component-based model, so you would have paid far more in net license fees and associated support if you did not choose the ULA. Either way, you’re paying support fees in perpetuity that could have been avoided. This brings us to step 2.
2. Approach Oracle with a Conservative Estimate from the Start
It is critical that you have a firm grip on your actual licensing demand roadmap before the proposal phase. Regardless of the requirements you send to Oracle, they will likely provide a proposal that shows what a component-based structure would look like for those requirements and how a ULA structure would be comparatively better for the same requirements. Since Oracle will base the support fees in your ULA proposal off your initial estimate of your license requirements for the duration of the ULA, plus a contingency for unexpected growth, providing Oracle with a conservative estimate in the proposal phase will save you from paying more for support after the ULA expires.
However, keep in mind that once Oracle presents you with a ULA proposal based on your forecasted demand estimate, lowering this original estimate during the negotiation phase is extremely challenging without having Oracle modify the associated discounting and potentially other commercial terms of the deal. It is always easier to increase forecasted demand during a negotiation. So be conservative with your estimate from the start and your support fees will be significantly lower when you certify your deployed licenses at the end of the ULA.
The Takeaway
Carefully considering whether you truly need a ULA in the first place and being conservative in your initial forecasted demand estimate can potentially save you millions of dollars in support fees down the road.
