To better understand the stake of ULA exit, we actually first need to understand what happens when we enter into ULA, and why we enter into ULA.
In many cases, the SW Publisher is putting a high pressure on the customer (e.g. during an audit), and one manner to sort out from this situation is sometimes to sign for an ULA.
Great, unlimited use…. BUT
…very often, unlimited sounds like no more control.
There are multiple type of ULA (e.g. with unlimited deployment for some products, but limited for some others) or summarizing the ULA to “all you can eat” approach is not good start.
- You need to precisely explain to your operations managers and DBA what they are authorized to deploy and activate, and what they are not. It is too easy to have a selective hearing and forget everything but unlimited. Make sure to communicate on contract terms all along the ULA duration.
- When you do not count anymore, you do not know whether you use 100 or 1000 or 10000 CPU licenses. No impact during ULA? Indeed, that could be the case, but if some day you exit the ULA, it will not be possible anymore to have a margin of appreciation of +500 or -500 CPU licenses… because financial cost will immediately be huge.
- Contamination effect when you use Oracle DB on IBM LPM or VMWare are something you pay attention all the time. Here, you do not really take care about it anymore…. but again, when you exit the ULA, the virtualization architecture strategy and principles you have built may not be compatible anymore… unless your freeze everything at the day of the ULA exit and do not make any new move in the future… which is not realistic !
It is then obvious to continue to measure its license consumption during the ULA period, in order to be ready to make decisions when it’s time to.
When is it the best time to exit an ULA?
ULA is the perfect contract vehicle if you are going to make an intensive usage of Oracle products during a limited and known period of time. While writing this sentence, I need to insist on the fact that it is not that easy to know precisely which type of products you are going to use (and which others, you won’t), and determine 2, 3 or 5 years in advance a sharp stop into the deployments.
If you managed to respect these conditions, and as previously mentioned, you continued to measure your license consumption all the time, yes, you are ready to exit the ULA, and it will be a good reasoned and informed decision.
And sometimes, you have such a limited choice that it rushes your decision to exit the ULA even if it was not necessarily in your plans. Actually, Oracle will always encourage you to renew the ULA, contract period after contract period. Yet, at the end of each ULA, new investments claimed by Oracle and new associated recurring fees can be much higher than what you expected. That can be a trigger to accelerate and finish the project before the ULA termination. In any case, start your negotiation asap, and anticipate as much as possible.
I decide to exit – what should I pay attention to ?
So when it’s time for you to exit the ULA, you have no other choice than being 100% accurate in your declaration.
Indeed, the declaration of licenses you currently use will become your entitlement. If you declare more than what you actually use, it will be considered as a fraud. Oracle explicitely asks you to warrant what you use through the Global Deployment Report spreadsheet. Over-declaring is just not an option.
At the opposite, if you under-declare (because some databases have simply been forgotten in a specific environment, or you are not sure whether options are really activated and used or not), well you take the risk that Oracle will accept your declaration. And immediatly after, you will be granted with the equivalent number of licenses…. which is then lower than what you need -> there it is, you are not compliant. Can we deal such missing with Oracle afterwards ? Unfortunately not; the editor is very strict with the declaration and all licenses that have not been declared cannot be retrieved afterwards. Concretely, you were compliant on May the 31st, and you are at risk on June the 1st.
For these 2 reasons, there is no other choice than being 100% accurate when you produce your declaration. It is not necessarily an easy process, and you need to have the appropriate means to do a good job.
Back to standard mode, any risk?
Once you are out of the ULA, you are back to the former and standard mode where you need to pay for your licenses everytime you need it and intend to install new Oracle SW (or change your architecture).
Theoretically, it is not a more difficult process than what it was before the ULA. But reality is different. First, keep in mind that you may have entered into ULA because your company was not rigorous enough in the control of your Oracle deployments. OK, that happens in the past, so let’s learn from the mistakes of the past and make sure not to do them again.
Moreover, after a 3 years or longer ULA period, another difficulty is to start over the inventory process on a regular basis. Not that easy considering what I wrote above, it is like resuming training after a break !
How SamBox.io can help mitigating those risks
SamBox.io enables customers to have a full end-to-end Oracle SAM process into the platform, in a few clicks.
After launching the LMS scripts for instance, SamBox.io will automatically ingest the raw outputs, and determine what is running on which server, with all the detailed underlying infrastructure asset.
SamBox.io will verify the data quality, and make sure everything is correct. Should there be some errors or discrepancies, SamBox.io will tag them and lower the calculation confidence index, so that you do not get approximate results.
Finally, SamBox.io will make an optimal compliance calculation. No need to set any rules, teach to the tool what it the VMWare contamination effect or something -> all the licensing rules, market practices, and auditors practices have been embedded by default in our engine.
A 3 step process, 3 clicks, and a few minutes to get reassured and make smart decisions.