A strong ULA exit is the product of a plan that spans the term, not a scramble in the final quarter. Five phases turn an Oracle ULA into a strong certified position and a lower ongoing bill. The value is in the sequence, because each phase produces the inputs the next one needs.
By the Meridian advisory team · Ex Oracle licensing analysts · Updated June 2026
A clean ULA exit is planned over years, not weeks. The roadmap runs in five phases: read the contract and fix scope, inventory every deployment, maximize genuine deployment, certify the strongest defensible position, then reduce ongoing cost. Start at least eighteen months out, because the highest value moves all need time to take effect and to be evidenced.
Treat the whole term as the planning horizon, and at the very least begin eighteen months before expiry. The reason is structural rather than cautious. The moves that change the outcome of a certification, fixing scope, growing deployment of valuable products, and sequencing migrations so workloads count, all take real time to implement and, just as importantly, to evidence. A deployment that appears the week before certification is hard to defend. A deployment established a year earlier, running as a genuine workload with a clean evidence trail, is straightforward. Starting early does not merely reduce stress; it expands the set of options available to you. A plan that begins in the final quarter is confined to whatever the estate already happens to be, which means the certification becomes a measurement exercise rather than a strategy. A plan that begins with eighteen months or more turns the term into a runway for building the position you want to certify.
The exit outcome is decided by when you start, not how hard you work at the end. Begin eighteen months out at minimum, and run five phases in order: contract and scope, inventory, maximization, certification, cost reduction. Each phase feeds the next. Started early, the term becomes a runway to build the position you certify. Started late, certification is just a snapshot of whatever you already have.
The roadmap below is the spine of a deliberate exit. It is written as five phases, but in practice they overlap, and the early phases stay live throughout. The discipline is to make sure each one is genuinely underway before the next depends on it.
Everything starts with the agreement as it is actually written. The customer definition decides which entities may deploy. The territory clause, where present, decides where deployment counts. The cloud counting language decides whether public cloud helps or hurts. The product list decides what is in play. Read these first, because they set the boundaries inside which every later move must operate, and because corporate change during the term may already have pushed deployments outside them. Fixing scope early, while there is time to bring entities in or repatriate workloads, prevents the scope sweep that turns deployment into a remediation bill at exit.
You cannot certify, maximize, or migrate what you have not measured. Build a complete inventory of every Oracle deployment mapped to a product, a legal entity, a location, and an environment, covering production, test, and disaster recovery. Include cloud and virtualised estates, where counting rules are most contested. This inventory is the single source of truth for the rest of the roadmap, and assembling it early means later decisions rest on facts rather than estimates. It is also the foundation of the evidence file that will defend your certified counts in an audit afterward.
With scope fixed and the estate measured, the question becomes how high a defensible certified position you can build. Certified counts often land well above first expectations, an indicative range of one and a half to two and a half times is common once cloud, disaster recovery, and non production deployments are handled correctly, and once virtualisation and counting rules are applied in your favour rather than against you. Maximization means deploying valuable products you genuinely intend to run, on infrastructure you actually use, and evidencing them properly. It never means standing up empty instances to inflate a number, which collapses under audit. This is the phase where time pays the most, because a workload needs to be real, operated, and documented before it can be certified with confidence.
Certification is the fixed point that converts deployment into perpetual entitlement. There is no fee for it, and support stays flat at the ULA level regardless of how high the certified number lands, so a higher defensible count is free value. The certification letter typically requires a senior executive to sign, which makes the evidence behind every number a governance matter, not just a technical one. Certify the full position your inventory and evidence support, declare it cleanly, and close out the term with a documented basis for every figure. This is the moment the asset is created, and it is irreversible, which is why the three phases before it exist to make it as strong as it honestly can be.
The asset is banked; now the work shifts to the bill you keep paying. After certification, migrations such as a move to PostgreSQL can retire Oracle footprint, and OCI moves can reshape where workloads run. The saving is realised only when you formally terminate support on the licenses you no longer need, and that step carries repricing mechanics that reward careful grouping and sequencing. This phase runs for years, governed by the support clock rather than the term, and it is where a strong certification turns into durable savings rather than a static entitlement sitting on a shelf.
| Phase | Typical window | Output it produces |
|---|---|---|
| Contract and scope | 18 months or more out | Boundaries and a fixed scope |
| Inventory | 12 to 18 months out | The single source of truth |
| Maximization | 6 to 18 months out | A higher defensible position |
| Certification | At expiry | Perpetual entitlement, evidenced |
| Cost reduction | After certification, ongoing | Lower support, retired footprint |
Consider a manufacturer, figures and facts indicative only, that began its exit roadmap two years before expiry. Phase one surfaced a reorganised entity outside scope, fixed in time to count. Phase two built a full inventory that revealed cloud and disaster recovery deployments nobody had counted. Phase three grew genuine deployment of high value database options. Phase four certified a position well above the figure first assumed, at no fee and with support held flat. Phase five then retired Oracle systematically and modelled support termination to limit repricing. The same estate certified late, with no roadmap, would have produced a far smaller asset and a higher running cost.
Yes, with a clear caveat. With twelve months you can still review the contract, fix what scope issues are fixable, build a proper inventory, evidence your deployments well, and certify a strong and defensible position. That protects the entitlement you already hold, which is the larger part of the value for many organisations. What narrows is the room for the moves that need time to mature: maximization that depends on establishing and operating new workloads, and migrations timed so that workloads count at certification. The honest message is not that a late start is hopeless, but that earlier is materially better, because the option set is widest when the clock has the most time left on it. Whatever the time remaining, the order of the phases stays the same.
Each phase has its own depth. Read ULA to OCI when the math works for the maximization move that uses cloud counting in your favour, and PostgreSQL migration and the ULA clock for the cost reduction phase done in the right order. Our ULA exit strategy guide is the pillar that frames the whole roadmap. To build a roadmap fitted to your term and your estate, the next step is a confidential assessment.
Begin at least eighteen months before the term ends, and ideally treat the whole term as the planning horizon. The highest value moves, contract review, deployment maximization, and migration sequencing, all need time to take effect and to be evidenced. A plan started in the final quarter is limited to whatever the estate already happens to be, with no room to improve the position.
A workable roadmap runs in five phases: read the contract and fix scope, inventory every deployment, maximize genuine deployment of valuable products, certify the strongest defensible position, and reduce ongoing cost through migration and support termination afterward. Each phase produces the inputs the next one needs, which is why the order matters as much as the content.
Yes, but the available moves narrow. With a year you can still review the contract, inventory the estate, evidence the position properly, and certify well, which protects the entitlement you already have. What shrinks is the room for maximization that needs time to establish, and for migrations timed to count. The earlier the start, the larger the set of options.