Reducing Oracle Licensing Costs: What They Do Not Want You to Know

This article is aimed at relating my experience in trying to reduce Oracle licensing costs, how they view contracts, and how to put yourself in the best position in relation to your licensing arrangement. I plan to explain more about the Oracle licensing model in future articles. In this article I will use the Oracle Enterprise Database product as an example. First of all, in my opinion, Oracle seems to like having large contracts with customers. By this I mean that they would prefer to have one license contract covering many instances of their software products. The article How Oracle Licensing Differs also includes information on how Oracle builds large contracts with customers. An example would be having contract id AB123 that includes 100 CPU licenses of the database product. In this example the 100 cpu licenses are distributed across 10 servers - each with 10 cpu’s. When you purchased these 100 cpu licenses you paid the upfront license cost for the 100 cpu’s and each year after you pay a yearly maintenance fee that covers support and software upgrades for these 100 licenses. Let’s say in this example you paid 75% of list price. List price for the Database Enterprise Edition is $40k per cpu, so you paid $4,000,000 x 75% = $3,000,000 for the upfront licenses and pay 22% (15% support + 7% software upgrades) of list for at yearly maintenance for a total of $660,000. Now for the part they don’t want you to know – they will try to maintain this yearly revenue stream at $660,000 no matter if you are actively using all 100 licenses or not. Hypothetical situation - Somewhere down the line, you are a good IT manager and find a way to cut costs by consolidating platforms. After your consolidation you can decommission two of your 10 cpu servers. So you go to Oracle and inform them you are no longer using 20 of your 100 cpu licenses and would like to only pay maintenance for 80 licenses. First thing your sales rep might say is - Why don’t you keep the 20 licenses (i.e. keep paying maintenance) and put them on the shelf. That way when you need them, you have them and don’t have to pay for upfront licensing again. You inform them that you really would like to give these licenses up and not pay for them anymore because you have no future need. This could go around and around a couple of times. Finally Oracle might tell you – OK, I’ll let you stop paying for the 20 licenses you are not using if you sign a software decommission letter and promise you are no longer using them (they have the right to do a software audit). However, your original 25% discount was based on a volume of 100 cpu licenses. If you want to change your contract to 80 licenses, we cannot give you the 25% discount because your volume has decreased. The best we can do is give you a 95% discount. This means that your yearly maintenance will be list price x quantity x 95% x 22% or $40,000 x 80 x .95 x .22 = $668800. So your maintenance costs will actually go up. Are you sure you want to do this? What this tactic buys Oracle is the fact that their yearly maintenance revenue does not decline, and that their install base does not decline either, even though not all software is in use. How do you protect yourself from this situation? The best answer seems to be making sure you have many small license contracts instead of few large ones. While Oracle has you cuffed if you try to reduce the quantity of a contract, they can do nothing if you wish to cancel an entire contract to reduce costs. Back when you needed the original 100 cpu licenses, if you arranged 10 contracts with 10 cpu licenses each, you have more flexibility in the long run. The downside is that you have to manage 10 contracts instead of one, but if you make sure they are all coterminous (all have the same end date), it is not that much more difficult to manage. Related Articles: How Oracle Licensing Differs CYA: Using Contracts to Protect Your Company