The certified count is decided long before you sign the certification letter. The 18 months before your Oracle ULA expires are where the value is won or lost. This is the runway we run, month by month, so you certify a number that is complete, defensible, and yours.
Begin at least 12 to 18 months before the ULA end date. The moves that raise the certified count and harden the evidence file take time to execute, and several of them only count if they finish well before the certification window opens. An exit left to the final quarter certifies whatever can be proven in a hurry, which is almost always less than the estate is truly worth.
Certification is not an event you attend at the end. It is the outcome of decisions you make across the final 18 months. Run the runway and the letter signs itself.
The first phase is measurement and contract reading. You cannot plan an exit you cannot see. In this window we build an independent effective license position across every product, option, and pack in scope, and we read the agreement for the clauses that decide what counts.
Inventory production, test, development, and disaster recovery instances deployed within the term. Capture processor counts with the correct core factors and Named User Plus where it applies. The aim is an honest picture of what you actually run, not a number shaped to reassure anyone.
Three areas decide more than any other: the cloud counting language, the partitioning treatment for virtualized estates, and the customer definition and territory scope. Each of these can move the certifiable count by a wide margin, so they are read first and read closely.
This is the phase where time becomes the constraint. Anything that depends on a clock has to start here, because it cannot be rushed at the end.
Cloud counting is contract specific. Many contracts require a deployment in AWS or Azure to run 365 continuous days to count toward the certification baseline, some exclude public cloud entirely, and many are silent on Google Cloud, where silence is not inclusion. Where cloud will not count, workloads can be repatriated on premises or moved to OCI so they do count. None of this works if it starts in the last quarter, because the 365 day clock will not have run.
Under Oracle's partitioning stance, soft partitioning does not limit scope, so an entire VMware cluster can be swept into the count. In a maximization context that same rule can work for you, because deployment on a large cluster supports a large count. The decision to isolate, to consolidate, or to spread depends on whether you are defending against exposure or building the count, and it needs documenting either way.
The number is only as strong as the evidence behind it. In this phase the deployment picture is frozen and the proof is assembled: server lists, tool output, methodology documentation, and a clear record of how every counted instance was deployed within the term. The evidence file matters as much as the count, because it is what defends the certified position in any audit that follows.
This is also the window to decide on Oracle LMS scripts. Running them is a choice, not an obligation, and the decision deserves analysis rather than a reflex. Whichever way you go, the methodology should be your own and fully documented.
The final phase reconciles the maximized count to the agreement, prepares the certification letter that a C level executive will sign, and manages the exchange with Oracle through to a clean close. Then the work shifts to protection, because audit risk rises in the first two years after certification and the evidence file is the defense.
A manufacturer with a database ULA started 16 months out. Early measurement showed roughly a third of growth had landed in AWS under a 365 day continuous run clause that would not complete before exit. Repatriating part of that estate to on premises and OCI at month 12 let the clock finish in time, and the certified count landed well above the first estimate. Started at month three, none of that would have been possible. Figures are indicative and depend on the specific contract language.
Every milestone above hinges on what your agreement actually says. A contract that counts cloud freely compresses the runway, while one that demands a 365 day continuous run stretches it. In ULA work the answer almost always depends on the specific wording, so the runway is a framework to adapt, not a fixed calendar to copy.
If your ULA expires within the next 18 months, the clock is already the most valuable thing you have. Start with the Oracle ULA certification guide for the full picture, then read when a ULA is the right deal and the Oracle ULA certification guide for 2026.
Start at least 12 to 18 months before the ULA end date. Cloud counting clauses, deployment moves, and evidence gathering all take real time, and several of them only count if they are complete well before the certification window opens.
Resolving cloud and virtualization counting. Many contracts require an AWS or Azure deployment to run 365 continuous days to count, so any repatriation or move to OCI has to happen early enough for the clock to complete before exit.
You forfeit the moves that depend on time. You cannot start a 365 day cloud clock, you cannot reshape virtualization cleanly, and you certify whatever you can prove in a rush. The count lands lower and the evidence file is weaker, which raises later audit risk.
Book a confidential assessment and we will map your exit runway to your contract and your estate, so every month before expiry is working for the certified count.