Contents
Key takeawaysMigration cost against subscribingWhat we saw in 2024 and 2025The cost of subscribingThe cost of full migrationThe cost of the hybridFive year comparisonChecking your own numbersWhat to do nextFAQMost Java cost models compare the Oracle invoice with a support quote, which prices half the problem. Priced across all four cost buckets, full migration wins for most companies and the hybrid comes last.
- Four buckets. License, supplier support, one time internal effort and recurring internal effort; most business cases contain the first two and lose the argument on the last two.
- Effort is a portfolio calculation. For a company with 220 Java applications we model 700 to 1,200 person days, and more than half of the application work sits in the hardest fifth of the applications.
- The hybrid is the expensive one. Staying free on Oracle binaries means upgrading every server to the next long term support release roughly every two years, at 40 to 60 percent of the original migration effort.
- Most of the effort is not cash. Internal days are usually absorbed capacity, so show them apart from incremental cash, or finance will discount the whole model.
- Payback lands between 9 and 24 months. It follows the counted employee number far more than the efficiency of the migration.
- A scoped Oracle remnant is priced at full headcount. The subscription bills on total counted employees however few machines run Oracle Java, so a small remnant can cost what the whole company costs.
What does an Oracle Java migration cost compared with subscribing?
On a 5,000 employee company with 220 Java applications, a full migration to OpenJDK costs 700 to 1,200 internal person days once, then a small recurring cost. Subscribing costs $400,000 to $480,000 a year after negotiation. A hybrid of free Oracle binaries plus a scoped subscription costs the most over five years.
Those are the three patterns every Java decision comes down to: subscribe to Oracle, migrate fully to a non Oracle build, or run the hybrid. The technical differences between them are small. The commercial differences are large, and most of them sit in internal effort that the usual business case leaves out.
Which four cost buckets belong in a Java cost model?
We price every pattern across the same four buckets. Most drafts we review contain the first two, because both come from a vendor quote, and lose the argument on the last two.
- License and subscription. What you pay a vendor for the right to run the software. It is always in the model.
- Supplier support. What you pay for a response commitment behind the runtime. It is usually in the model.
- One time internal effort. The person days to inventory, pilot, migrate, validate, package, evidence and terminate. It is rarely in the model.
- Recurring internal effort. Patch currency, version upgrades, headcount reconciliation and audit response. It is almost never in the model, and it decides the five year answer.
Two of the three patterns look cheap in the first two buckets and expensive in the fourth. A model built on invoices alone therefore picks the wrong pattern with some regularity. The way to present these buckets to a finance function is set out in the CFO business case to leave Oracle Java.
What reference company is this page priced against?
All three patterns are priced on one hypothetical company so the comparison holds. Substitute your own numbers but keep the structure, because the shape of the answer follows the ratios more than the absolute size.
| Attribute | Value | Why it matters to the model |
|---|---|---|
| Counted employees | 5,000 | Sets the entire Oracle bill, whatever the footprint |
| Server and container JVMs | 400 | Sets the supplier support bill on the alternatives |
| Distinct applications carrying Java | 220 | Sets the migration effort, which is counted per application |
| Desktops with a Java runtime | 900 | Adds packaging and user acceptance effort, and a support unit |
| Employees per JVM | 12.5 | The ratio that predicts the answer before any modeling starts |
The last row matters most. At 12.5 counted employees per JVM this company is deliberately ordinary. The higher that ratio, the more Oracle charges per running JVM and the faster a migration pays back. The Oracle Java decision gate reads this ratio and returns a provisional destination before you build anything.
How to Negotiate the Oracle Java Employee Agreement: Honest Leverage in a Captive Deal
What have we seen in Oracle Java cost models in 2024 and 2025?
I ran or reviewed roughly 30 to 45 Oracle Java engagements in 2024 and 2025. The business cases that failed almost never failed on the license arithmetic. They failed on effort, and in three recurring ways.
- Effort left out. The first draft priced the runtime and ignored the effort, so the first question from finance destroyed the credibility of the whole paper.
- Effort estimated from the top. Estimates built bottom up by application owners came in 2 to 3 times higher than the platform team's estimate, and the application owners were closer to the final number.
- The free route left unpriced. No one priced the recurring cost of staying on free Oracle binaries. That option wins the first year and loses the fifth.
None of these is a technical failure. Each one is a gap in how the paper was built, and each can be closed before the paper reaches a steering committee.
Oracle Database ULA Negotiation
Our white paper on negotiating an Oracle Database ULA, from scope and term to certification and exit.
Get the white paper →What does subscribing to Oracle Java cost end to end?
On the reference company, subscribing costs $630,000 a year at list, plus 20 to 40 person days a year of internal effort that rarely appears anywhere. The license line is visible. The hidden cost is the yearly work of maintaining a counted number that tends to grow.
How is the Java SE Universal Subscription priced?
The Java SE Universal Subscription is priced per counted employee per month, on published volume bands. Oracle's own FAQ gives a starting price of $15 and a lowest published tier of $5.25, with lower pricing possible above 50,000 employees. Check the current bands against Oracle's price list before a paper goes out, because Oracle revises them.
| Employee band | List rate per employee per month | Annual cost at a sample count |
|---|---|---|
| 1 to 999 | $15.00 | $179,820 at 999 |
| 1,000 to 2,999 | $12.00 | $144,000 at 1,000 |
| 3,000 to 9,999 | $10.50 | $378,000 at 3,000 |
| 10,000 to 19,999 | $8.25 | $990,000 at 10,000 |
| 20,000 to 29,999 | $6.75 | $1,620,000 at 20,000 |
| 30,000 to 39,999 | See Oracle's current price list | Not modeled here |
| 40,000 to 49,999 | $5.25 | $2,520,000 at 40,000 |
The band rate applies to the whole count, so the bill steps down at each band boundary. At list, 999 employees cost $179,820 a year and 1,000 cost $144,000. Likewise 2,999 employees cost $431,856 and 3,000 cost $378,000. If your count sits just below a boundary, check whether contractors or a pending acquisition will push it over before you sign.
The reference company sits at 5,000 employees and $10.50, which is $630,000 a year at list. A realistic negotiated outcome lands between $400,000 and $480,000. The counting rules that produce the 5,000 are covered in the employee metric guide, and contractor counting in contractors and consultants in the employee count.
What internal effort does staying on the subscription take?
Subscribing still takes work. That load appears in no business case because it is spread across procurement, human resources and the platform team.
- Headcount reconciliation, 10 to 20 days a year. Producing a counted number that holds up across staff, contractors, outsourcers and acquired entities is real work. It is also the highest value work in this pattern, because every employee you correctly exclude comes off the bill.
- Renewal negotiation, 5 to 15 days. This recurs every year, and it grows in a year when another Oracle agreement is also up.
- Deployment evidence, 5 to 10 days. You still need to know where Oracle Java runs, because the subscription has usage boundaries of its own.
- Growth exposure. An acquisition adds counted employees from the acquisition date, so the bill rises without anyone deploying anything. Acquisitions and divestitures in the Java count covers the timing.
The subscription's recurring internal cost is small. Its recurring commercial cost grows every time your company hires, acquires or outsources, and none of those is a Java decision.
What contract terms should you ask for if you subscribe?
If the model says stay, or if you keep a paid remnant, the order form decides how much of the growth exposure you carry. Ask for these in writing before signature.
- A rate hold for the full term. Fix the per employee rate for every year of a multi year order, so a later price list revision does not reach you mid term.
- A fixed count, or a growth allowance. Agree the counted number at signature and a band of growth that triggers no additional fee until renewal.
- A written employee definition. Name the populations you have agreed to exclude, such as contractors of a divested unit, so the count cannot be reopened at renewal.
- An acquisition grace period. Ask that acquired employees are counted from the next renewal instead of the acquisition date.
- A reduction right at renewal. Keep the ability to renew at a lower count after a divestiture or a partial migration.
Oracle will not grant all five. Asking for them sets the terms of the discussion, and contract language to cap the headcount goes further into the wording.
What does a full migration to OpenJDK cost, including internal effort?
On the reference company, full migration costs 700 to 1,200 person days once, plus supplier support of zero to roughly $60,000 a year depending on how narrowly you scope it. The license line goes to zero, because every mainstream alternative is built from the OpenJDK project and ships free for production use.
How much effort does each application class take?
Migration effort is counted per application, and it is uneven. Sorting the portfolio into six classes turns a guess into a calculation, and tells you which applications to pilot first.
| Application class | Share of portfolio | Applications | Days each | Days for the class | What consumes the time |
|---|---|---|---|---|---|
| Plain server or container application | About 65 percent | 143 | 1 to 3 | 143 to 429 | Base image change, regression run, change record, owner sign off |
| Carries a monitoring or security agent | About 15 percent | 33 | 2 to 5 | 66 to 165 | Agents pinned to a vendor version string stop reporting without raising an error |
| Sensitive to cryptography or federal standards | About 5 percent | 11 | 5 to 12 | 55 to 132 | Provider ordering, keystore types and policy defaults differ by build |
| Reporting and document generation | About 6 percent | 13 | 3 to 10 | 39 to 130 | Font availability and rasterizer differences shift PDF layout |
| Desktop, applet or Java Web Start delivered | About 4 percent | 9 | 10 to 25 | 90 to 225 | Repackaging, a Web Start replacement, and user acceptance testing |
| Vendor product with an embedded runtime | About 5 percent | 11 | 5 to 15 | 55 to 165 | Vendor management and contract work, almost no engineering |
The bottom of every range adds up to about 450 days and the top of every range to about 1,250. We model the portfolio at 450 to 800 days, which assumes most classes land in the lower half of their range. Test that assumption against your own application owners before you publish a total.
The distribution matters more than the total. The 9 percent of applications in the desktop and cryptography classes consume close to a third of the effort, and the hardest fifth of the portfolio consumes more than half. That is why a pilot of three easy microservices tells you little about the total.
What program level effort sits on top of the application work?
A migration carries overhead that barely changes with the number of applications. Platform teams underestimate this part more consistently than any other.
| Workstream | Person days | Note |
|---|---|---|
| Binary inventory across servers, containers, agents and desktops | 25 to 60 | Installed product lists miss runtimes, so scan for the binary |
| Distribution selection and the written standard | 10 to 15 | One primary build, one named exception build |
| Base images, provisioning templates and pipelines | 20 to 40 | If the old binary is still available internally, it comes back |
| Desktop packaging and rollout, 900 machines | 30 to 80 | Usually the largest single line, and usually missing |
| Evidence pack, download blocking and termination | 10 to 20 | Cheap now, expensive to reconstruct in two years |
| Program management across 9 to 14 months | 100 to 160 | Roughly half a full time role for the duration |
Program overhead lands between 195 and 375 days. Added to the portfolio range, that gives the one time total quoted above for the reference company. The CI/CD and developer workstation cleanup guide breaks out the pipeline and workstation share, and when third party applications bundle Oracle Java covers the vendor product share.
How do you separate cash cost from absorbed effort?
Person days are not automatically money. On the companies we advise, 60 to 80 percent of migration effort is absorbed by existing internal capacity. The incremental cash is contractor cover, tooling and any specialist testing you cannot do in house.
Present both figures. A model that converts 1,000 days into a single cash number invites finance to challenge the day rate and discard the paper. A model that shows absorbed days and incremental cash side by side gets discussed on its merits.
- Incremental cash on the reference company. Typically $120,000 to $300,000 across the program, mostly contractor cover and desktop packaging.
- Absorbed internal days. The remainder, stated as days and as an opportunity cost against the roadmap work they displace.
- Recurring cost afterwards. A named owner for quarterly patch currency, and a support contract only where an external obligation exists.
What does the hybrid pattern cost once upgrades are priced?
In most companies we model, the hybrid costs more over five years than either alternative, because of recurring effort. It keeps most servers on free Oracle binaries and pays a scoped subscription where an Oracle build is required.
Why does the free Oracle JDK route carry a recurring upgrade bill?
Oracle's No Fee Terms and Conditions cover a long term support release for a bounded window, which ends about one year after the next long term support release ships. Oracle's JDK FAQ lists free JDK 21 updates under these terms until September 2026, and free JDK 25 updates until September 2028.
Staying free therefore means moving every Oracle JDK server to the next long term support release inside each window, roughly every two years. Anyone still on JDK 21 is at that point now, as the end of free JDK 21 updates explains. Take future dates from the Oracle Java SE Support Roadmap and give them a named owner.
| Work item | Distribution swap | Version upgrade |
|---|---|---|
| Application code changes | Rare | Common, as APIs are removed and defaults change |
| Regression testing | Full | Full |
| Change records and owner sign off | Full | Full |
| Vendor certification checks | Full | Full |
| Frequency | Once | Every window, indefinitely |
A version upgrade touches the same applications a migration touches, with the same testing and sign off. We model it at 40 to 60 percent of the original migration effort, which is 280 to 720 days every two years on the reference company.
In round numbers, the hybrid swaps roughly 900 days once for roughly 500 days every two years, for as long as the pattern lasts. The LTS upgrade treadmill sets out the release cycle in detail.
Why does a scoped Oracle subscription still cost full price?
The Universal Subscription is priced on total counted employees, whatever the number of machines running Oracle Java. A remnant of ten servers is therefore quoted against all 5,000 employees, and a small remnant can cost what the whole company costs.
The paid half costs less in only two situations:
- A legacy entitlement. The remnant sits inside a pre 2023 Named User Plus or Processor entitlement you already hold, as described in legacy Named User Plus licenses.
- An Oracle product that requires Java. Oracle's FAQ says such a product carries the right to run the Java SE runtime for that product alone, covered in restricted use entitlements you already have.
Absent one of those, the hybrid pays the full subscription plus the full upgrade cycle. It is the one pattern that pays a full subscription and a recurring migration at the same time, and it still tends to appear in steering papers as the cautious option.
How do the three patterns compare over five years?
Full migration is cheapest by a wide margin, subscribing is second, and the hybrid is last once recurring effort is priced. The table uses the same company throughout: 5,000 counted employees, 400 JVMs and 220 applications.
| Line | Subscribe | Full migration | Hybrid |
|---|---|---|---|
| License, five years | $2.0m to $2.4m negotiated | Zero | $2.0m to $2.4m, priced on full headcount |
| Supplier support, five years | Included | Zero to $300,000, scoped to real need | Zero to $150,000 |
| One time internal effort | Minimal | 700 to 1,200 days | Minimal at the start |
| Recurring internal effort | 20 to 40 days a year | 15 to 30 days a year for patch currency | 280 to 720 days every two years |
| Audit exposure for Java | Present, and priced on headcount | Removed once binaries are gone and the removal is evidenced | Present, on the paid remnant and the free window |
| Exposure to headcount growth | Direct and immediate | None | Direct and immediate |
Over five years the hybrid goes through at least two upgrade cycles, which is 560 to 1,440 days of recurring effort on top of the same license bill as subscribing. Most steering papers we review leave that line out.
How long does an Oracle Java migration take to pay back?
Between 9 and 24 months on most companies we model. Payback follows the counted employee number more than the speed of the migration, so a slow, careful program still pays back when the headcount is large.
- Under 1,000 counted employees. Payback can exceed two years. Model it carefully, and be willing to conclude that staying is right for now.
- 1,000 to 10,000 counted employees. Payback typically 12 to 24 months. Most decisions are made in this band, and most are made correctly.
- Over 10,000 counted employees. Payback often inside 12 months, and the recurring saving soon exceeds the entire program cost.
In every band, a credible ability to leave is what changes an Oracle quote. The exit model is worth building even when the company ends up staying, as the Illinois manufacturer case shows, and migration credibility in a Java negotiation explains why.
Worked example: the same technical footprint at three headcounts
Say three companies each run the reference footprint of 400 JVMs and 220 applications, and differ only in counted employees. Assume a one time program of 1,000 days, 70 percent absorbed. Value the 700 absorbed days at a hypothetical $600 a day, which is $420,000, and add $200,000 of incremental cash. The program costs $620,000.
Afterwards each company pays an assumed $30,000 a year for scoped support and spends 20 days a year on patch currency, another $12,000. Recurring cost after migration is $42,000 a year. Payback is the program cost divided by the monthly saving.
| Counted employees | Employees per JVM | Subscription avoided per year | Net saving per year | Payback |
|---|---|---|---|---|
| 3,000 | 7.5 | $378,000 at list | $336,000 | About 22 months |
| 5,000 | 12.5 | $440,000 negotiated | $398,000 | About 19 months |
| 5,000 | 12.5 | $630,000 at list | $588,000 | About 13 months |
| 10,000 | 25 | $990,000 at list | $948,000 | About 8 months |
The engineering work is identical in every row, and payback still ranges from 8 to 22 months. The example leaves out the yearly subscription upkeep that migration also removes, which shortens every payback slightly. Savings only start at the first renewal you do not sign, so the program has to finish before that date.
What will Oracle's account team say, and how should you answer?
Expect some version of these four lines once Oracle learns a migration is being costed.
- "Migration will cost you more than the subscription." Show the four bucket model with absorbed days and cash separated, and ask Oracle to price five years of subscription with your expected headcount growth included.
- "Keep Oracle only where you need it and pay for that." Ask for the scoped quote in writing. It will be priced on total counted employees, which settles the question.
- "Sign a three year term now and we will hold today's rate." Take the rate hold only with a reduction right at renewal, so a partial migration lowers the next bill. Do not let the offer's expiry date set your migration schedule.
- "OpenJDK builds are unsupported." Supported builds with response commitments exist from several suppliers. Buy that support only where an external obligation requires it.
Keep the replies factual and in writing. The rollback and support risk that Oracle will point to is priced in OpenJDK support and rollback risk after leaving Oracle Java.
What does this cost model deliberately not claim?
A cost model that claims certainty reads like a sales document. Publish these three limits next to the numbers, and the model becomes harder to attack.
- Day counts are ranges, not estimates. They come from portfolio patterns, and a bottom up estimate from your own application owners will beat them.
- Support pricing is negotiated. Published rates from any supplier are a ceiling, so model a band of prices.
- The free build is not free to run. It carries zero license cost. Patch currency, escalation and version refresh remain yours, and they are the recurring line in bucket four.
Why the usual invoice comparison is the wrong place to start
The standard business case compares the Oracle invoice with a support quote and declares a saving. We disagree with starting there. In front of a competent finance function it loses, because it prices the two buckets that are easy to obtain and ignores the two that decide the five year answer.
Build the model in the opposite order: portfolio effort first, then program overhead, then the split between absorbed days and cash, and the license lines last. Built that way, the migration case still wins in most companies. It wins on numbers that survive challenge, and it correctly identifies the minority where the right answer is to stay another year.
How do you check your own numbers before you build the model?
Collect the four reference numbers from your own records before anyone models a pattern. Each one has an owner and a source, and a wrong source is the most common reason a model gets reopened.
| Input | Where to get it | What to watch for |
|---|---|---|
| Counted employees | The HR system of record, plus contractor and outsourcer records from procurement | The employee definition reaches contractors and outsourcers as well as payroll staff |
| Server and container JVMs | A file system scan for java binaries, the release file in each JDK directory, and container image manifests | Base images and build agents carry runtimes that no installed programs list shows |
| Applications carrying Java | The CMDB, checked by application owners | Vendor products with embedded runtimes are often recorded under the product name, with no Java entry |
| Desktops with a runtime | The software inventory in your endpoint management tool | Old Java 8 runtimes installed for a single browser applet or Web Start tool |
Run the scans yourself and keep the results inside your own tooling. Guidance on finding every install is in detecting Oracle Java installs before Oracle does, and the risk of reporting through Oracle's own tooling is covered in the Java Management Service self report trap.
What to do next
- Write down the four reference numbers. Counted employees, JVMs, distinct applications carrying Java, and desktops with a runtime, each from a named source.
- Sort the application portfolio into the six classes. An approximate sort by an application owner beats a precise sort by a tool.
- Build the effort model bottom up. Have three application owners check their own class before anyone sees a total.
- Split the total into absorbed days and incremental cash. Present both, and never convert everything into one cash figure.
- Price the hybrid in full. Include a version upgrade inside every free window and a subscription quoted at full headcount.
- Model payback against the counted employee number. Base it on headcount and your renewal date. How quickly you think you can migrate matters much less.
- Choose the build and check the wider options. Use the distribution comparison to choose the primary build, and the six Java options to check you have not missed a route.
- Schedule and sequence the exit. Set delivery against the 9 to 14 month timeline, sequence the exit with the Oracle Java SE exit map, and bring in the OpenJDK migration advisory service if the model has to hold up against a renewal deadline.
Frequently asked questions
What does an Oracle Java migration actually cost?
For a company with 220 Java applications, 400 JVMs and 900 desktops we model 700 to 1,200 person days once: roughly 450 to 800 days of application work and 195 to 375 days of program overhead. Most of those days are absorbed by existing staff, and incremental cash typically runs $120,000 to $300,000.
Why is the hybrid pattern the most expensive over five years?
It pays twice. The paid remnant is quoted on every counted employee, so it costs about the same as a full subscription, while the free servers need a version upgrade inside each No Fee Terms window. Over five years that is at least two upgrade cycles.
Which cost buckets do most business cases miss?
One time internal effort and recurring internal effort. License and support lines arrive on a vendor quote, so they are always present, while the effort lines have to be built from the application portfolio. Building those first is what allows a model to survive a finance challenge.
How do we estimate effort without a completed inventory?
Ask application owners to place each application in one of six classes and apply a day range to each, from 1 to 3 days for a plain server application up to 10 to 25 days for a desktop or Java Web Start application. An approximate sort is enough for a first model; refine it once the binary inventory is done.
How long until a migration pays back?
Most companies we model pay back inside two years. Above 10,000 counted employees it often lands inside a year; below 1,000 it can run past two years, and staying another year is sometimes the correct call. Measure it from the first Oracle renewal you will not sign, because savings start there.
Should we convert person days into a single cash number?
No. It is the most common way a good business case gets rejected, because finance challenges the day rate and then the whole paper. Show absorbed internal capacity as days with an opportunity cost, and list contractor cover, tooling and specialist testing as the cash.
Is a free OpenJDK build zero cost?
Only on the license line. You still own patch currency, escalation and version refresh, which we model at 15 to 30 days a year on a company of this size. Name an owner for the quarterly updates, because an unpatched free build brings back the security risk the migration was meant to remove.
Does the end of free JDK 21 updates change the cost comparison?
Yes, for anyone on the hybrid. Oracle's free JDK 21 updates under the No Fee Terms end in September 2026, so servers on free Oracle JDK 21 must move to JDK 25 or onto a paid subscription. That upgrade is the first recurring cycle, and it is due now.