Once the ULA exits, Java becomes its own budget line unless it was named and certified into the perpetual estate. The number is set by whether Java is owned, the metric in force, and whether you keep, reduce, or replace it. Plan it, and it stops being a surprise.
By the Meridian advisory team · Ex Oracle licensing analysts · Updated June 2026
It depends on whether Java was a named product in the ULA. If Java was in scope and certified, you hold a perpetual entitlement for the quantity you converted, and your ongoing cost is the support against that owned position, which stays flat at the ULA level. If Java was outside the ULA, your Java position after exit is governed by whatever Java terms apply to your estate, and under the employee based model that can scale with total headcount into a significant standalone line. The first budgeting question, therefore, is not how much but whether you own it. Everything else follows from the answer, and the answer is in the contract you certified, not in an assumption carried over from the ULA years.
Budget Java from the question of ownership. Owned and certified means a flat support cost against a perpetual count. Outside the ULA means a live decision governed by the current metric. Measure the real footprint, model keep, reduce, and replace, and budget the chosen path with migration cost included. A Java number you planned holds; one you discover at renewal does not.
Work in order. First, establish ownership: was Java named and certified, or is it outside the perpetual estate. Second, measure the real Java footprint across the systems that run it, because the technical reality and a headcount based figure can imply very different numbers, and the gap usually favours the buyer. Third, confirm the metric that applies, since the basis decides how the cost is calculated. Then model three paths, keep, reduce, and replace, and budget the one you choose with its transition cost built in. This sequence turns Java from an open ended worry into a defined line you can defend in a budget conversation. The work is modest, and it is far cheaper than carrying an unexamined number.
| Path | What it means | When it fits |
|---|---|---|
| Keep | Maintain Oracle Java across the estate | Java is owned, or replacement is impractical near term |
| Reduce | Consolidate Java to the systems that need it | Usage is broader than it needs to be |
| Replace | Move to an alternative runtime | Applications support it and the metric cost is high |
Three decisions move the Java budget more than any negotiation. Whether Java is owned sets the floor: a certified perpetual position is a support line, while an out of scope position is a recurring decision. The metric in force sets the scale: an employee based basis ties the number to headcount, while a usage based or owned position ties it to the real footprint. And the keep, reduce, or replace choice sets the trajectory: reducing or replacing lowers the recurring cost at the price of a one time transition. Budgeting Java well means making these three choices explicitly rather than inheriting them, because the difference between an examined and an unexamined Java line is often the largest avoidable number in the post exit estate.
Consider an organisation, figures indicative only, that certified its ULA without Java in scope. The headcount based Java figure first presented was large. On measurement, real Java usage sat on a limited set of applications, two of which moved to an alternative runtime within a planned window. The budgeted Java line, after a modest one time migration, settled well below the original number, and it was a figure the finance team could defend rather than fear.
Often yes, and the routes are practical. Consolidating Java onto fewer systems, removing it where another runtime serves the application equally well, and right sizing to actual use all lower the number. The constraint is the contract metric and any support obligations, so each saving has to be modelled against the real terms rather than assumed into existence. A reduction planned deliberately, with the applications tested and the transition scheduled, holds far better than a reactive cut made under deadline. The discipline is the same one that governs the whole exit: measure first, model the options, and decide on the facts. Java responds to that approach as well as any other product in the estate.
Java sits inside a wider exit that also covers the database and its options. Read Java ULA renewal pressure in 2026 for how Java is handled at the exit itself, and database options in a mixed ULA for the other named products that share the certification. Our ULA exit strategy guide is the pillar that frames the full exit and the budget that follows it. When you want a read on your own Java position, the next step is a confidential assessment.
It depends on whether Java was a named product in the ULA. If Java was in scope and certified, you hold a perpetual entitlement and your cost is the ongoing support against it. If Java was outside the ULA, your Java position after exit is governed by whatever Java terms apply, which under the employee based model can scale with headcount and become a significant standalone line.
Start from whether Java is owned or not. Measure the real Java footprint, confirm the metric that applies, and model three paths: keep Oracle Java as is, reduce it to the systems that genuinely need it, or replace it with an alternative runtime. Budget the chosen path with the migration cost included, and revisit it as the estate changes.
Often yes. Consolidating Java onto fewer systems, removing it where another runtime serves, and right sizing to actual use can all lower the number. The constraint is the contract metric and any support obligations, so the savings have to be modelled against the real terms rather than assumed. Reductions planned deliberately hold better than reactive cuts.