The saving from an OpenJDK migration is the distance between subscribing the whole estate and subscribing only the residual you cannot move. This guide gives you a simple formula, a worked example, and the payback shape you need to size that prize.
Since January 2023 Oracle has priced Java SE on the Universal Subscription, a per employee metric. List pricing runs from 5.25 to 15.00 dollars per employee per month, stepping down through volume bands, with small estates near the 15.00 ceiling and the largest estates near the 5.25 floor. The metric counts every full time and part time employee, every contractor, and every temporary worker, regardless of who uses Java. So the first figure to write down is simple. Take your counted population, multiply by the indicative rate for your band, and multiply by twelve. That is the all estate figure Oracle would like to charge.
For a population of 10,000 at an indicative mid band rate of 8.25 dollars, the all estate figure is roughly 990,000 dollars a year. That number is the ceiling, not the destiny. The saving from a migration is the distance between that ceiling and the much smaller figure you pay once most of the estate has moved. Before you can negotiate that distance, you have to estimate it, and a good estimate is the difference between a vague hope of savings and a number your finance team will fund a project against.
An OpenJDK migration competes for budget and attention with every other initiative in the organization. A credible savings estimate is what wins it that budget. It tells the chief financial officer how much avoidable spend sits inside the Oracle Java line, it tells the chief information officer how big the program needs to be, and it tells procurement what a defended renewal should look like. Without an estimate you are negotiating against Oracle's number with nothing of your own. With one, you control the anchor.
The estimate also tells you something important about urgency. If the avoidable spend is large and the next renewal or true up is close, the migration is a priority this quarter. If the spend is modest and the renewal is far off, you have room to phase the work calmly. Either way, the estimate turns a feeling into a plan.
A migration saving has three moving parts: the population that stays in the count, the rate band you land in, and the size of the residual Oracle Java need. The first two are largely fixed in the short term, so the lever you control is the residual. Reduce the workloads that require an Oracle entitlement and you reduce the envelope you must subscribe for. The formula is therefore straightforward. The gross prize is your counted population times the band rate times twelve. The net prize is that figure minus the cost of any residual Oracle Java you still need and minus the one time and ongoing cost of running OpenJDK.
| Scenario | Counted basis | Indicative annual |
|---|---|---|
| Subscribe whole estate | 10,000 | $990,000 |
| Migrate most workloads | small residual | far lower |
| Full migration, no Oracle Java | 0 | $0 subscription |
The figures above are indicative and depend on your deployment and your contract. The shape, though, holds across estates: the bulk of the spend is avoidable because the bulk of the workloads do not need Oracle Java in particular. They need a Java runtime, and a free OpenJDK distribution is a Java runtime built from the same source.
When you compare estimates across organizations, three factors explain almost all of the variation. The first is the share of workloads that can move. In most estates this is high, because standard server side and containerized Java has no dependence on anything Oracle specific. The second is the rate band, which is a function of headcount and is hard to change. The third is the contract structure, because a deal with a high minimum floor and a steep escalator costs far more over a term than the headline rate suggests. A good estimate looks at all three rather than only the first year rate.
A credible estimate nets the saving against the cost of the migration itself. Budget for discovery, testing, packaging, any paid OpenJDK support you choose, and the staff time to run the phases. For most estates these costs are a fraction of a single year of the all estate subscription, which is why the payback period is usually short. Label the migration cost as indicative until you have scoped your own estate, then refine it once discovery is complete.
The largest line in the migration cost is usually people time, not licenses, because most OpenJDK distributions are free to run. That means the cost is mostly one time effort that ends when the phases complete, while the saving recurs every year. An honest estimate makes that contrast visible by separating the one time cost from the recurring saving.
| Item | Type | When it lands |
|---|---|---|
| Discovery and triage | One time | Early |
| Testing and packaging | One time | During phases |
| OpenJDK support, if chosen | Recurring | Ongoing, small |
| Avoided Oracle Java subscription | Recurring saving | Every year after |
The headline saving is the runtime cost, but the contract traps add to the prize. Oracle Java deals often carry a minimum annual floor, an annual true up at each anniversary, and a renewal escalator. Migrating before you sign removes the base those traps grow on. A smaller envelope means a smaller floor, a smaller true up, and a smaller escalator. Over a three year term these compounding effects can rival the first year saving, so a serious estimate models the whole term rather than a single year.
An estimate is a planning tool, not a promise. It should be built from a real inventory wherever possible, and clearly labelled as indicative where it relies on assumptions. Resist the temptation to present a single confident number. A floor, a target, and a ceiling are far more useful, because they show finance the range and let you defend the midpoint. The discipline of giving a range also protects your credibility when the final outcome lands, as it almost always does, somewhere inside it.
Three mistakes recur. The first is estimating from Oracle's population figure rather than your own, which bakes in the very inflation you are trying to remove. The second is ignoring the residual, which makes the saving look larger than it is and undermines trust when the residual surfaces later. The third is treating the migration cost as if it were recurring, which makes the payback look worse than reality. Avoid all three and your estimate will hold up to scrutiny from finance and from Oracle alike.
An estimate is most valuable when it changes the negotiation. Once you can show that most of the estate has moved or will move, the opening number loses its force. For the full method behind the move, read the OpenJDK Migration Playbook. To weigh the runtime options behind your residual choice, see our guide to support options for OpenJDK in the enterprise, and to understand the patching picture that underpins any cost comparison, read about security updates on OpenJDK distributions.
A saving that lands all at once is rare, and you should not promise one. More often the saving arrives in steps as each phase of the migration completes. The first phase, usually server side and containerized workloads, removes the largest block of avoidable spend. Later phases bring the desktop fleet and the harder cases, each one shrinking the envelope a little further. Model the saving as a curve rather than a single drop, and tie each step to a phase so finance can see the value arrive in line with the effort. This phased view also protects you if a phase slips, because the earlier savings are already banked.
It helps to express the curve against your renewal calendar. If a true up or renewal falls in the middle of the program, the saving you have captured by that date is the number that matters for the negotiation, not the eventual full saving. Aligning the phase plan to the contract calendar is how an estimate turns into leverage at exactly the moment you need it.
Before you take an estimate to finance, run it through a few quick checks. Confirm the population figure is your own and not Oracle's. Confirm the residual is sized from a real inventory rather than assumed away. Confirm the migration cost is separated into one time and recurring parts. Confirm the contract traps are modeled across the whole term, not just the first year. And confirm the headline figure is presented as a range with a defensible midpoint. An estimate that passes these checks will hold up in front of finance and in front of Oracle.
Will the saving really be this large? In most estates the bulk of the spend is avoidable, because most workloads do not need Oracle Java in particular. The exact figure depends on your residual and your contract, which is why the estimate is a range rather than a single number. Does migration cost wipe out the saving? Rarely, because the migration cost is mostly one time effort while the saving recurs every year. What if we cannot move everything? You do not need to. The goal is to carve the estate down to a small residual and negotiate that, which captures most of the saving even when a full exit is not possible.
Build your own estimate from a real estate inventory, not a guess. Our field guide includes the worked exposure model and the discovery checklist you need to do it properly, so the number you bring to finance and to Oracle is one you can defend.
The Migration Field Guide walks through estate discovery, workload triage, distribution choice, and the residual negotiation, with a worked exposure model.
Download the field guide Book a Strategy CallFixed fee or gainshare, both backed by our guarantee. We sit between you and Oracle and we never take vendor money.
Get a QuoteWeekly intelligence on Oracle Java licensing moves and the buyer side defenses that work.