The certify or renew decision is not a final quarter task. Started 18 months before your Oracle ULA expires, it becomes a structured programme that builds evidence, maximises the count, and turns the deadline into your leverage instead of Oracle's.
Most ULA holders treat the expiry date as the moment the work begins. By then the estate is whatever it is, the evidence is whatever was kept, and the only move left is to react to Oracle's process. The holders who do well start far earlier, because the certify or renew decision rewards preparation in a way few licensing decisions do. Eighteen months is the window that lets you build the deployment evidence, model both paths properly, reshape the estate while deployment still counts as unlimited, and walk into any renewal conversation with a number you trust. This article lays out that timeline phase by phase, so you can see what each period of the runway is for and what it costs you to skip it.
Start 18 months before the ULA expires. That runway is long enough to do the four things a strong outcome requires and short enough to stay urgent. You build the deployment inventory and evidence, you model certify against renew on real numbers, you reshape the estate while workloads still count as unlimited, and you set your position before Oracle sets the agenda. Start later and you lose the ability to change anything, which leaves you reacting to a deadline. The deadline favours whoever prepared for it, and on a ULA exit that is rarely the customer who began in the final quarter. The wider runway logic is set out in the 18 month ULA exit runway.
The 18 months divide into four working phases. The boundaries are approximate, and a longer or more complex estate can need more time, but the sequence holds: understand, model, reshape, then decide and execute.
The first phase is discovery. Read the contract properly, because the certify or renew decision is governed by clauses most holders have never examined closely: the counting metric, the customer and territory definitions, the cloud counting language, and any partitioning terms. At the same time, build the first deployment inventory across production, test, disaster recovery, virtualized, and cloud environments, so you know roughly what you have deployed and where. The output of this phase is a clear picture of two things: what your contract allows, and what your estate currently looks like. Without both, every later decision is a guess. The discovery work feeds directly into building the deployment inventory.
With the position understood, model certification against renewal on real numbers. The certification model is the perpetual entitlement you could declare today and its value. The renewal model is the cost of another term against the value of the unlimited rights it carries, read against your growth curve and your product roadmap. This is where the decision actually gets made on evidence rather than instinct, and where the cases for each path become visible. If growth is steep or product scope is widening, renewal may be clearly right, which is the subject of when renewing is clearly right. If the estate is broad and stable, certification usually wins. The gated model that structures this comparison is the Certify or Renew Decision Kit.
This is the phase only an early start makes possible, and the one a late start loses entirely. While the ULA is live, deployment is unlimited, so you can still change what the count will capture. If you are heading toward certification, this is when you maximise: stand up the disaster recovery, test, and non production instances you will genuinely use, repatriate cloud workloads that the contract will not count where they sit, and deploy deliberately to widen the certified number. If you are heading toward renewal, this is when you build the leverage and evidence that improve the terms. Either way, the estate stops being a fixed input and becomes something you shape with purpose. The maximization side of this phase is covered across our deployment material, and the cost of leaving it too late is real, because once the term ends the lever is gone.
The final phase commits the decision and executes it cleanly. If certifying, assemble the evidence file, verify the count before Oracle does, prepare the certification letter for the C level signature the contract requires, and submit within the window. If renewing, run the negotiation from the position the earlier phases built, knowing your certify alternative as your walk away. The work here is execution, not discovery, because the discovery was done months ago. A clean final phase is the dividend of an early start, and a chaotic one is the price of a late one.
An indicative timeline for a ULA expiring in 18 months: months 18 to 13 read the contract and build the first inventory; months 13 to 9 model certify against renew on the real numbers; months 9 to 4 reshape the estate, standing up genuine capacity and repatriating workloads that do not count where they sit; months 4 to 0 verify the count, prepare the letter, and either certify or negotiate the renewal from a known position. Compress this into a final quarter and the reshape phase disappears, which is usually where the largest value sits. The phases are indicative and a complex estate may need a longer runway.
A late start removes options in a fixed order. First you lose the reshape phase, so the estate that exists is the estate you certify, with no chance to maximise the count or move workloads so they count. Then you lose modelling depth, because there is no time to build the evidence the model needs, so the decision rests on rough numbers. Finally you lose negotiating position, because you are now reacting to Oracle's deadline rather than arriving with a settled view. Each lost phase shifts leverage toward Oracle. The decision mistakes that follow from a late start, and what they cost, are set out in the decision mistakes that cost millions.
The same expiry date is a threat to the unprepared and a tool for the prepared. When you have modelled both paths and know your certify alternative cold, a renewal conversation is one you can walk away from, which is the only stance that moves a renewal quote. When you have maximised the count and built the evidence, certification is a number you can defend rather than one Oracle can challenge. The deadline did not change. Your readiness for it did, and readiness is what converts a clock running against you into one running for you. The way an early position translates into renewal leverage is covered in our certify or renew guide.
If your ULA expires within the next 18 months, the timeline has already started whether you have or not. The cheapest move available today is to begin the understand phase: read the contract and build the first inventory, so the later phases have something to work with. Start with the certify or renew guide for the full decision framework, test your case against when renewing is clearly right, and work the numbers with the Certify or Renew Decision Kit. Because the value of the runway compounds with the time you give it, the single highest return action on a ULA exit is to start sooner than feels necessary.
Start 18 months before the ULA expires. That window lets you build the deployment evidence, model both paths, reshape the estate while it still counts, and enter any renewal conversation with a known position rather than reacting to Oracle's clock at the last minute.
A late start means the estate is fixed, the evidence is incomplete, and there is no time to maximise the count or improve the contract position. You end up reacting to a deadline, which is exactly the position that favours Oracle and weakens your certify or renew outcome.
We run the certify or renew timeline with you from month 18, so the deadline arrives as your leverage rather than Oracle's.