The three responses to Oracle's per employee Java metric, modeled on one estate across four cost buckets. The two buckets most business cases omit are the ones that decide the five year answer, and they are the reason the hybrid usually loses.
Most Java cost models compare two numbers: the Oracle invoice and a support quote. That prices half the problem. This page models all three patterns on one estate across four cost buckets, including the internal effort that never reaches a business case.
Subscribe to Oracle, migrate fully to a non Oracle build, or run a hybrid where free Oracle binaries carry most of the estate and a scoped subscription covers the rest. The technical difference between these three is small. The cost difference is not, and it is not where buyers look for it.
Two of the three patterns are cheap in buckets one and two and expensive in bucket four. That is why a model built on invoices alone reaches the wrong conclusion so reliably. The finance framing that survives challenge is set out in the CFO business case to leave Oracle Java.
All three patterns are priced on one estate so the comparison means something. Substitute your own numbers, but keep the structure, because the shape of the answer changes with the ratio rather than with the absolute size.
The reference estate
| Attribute | Value | Why it matters to the model |
|---|---|---|
| Counted employees | 5,000 | Sets the entire Oracle bill, regardless of 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 per application not per JVM |
| 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 |
Note the last line. At 12.5 counted employees per JVM this estate is not an extreme case, which is deliberate. The gate that reads this ratio and returns a provisional destination sits in the Oracle Java decision gate.
On the reference estate, roughly 630,000 dollars a year at list, plus 20 to 40 person days a year of internal effort that nobody counts. The license line is the visible cost. The invisible cost is the annual work of defending a number that only ever grows.
The Java SE Universal Subscription is priced per employee per month on published volume bands. Confirm the current bands against Oracle's price list before you use these in a paper, because Oracle revises them.
Published employee bands and what they produce annually
| Employee band | List rate per employee per month | Annual cost at the band minimum |
|---|---|---|
| 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 |
| 40,000 to 49,999 | $5.25 | $2,520,000 at 40,000 |
The reference estate 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 decoded in the employee metric decode.
Subscribing is not effort free. It carries a recurring internal load that appears in nobody's business case because it is spread across procurement, human resources and the platform team.
The subscription's recurring internal cost is small. Its recurring commercial cost grows every time your company hires, acquires or outsources, and none of that is a Java decision.
On the reference estate, 700 to 1,200 person days one time, plus a supplier support line of zero to roughly 60,000 dollars 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.
Migration effort is per application, not per JVM, and it is wildly uneven. Sorting the portfolio into six classes turns a guess into a calculation, and it also tells you which applications to pilot first.
Person days per application, by class, on a 220 application portfolio
| Application class | Share of portfolio | Days each | What consumes the time |
|---|---|---|---|
| Plain server or container application | About 65 percent | 1 to 3 | Base image change, regression run, change record, owner sign off |
| Carries a monitoring or security agent | About 15 percent | 2 to 5 | Agents pinned to a vendor version string stop reporting silently rather than failing |
| Cryptography or federal standard sensitive | About 5 percent | 5 to 12 | Provider ordering, keystore types and policy defaults differ by build |
| Reporting and document generation | About 6 percent | 3 to 10 | Font availability and rasterizer differences move PDF layout |
| Desktop, applet or Java Web Start delivered | About 4 percent | 10 to 25 | Repackaging, a Web Start replacement, and user acceptance testing |
| Vendor product with an embedded runtime | About 5 percent | 5 to 15 | Vendor management and contract work, almost no engineering |
Run those percentages against 220 applications and the portfolio lands around 450 to 800 days. The distribution matters more than the total: the 9 percent of applications in the desktop and cryptography classes consume roughly a third of the effort, which is why piloting three easy microservices proves nothing.
Application work is not the whole bill. A migration carries a program overhead that is largely independent of how many applications you have, and it is the part platform teams underestimate most consistently.
Program level effort on the reference estate
| Workstream | Person days | Note |
|---|---|---|
| Binary inventory across servers, containers, agents and desktops | 25 to 60 | Scan for the binary, not for an installed product name |
| 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 returns |
| 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, the reference estate models at 700 to 1,200 person days one time. The pipeline and workstation share of that is broken out in the CI/CD and developer workstation cleanup guide, and the vendor product share in when third party applications bundle Oracle Java.
Person days are not automatically money. On the estates we advise, 60 to 80 percent of migration effort is absorbed by existing internal capacity, and the genuine 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 a finance team to challenge the rate and discard the paper. A model that separates absorbed days from incremental cash survives the meeting.
More than either alternative over five years, in most estates we model, and the reason is recurring effort rather than license fees. The hybrid keeps most of the estate on free Oracle binaries and pays a scoped subscription where an Oracle build is genuinely required.
Oracle's No Fee Terms and Conditions license covers a long term support release for a bounded window. Staying free therefore means moving the whole estate to the next long term support release inside each window, roughly every two years, on Oracle's calendar.
That is not a small change. A version upgrade touches the same applications a migration touches, and carries the same regression testing, change records and owner sign off. We model it at 40 to 60 percent of the original migration effort.
On the reference estate that is 280 to 720 days every two years, indefinitely. Take the window dates from the Oracle Java SE Support Roadmap rather than from an article, and diarize them with a named owner.
Why a version upgrade costs almost as much as a distribution swap
| Work item | Distribution swap | Version upgrade |
|---|---|---|
| Application code changes | Rare | Common, as removed APIs 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 |
Read the last row twice. The hybrid trades a one time cost for a recurring one, and the recurring one is nearly as large. On the reference estate that is the difference between roughly 900 days once and roughly 500 days every two years for as long as the pattern lasts.
The paid half of the hybrid rarely behaves as buyers expect. The Universal Subscription is priced on total counted employees, not on the number of machines running Oracle Java, so a remnant of ten servers is quoted against 5,000 employees.
There are two ways the scoped half genuinely costs less. The remnant sits inside a pre 2023 Named User Plus or Processor entitlement you already hold, or it sits inside an Oracle product entitlement that grants restricted use Java rights. Absent one of those, the hybrid pays the full subscription plus the full upgrade treadmill.
The hybrid is the only pattern that can pay a full subscription and a full migration effort at the same time, every two years, and still be described in a steering paper as the cautious option.
Full migration wins by a wide margin, the subscription is second, and the hybrid is last once recurring effort is priced. Here is the same estate, the same 400 JVMs and the same 220 applications, across five years.
Five year comparison, 5,000 counted employees and 400 JVMs
| 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 surface for Java | Present, and priced on headcount | Removed once binaries are gone and evidenced | Present, on the paid remnant and the free window |
| Exposure to headcount growth | Direct and immediate | None | Direct and immediate |
Between 9 and 24 months on most estates we model, and it moves with the counted employee number rather than with migration efficiency. That is worth stating plainly, because it means a slow, careful migration still pays back if the headcount is large.
Whichever band you sit in, the credible ability to leave is what moves an Oracle quote. That is why the exit model is worth building even in the estates that end up staying, as the Illinois manufacturer case shows.
Source: Redress Compliance advisory engagement file, 2024 to 2025.
Three honest limits, because a cost model that claims certainty is a sales document. Publish these next to the numbers and the model becomes harder to attack, not easier.
The standard business case compares the Oracle invoice with a support quote and declares a saving. We disagree with that framing, and it loses in front of a competent finance function for a simple reason: it prices the two buckets that are easy to obtain and ignores the two that decide the five year answer. Build the model the other way around. Start with the application portfolio effort, add the program overhead, separate absorbed days from incremental cash, then put the license lines in last. Done that way the migration case still wins in the large majority of estates, but it wins on numbers that survive challenge, and it correctly identifies the minority of estates where the honest answer is to stay another year.
On a 220 application estate with 400 JVMs and 900 desktops we model 700 to 1,200 person days one time. Roughly 450 to 800 of those days are application work and the rest is program overhead. Of the total, 60 to 80 percent is normally absorbed internal capacity rather than incremental cash.
Because it pays a full subscription and a recurring migration at the same time. The Universal Subscription is priced on total counted employees regardless of how few machines run Oracle Java, and staying free on the rest of the estate requires a version upgrade inside every No Fee Terms window at 40 to 60 percent of the original migration effort.
One time internal effort and recurring internal effort. Almost every draft we review contains the license line and the support line, which are easy to obtain, and omits the two that decide the five year answer. Building the model in the reverse order is what makes it survive a finance challenge.
Sort the application portfolio into six classes and apply a day range to each. Plain server applications run 1 to 3 days, applications with monitoring agents 2 to 5, cryptography sensitive applications 5 to 12, and reporting engines 3 to 10. Desktop and Java Web Start applications run 10 to 25 days.
Between 9 and 24 months on most estates we model. Payback is driven by the counted employee number rather than by migration efficiency, so above 10,000 counted employees it often lands inside a year, and below 1,000 it can exceed two years. In that lowest band, staying another year is sometimes the correct answer.
No, and doing so is the most common way a good business case gets rejected. Separate absorbed internal capacity from genuine incremental cash such as contractor cover, tooling and specialist testing. A finance team that can see the split will engage with the model instead of challenging the day rate.
It is zero license cost, which is not the same thing. You still own patch currency, escalation and version refresh, which we model at 15 to 30 days a year on the reference estate. Budget a named owner for quarterly updates, because an unpatched free build reintroduces the risk the migration was meant to remove.
The full white paper on Oracle Database ULA negotiation. Scope, term, certification, territory, growth, exit, Oracle Database vs Oracle Cloud Database.
Gated with a work email on the download page. No sales follow up you did not ask for.
Get the White Paper →
500+ enterprise clients. 11 vendor practices. Industry recognized. One conversation can change what you pay for the next three years.
One buyer side briefing a week. Renewal signals, audit moves, and the levers that work. No vendor spin.
