So you have a ULA… what happens if you decide to exit?

Something of an ‘all you can eat’ licensing buffet, the Unlimited License Agreement—the ULA—lets you selectively use as much of an agreed Oracle product as you need. It is ‘selective’ in that you must define and agree with Oracle which products are to be included.  In addition, you and Oracle agree on a metric and a purchase cost for the license set, which typically includes Oracle Database and associated options. 

Sounds good doesn’t it? No more constraints, no more worries about who has deployed what, and where… So…

What’s the catch?

The ‘catch’ is in the continuing uplift to support costs. This type of agreement comes with a Total Support Cost clause that specifies a percentage uplift year on year. So costs keep rising throughout the agreement term.

Typically, these agreements last for three to five years. At the end of the agreement, you can renew and continue as before, or you can ’certify’ your usage and exit. If you choose to renew straight into a new ULA, there may still be a process to go through. This includes a new contract,  which requires careful analysis to ensure it still meets your business needs.

If you choose to exit, the Total Support Cost will not reduce. This creates something of a dilemma because you now have to ensure your usage (deployments certified) is adequate for the support fees you’re paying.

Let’s look at a simple example using current list prices:

• You signed a ULA for Oracle Database Enterprise Edition (DBEE) in 2021, and it’s now coming  up for renewal. 
• You decide to certify your usage and exit the contract with full use licensing for the products you’re consuming.
• You’re paying $2m in total support costs. 

So the challenge here will be matching your deployment to the amount of support being paid. At a DBEE support list price of $10,450 per processor, to make the books balance, you should have in excess of 190 licensable processors of Oracle Database deployed. If you have fewer than this, you will be paying more than the list price in support costs and ROI is then questionable.

The top five challenges when exiting a ULA

In our experience, these five pop up time and again.

1. Discovery

When you’ve had carte blanche for years to deploy products, control and tracking often goes out the window. This makes it difficult to locate all the deployments and there’s no silver bullet to finding them. Even discovery tools need a starting point!

The best approach is to map applications and ask questions: do you have test / development / UAT environments? What about backup and disaster recovery? This will give you a high level view and starting point.

2. Ownership

Likewise, applications may not have clear owners. Establish application owners who have a vested interest in ensuring nothing breaks.

Ask questions about the application:

• Is it still required?
• Is it critical?
• How long is it needed for?
• Will it be decommissioned and if so, when?
• If the database that supports it disappears, how does that effect the application?

3. Time

I can’t stress enough how important it is to start early. Oracle likes to see at least 90 days’ usage if you’re going to certify. So it’s crucial to start the discovery process at least six months before the exit date so that you can provide accurate proof of usage. Don’t underestimate the time an exit takes. The bigger the support fees, the more time you’ll need.

4. Compliance

You need to ensure your deployments match the products on the ULA exactly and any non-compliance should be addressed early. You can assess this through an external Software Asset Management (SAM) service or through internal checks. It needs to be evidence Oracle will accept, like information from DBA Features Usage tables.

5. Team Accountability

Decide who performs the major tasks and put a timeframe in place. And document everything! For example:

• The DBA who finds database deployments for a specific application and confirms what’s in use and what isn’t
• The application owner who confirms what it’s used for and how critical it is
• The architect who confirms if it has links to other applications or products or businesses

Things to keep in mind when planning your exit

Future proofing

Ideally, you’ll exit with licenses in hand for future deployments. So think about the deployments you have now, what can be switched off or reconfigured in the future and how those licenses could be re-harvested for other projects.  

For example, if you certify on a virtualized platform, think about how you could reconfigure and reduce that license requirement to give you additional ‘free’ licenses in the future.

Disaster Recovery

Don’t forget your standby environments when you calculate your current usage. These will likely require a full use license after certification.

Who will use the products?

The ULA specified which businesses could use the products—is this still accurate?  For your new agreement, reflect any new acquisitions or divestments. Ensure you have a world-wide usage clause to cover all locations.

Are you still using all the products in the ULA?

Ensure you only include products you intend to use and communicate that to the business so that everyone is clear what products remain available for use.

For Oracle Expertise. Ask Inoapps.

If you need to get to the bottom of your ULA deployments before an exit, the Oracle experts at Inoapps are here to help. As members of the Joint Partner Engagement program and the Oracle Partner SAM Service, we can help you regain visibility, take control and expand your Oracle licensing knowledge.

You can find out more about our services on our Oracle Licensing and Subscription Services web page.