The ULA Exit Field Guide

Every Oracle Unlimited License Agreement ends with a single, permanent act. You certify the quantities deployed during the term into a perpetual entitlement, sign a letter, and the unlimited right is gone for good. The number on that letter is the number you live with. It is the difference between a certification that captures the full value of the agreement and one that quietly leaves seven figures of entitlement unclaimed. The gap between those two outcomes is almost always time.

We are an independent advisory. We are not a reseller, we hold no Oracle quota, and we sit on the buyer side of the table. This field guide is the runway we run with clients, written so that an IT asset manager, a procurement lead, or an enterprise architect can follow it without us. It assumes roughly eighteen months from notice to certification, which is the window in which the work can be done properly. Every figure here is indicative, and because the rules that decide your count are set by your specific agreement, the answer in your case will turn on your exact contract language.

What is the ULA exit runway, and why eighteen months?

The exit runway is the planned sequence of work that turns an approaching ULA expiry into a defensible certification. Eighteen months is the figure we use because the tasks have a natural order and several of them take real calendar time. You cannot maximize a count you have not measured, you cannot measure an estate you have not mapped, and you cannot move workloads to make cloud deployments count without leaving time for the clock those moves depend on. Compress the runway and you lose options, not just comfort.

The reason most teams under certify is not that they lack the data. It is that they start the count in the final quarter, when there is no time left to investigate the environments that hold the most value, no time to repatriate or relocate cloud workloads so they qualify, and no time to document a clean virtualization position. The runway exists to put each of those decisions in the quarter where it can still change the outcome.

There is a second reason to start early that has nothing to do with counting. An exit done well needs internal alignment, and alignment takes time to build. Finance has to understand why a large certified number is free value rather than a cost. The executive who will sign the letter has to be brought along so the signature is informed rather than rushed. Legal has to read the customer definition and the territory clause. Infrastructure has to be ready to move workloads if cloud counting requires it. None of these conversations happen quickly in a large organisation, and each of them is easier when there are months in hand rather than weeks. The runway is as much a plan for the people as it is for the numbers.

The quarter by quarter runway at a glance

The table below sets out the runway as four working quarters with a buffer. The dates are indicative and you should anchor them to your own expiry, but the order is fixed, because each quarter produces the input the next one needs.

For the runway in narrative form, with the milestones broken down further, read the 18 month ULA exit runway. The sections that follow walk each window in turn.

Quarters one and two: read the contract and measure the estate

The first quarter is reading, not counting. The agreement decides everything that follows, and the clauses that matter are the certification rights, the named product list, the customer definition, the territory clause, the cloud counting language, and any cap on the unlimited right. Each of these can add or remove value from the final number, and a count built before the contract is understood is a count built on assumptions. Read first, measure second.

The second quarter is the measurement itself. This is where you build a defensible count of every named product across every environment the agreement allows you to claim: production, test, development, and disaster recovery deployed within the term. The output is not a total. It is an inventory tied to named hosts, with the discovery tool output and the processor methodology behind each number. The processor count uses physical cores multiplied by the core factor for each processor type, and the arithmetic has to be reproducible from the evidence, because the evidence is what defends the count later.

Quarter three: how do you maximize the count?

Maximization is the quarter where the value is made. Certified counts often land 1.5 to 2.5 times higher than a first estimate once cloud, disaster recovery, and non production deployments are handled properly. That multiple is indicative and depends entirely on your estate, but the mechanism is consistent: a first count captures the obvious production footprint, and the maximization work captures everything else the agreement entitles you to certify. The table below sets out the main levers.

For the maximization work in full, including how each environment qualifies, read the deployment maximization playbook. The discipline throughout is that every claimed deployment must be evidenced. A larger number that cannot be defended is not value, it is exposure, and the point of maximization is to claim everything you are entitled to and can prove.

Does Named User Plus or a capped ULA change the runway?

Most ULAs are counted on a processor basis, but some named products are licensed by Named User Plus, and where that metric applies the runway has to account for it. Named User Plus counts the individuals and devices authorised to use the product, subject to per processor minimums, and the measurement discipline is different from a processor count. The estate work in the second quarter has to identify which products fall under which metric, because a count that applies the wrong metric is neither defensible nor maximised. Where both metrics appear in one agreement, each product is measured on its own terms.

The structure of the agreement also shapes the exit. A standard ULA grants an unlimited right that converts to a perpetual entitlement at certification. A capped ULA limits that unlimited right, so the certified count cannot exceed the cap regardless of deployment, and the runway has to model the cap as a ceiling on value. A hybrid ULA folds cloud rights into the agreement, which changes how cloud deployments are treated at exit and can remove some of the cloud counting friction described below. Reading which of these you hold is part of the first quarter contract work, because each changes what maximization can achieve.

A perpetual ULA, or PULA, sits outside this runway entirely, because it has no certification exit at all. If your agreement is a PULA, the unlimited right does not convert and then end, it simply continues, and the levers that rebuild buyer leverage are different ones. Confirm which agreement you hold before you plan an exit, because planning a certification for an agreement that has none is wasted effort. None of this is a reason to delay. It is a reason to read the agreement early, so that the measurement and maximization quarters apply the right metric to the right product and model any cap before time is spent chasing value the contract does not allow you to claim.

A worked example: where the count came from

Consider an anonymized example. A European financial services group approached its database ULA expiry with a first estimate built on its production footprint alone. The figures below are indicative and illustrate the maximization mechanics, not any specific client.

The first estimate of 240 processor licenses captured only the production databases the team thought of as the ULA. The maximization quarter added the disaster recovery standby instances, the test and development environments, and the cloud deployments that met the continuous running test in the contract, each backed by the evidence to support it. The defensible total reached 448, close to 1.9 times the first estimate, comfortably inside the 1.5 to 2.5 times range the runway commonly produces. None of the additional value required new deployment. It was already running and already entitled to be certified. It simply had not been counted, because the first estimate stopped at the obvious footprint.

The multiple is indicative and would be different for a different estate. What is consistent is the source of the value: the environments beyond production that a hurried count overlooks. A team that certified 240 would have left more than two hundred processor licenses of permanent entitlement unclaimed, at no saving, because support stays flat regardless of the certified count. The runway exists to find that gap while there is still time to evidence it.

How do cloud and VMware change the count?

Cloud and virtualization are the two areas where a count can be quietly lost, and the fourth quarter is where they are settled. Cloud counting is contract specific. Many agreements require deployments in a public cloud to run for 365 continuous days to count toward the certification baseline, some exclude public cloud entirely, and many are simply silent on a given provider. Silence is not inclusion. Where the contract does not let a cloud deployment count, the move is to repatriate the workload on premises, or relocate it, in time for it to qualify, which is exactly why this cannot be left to the final weeks.

Virtualization works the other way at exit. Under Oracle's partitioning stance, soft partitioning does not limit the scope of what must be licensed, which during a ULA exit can work in your favour: a broad virtualization footprint can support a larger defensible count. The same rule reverses after certification, when an unbounded cluster becomes audit exposure rather than entitlement. So the work in this quarter is twofold: claim the footprint you are entitled to before the signature, and then draw and document the clean boundary that protects you afterward. Both depend on the partitioning language and the facts of your estate.

Quarter four: build the evidence file and certify

The final quarter turns the count into a defensible certification. The evidence file is the documented basis for every number you declare: the server and instance inventory, the original discovery tool output, the processor methodology with cores and core factors, the virtualization map, and the reconciliation to the contract's product list and scope. Built well, the file does two jobs at once. It supports the certification letter today, and it is your defense against any audit that follows in the next two years.

Certification itself has no fee, and support continues at the ULA level regardless of the number you certify, so a larger defensible count is free perpetual value rather than a higher cost. This is the single fact that most often gets the exit wrong. Teams fear that certifying a high number will be punished with a larger support invoice, so they under count out of caution, and they leave permanent entitlement on the table for a saving that does not exist. Support is set at the ULA level and stays there. Within the bounds of what you can evidence, the largest defensible number is always the right number.

With the file complete, the certification letter is drafted, the count is reconciled one final time, and the letter goes for the executive signature the contract typically requires. That signature is not a formality. It is a declaration the business is making to the vendor, and the person signing it is entitled to see the evidence behind every number before they do. A letter that an executive can sign with confidence is a letter built on a file they have been shown, which is another reason the file is assembled in this quarter rather than improvised at the deadline. For the mechanics of the certification step in full, read the Oracle ULA certification guide.

How does corporate change affect the ULA clock?

Corporate change is the variable that can derail an otherwise clean runway, and it has to be managed against the ULA clock rather than discovered at the end. Mergers, acquisitions, divestitures, and entity restructures all interact with the customer definition and the territory clause, which decide who is covered by the agreement and where. A deployment in an entity or a territory outside the agreed scope is not entitlement, it is a remediation demand waiting to surface, and the timing of a corporate event relative to the term can change whether an estate is inside or outside scope.

The practical rule is to surface any corporate change early and test it against the customer definition before it reaches the certification. An acquisition that closes during the term may bring an estate that can be folded in on favourable terms, or one that sits outside scope and must be handled separately. A divestiture may remove deployment you were planning to certify. None of these are problems if they are modelled into the runway with months to spare, and all of them are problems if they arrive in the final quarter. Where the interaction is unclear, it depends on the exact language of the customer definition, and that reading should happen alongside the contract work in the first quarter.

The territory clause deserves the same early attention. A group that has grown internationally during the term may be running Oracle products in territories the original agreement never contemplated, and a deployment in a territory outside scope is not entitlement, it is exposure. The fix is rarely complicated once it is seen in time. Workloads can be consolidated into covered territories, or the scope question can be raised in the certification rather than discovered in a later audit. What turns a manageable point into an expensive one is finding it late, when there is no time left to move anything. Read the customer and territory definitions together, map your real estate against both, and resolve any mismatch while the runway still has room.

What if you have already started late?

Not every team has eighteen months, and a shorter runway is not a lost cause. The order of work stays the same, but the choices narrow. With twelve months, the contract read and the measurement still fit, and most of the maximization is reachable, but the cloud repatriation moves that depend on a continuous running clock may no longer be available. With six months, the priority is a clean, defensible count of what already qualifies, a complete evidence file, and a careful reconciliation, accepting that some maximization value tied to relocations is out of reach.

The worst outcome is to let a short runway push the team into certifying a hurried number with thin evidence, or into a panic renewal to avoid the question entirely. Even on a compressed timeline, the work that protects value is the same work: understand the contract, measure honestly, claim everything you can evidence, and document it. Start from wherever you are, in the order the runway sets, and capture the value that is still in reach.

One discipline matters more than any other when time is short: protect the evidence even as you move quickly. A count assembled in six weeks is still defensible if the inventory is dated, the tool output is kept, and the methodology is written down, and it is worthless if it is a spreadsheet of totals with nothing behind it. The temptation under deadline pressure is to skip the documentation and trust the number. That is precisely the number an audit will test in the two years that follow. If you can do only one thing well on a short runway, make it the evidence, because the evidence is what carries the certification through whatever comes after it.

The Meridian exit method

We run the exit as a repeatable sequence, and the order is the point, because the leverage and the value are both created by doing the work in the right quarter rather than the last one.

1. Read the contract first. Map certification rights, the product list, the customer and territory definitions, cloud language, and any cap before counting anything.
2. Measure the estate honestly. Build a defensible count across production, test, development, and disaster recovery, tied to named hosts and the tool output.
3. Maximize the defensible count. Capture the cloud, disaster recovery, non production, and virtualization value the agreement entitles you to claim and evidence.
4. Settle cloud and virtualization. Position cloud workloads to count and draw a clean virtualization boundary for after the exit.
5. Manage corporate change. Test any merger, acquisition, or restructure against the customer definition and the ULA clock.
6. Build the evidence file. Assemble the inventory, tool output, methodology, virtualization map, and contract reconciliation behind every number.
7. Certify the number you can defend. Draft the letter, reconcile once more, and take it for the executive signature.

The readiness checklist

Use this to test where you stand against the runway. Every line you can tick is value protected. Every line you cannot is a task for the quarter you are in.

1. Contract read with certification rights, product list, customer and territory definitions, cloud language, and cap mapped.
2. Estate measured across production, test, development, and disaster recovery, tied to named hosts.
3. Discovery method chosen deliberately, with the LMS script decision made on its merits.
4. Maximization complete across cloud, disaster recovery, non production, and virtualization, all evidenced.
5. Cloud positioned so eligible workloads count, with the continuous running test understood.
6. Virtualization boundary claimed for the exit and documented for afterward.
7. Corporate change tested against the customer definition and the ULA clock.
8. Evidence file assembled and the certification letter ready for signature with time to spare.

The next step

A ULA exit done well captures the full value of an agreement you have already paid for, and the way to do it well is to start early and work the runway in order. If your expiry is within eighteen months, the time to begin the contract read and the measurement is now. If you would like the runway run with you, on your contract and your estate, that is the work we do. For the wider picture, read the Oracle ULA certification guide and the deployment maximization playbook.