ULA exit: What to consider?

When considering the question of exiting an Oracle Unlimited License Agreement (ULA), we first need to understand what happens when we enter a ULA, and why we do so.

In many cases, the publisher is putting pressure on the customer, for example during an audit, and one way to resolve this situation may be to sign up for an ULA.

Great, unlimited usage, but...

Often, “unlimited” sounds like “out of control”. 

There are multiple types of ULA (e.g. with unlimited deployment for some products, but limited for some others), therefore summarizing the ULA as an “all you can eat” approach is not a good start. 

1. You need to precisely explain to your operations managers and DBAs 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 the word “unlimited”. Make sure you communicate your contract terms throughout the duration of the ULA.
2. When you do not count anymore, you do not know whether you are using 100, 1,000 or 10,000 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 to have a margin of appreciation of +500 or -500 CPU licenses… because the financial cost will immediately be huge.
3. In normal circumstances, you would pay close attention to the contamination effect when you use Oracle DB on IBM LPM or VMWare. With a ULA, you do not really take care about it anymore. But again, when you exit the ULA, the virtualization architecture strategy you have developed may not be compatible anymore, unless you freeze everything at the day of the ULA exit and do not make any new moves in the future, which is not realistic.

For these reasons, you need to measure your license consumption during the ULA period, so you are ready to make decisions at the right time.

When is 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. But it is not easy to know precisely which products you are going to use and to plan for a sharp stop in deployments after 2, 3 or 5 years.

If you managed to measure your license consumption continually, you are ready to exit the ULA, and it will be a well-reasoned and informed decision.

And sometimes, you have such a limited choice that it rushes your decision to exit the ULA even if this was not necessarily what you had planned. Oracle will always encourage you to renew the ULA, contract period after contract period. Yet, at the end of each ULA, the new fees can be much higher than what you expected. That can be a trigger to accelerate and finish your 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?

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 use, it will be considered fraud. Oracle explicitly asks you to warrant what you use through the Global Deployment Report spreadsheet. Over-declaring is just not an option.

Conversely, if you under-declare (because some databases have been forgotten, or you are not sure whether options are really activated and used), you take the risk that Oracle will accept your declaration. And immediately afterwards, you will be granted with an allocation of licenses which is lower than what you need, and you will not be compliant. Can you work this out with Oracle afterwards? Unfortunately, no: Oracle is very strict with its declarations, and all licenses that have not been declared cannot be retrieved afterwards.

For these reasons, there is no other choice than being 100% accurate when you produce your declaration. It is not an easy process, and you need to have the appropriate means to do a good job.

Back to standard mode, any risk?

In theory, standard mode is not more difficult than the process you followed before the ULA. But the reality is different. First, you may have entered the ULA because your company was not rigorous enough in managing your Oracle deployments. OK, let’s learn from the mistakes of the past and make sure not to repeat them.

Moreover, after a 3 years or longer ULA period, another difficulty is starting the inventory process on a regular basis. It is like resuming training after a break!

​

How SamBox.io can help mitigate those risks

SamBox.io enables customers to insert 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 assets.

SamBox.io will verify the data quality, and make sure everything is correct. Should there be any 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 the tool the VMWare contamination effect for example; all licensing rules, market practices, and auditor 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.

By Damien Juillard, June 10, 2020

Read the full article