This guide separates the 2026 build-versus-buy decision from the execution program that follows it. You will leave knowing which of the three patterns fits your estate, what the migration actually costs in effort and time, and how to run the CI/CD cleanup without leaving audit exposure behind.
This guide separates the 2026 build-versus-buy decision from the execution program that follows it. You will leave knowing which of the three patterns fits your estate, what the migration actually costs in effort and time, and how to run the CI/CD cleanup without leaving audit exposure behind.
Every organization running Java in production now faces one of three destinations: pay Oracle the per-employee Java SE Universal Subscription, run a hybrid where a small subscribed footprint coexists with OpenJDK, or migrate fully to a supported OpenJDK distribution and stop paying Oracle for Java entirely. The economics of that fork changed decisively when Oracle moved to the employee metric on January 23, 2023, and they get worse for buyers in 2026 as the last free Oracle JDK 21 update lands and the audit teams escalate.
We write this from 25 years on the buyer side of Oracle negotiations. The blunt reality: for the large majority of enterprises we advise, full migration to OpenJDK is the correct financial answer, and the only genuine questions are execution sequencing and residual risk. The subscription remains defensible in a narrow band of cases (deep GraalVM Enterprise dependency, contractual comfort requirements, or an estate too small for migration to pay back inside 18 months). This article models all three and then hands you the execution program. For the decision math alone, pair this with our Oracle Java versus OpenJDK decision guide.
For most enterprises, the only open questions are sequencing and residual risk, not whether to leave.
The pricing model is the whole story. Oracle's Java SE Universal Subscription is priced per employee, not per user and not per server. The published list starts at $15 per employee per month for the smallest tier and steps down through volume bands: roughly $12 (1,000 to 2,999 employees), $10.50 (3,000 to 9,999), and lower rates above that. Redress analysis places the meaningful tier boundaries at 1,000, 10,000, and 40,000 employees, with rates as low as $5.25 quoted for the very largest estates.
The trap is the definition of "employee." Oracle counts all your full-time, part-time, and temporary staff, plus the full-time, part-time, and temporary employees of your agents, contractors, outsourcers, and consultants who support your internal business operations. The contract language is explicit that the licensed quantity is determined by the number of employees, not the number of people who actually use Java, and it must at minimum equal your employee count on the order's effective date. You license the whole headcount to run Java on one server.
Oracle's own price list worked example makes the scale visible: a company with 28,000 total counted employees (23,000 staff plus 5,000 contractors) at $6.75 per employee per month pays $2,268,000 per year. That is not a negotiation outcome; it is Oracle's published arithmetic.
| Scenario | Old metric (annual) | 2026 employee metric (annual) | Multiple |
|---|---|---|---|
| Mid-market, 1,000 employees, ~50 Java users | $30,000 to $50,000 | $144,000 | ~3x to 4x |
| Enterprise, 12,000 employees | $200,000 to $500,000 | ~$1,300,000 | ~2.6x to 6.5x |
| Large enterprise, 28,000 counted (Oracle example) | Varies | $2,268,000 | N/A |
The escalation across the market converged on multiples of 2x to 10x relative to the old Named User Plus and Processor models. Those legacy metrics priced Java at roughly $2.50 per named user per month and $25 per processor per month at list. Pre-2023 perpetual and NUP contracts remain valid but cannot be expanded, so growth forces you onto the employee metric. Oracle stopped selling NUP and Processor licenses for Java in 2023; the employee model is the only door open to new buyers.
Buyers used to extract meaningful volume discounts on Java. That leverage has thinned. Several advisories note that as of 2025 the lowest-tier prices have plateaued and Oracle is less willing to move off published rates. Our own engagement data is more optimistic on paper: median discount from Oracle's first quote to a three-year signature ran between 22 and 41 percent depending on tier. Reconcile those two views this way: the discount you win is real, but it applies to a headcount-based number that is structurally larger than what you should be paying, so a 30 percent discount on a 5x cost increase is still a large bill.
The most productive negotiation lever is not price percentage. It is the counted quantity itself. In our engagements, contractor counts were the single largest dispute, and Oracle's opening position treats every contractor with system access as a counted employee. A narrower, defensible definition held in roughly four out of five engagements. Oracle's quoted employee counts ran 18 to 28 percent higher on average than the count a buyer could defend after a clean headcount audit. If you are going to subscribe, that headcount defense is where the money is. For the full procurement playbook, see our 20 critical Java SE procurement insights.
A 30 percent discount on a 5x cost increase is still a large bill. Fight the counted quantity, not the rate.
Two dates make 2026 the year the decision cannot be deferred. First, Oracle JDK 21, distributed under the No-Fee Terms and Conditions (NFTC) license, is free only until September 16, 2026. Oracle plans to ship the last free NFTC update to JDK 21 in July 2026. After that window closes, continued production use of Oracle JDK 21 defaults to the paid Universal Subscription, billed per employee. If your estate quietly standardized on the free Oracle JDK 21 build, you are on a countdown to a licensing event, not a stable position.
Second, the JDK 17 trap already sprang. The last free Oracle Java 17 update was 17.0.12 on August 16, 2024. Every subsequent Oracle JDK 17 patch falls under the OTN license and requires a subscription for production use. Organizations that stayed on Oracle's JDK 17 build for the security updates after that date have been accruing exposure since late 2024.
| Oracle build | Free (NFTC) until | What happens after |
|---|---|---|
| Oracle JDK 17 | 17.0.12, August 2024 | OTN license, subscription required for production |
| Oracle JDK 21 | September 16, 2026 (last update July 2026) | Defaults to paid Universal Subscription |
| Oracle JDK 25 | September 2028 (planned) | Expected to default to subscription after window |
There is a further trap that catches subscribers specifically: the NFTC license cannot be applied if you already have any Java subscription in place. If you hold a subscription agreement for any version of Java, that agreement is in force and you cannot fall back to the free NFTC build to avoid it. The free build is a route out for the never-subscribed, not an off-ramp for existing subscribers.
Subscribing is the right call in a minority of situations, and honesty about them protects your credibility with the CFO. Subscribe when you have a genuine, hard dependency on Oracle-only technology such as GraalVM Enterprise features, when your total counted headcount is small enough that migration effort will not pay back inside 18 months, or when a regulated environment demands the specific indemnities and support commitments Oracle contractually provides and you cannot secure equivalent terms from a commercial OpenJDK vendor.
If you land here, the discipline is entirely about the counted quantity and the contract term. Audit and defend the headcount before signing, exclude contractors who do not support internal operations, and resist multi-year commitments priced on a headcount you expect to shrink. Watch the residual 50,000-processor ceiling, which still exists in the subscription terms: you may run on up to 50,000 processors (excluding desktops and laptops), and exceeding that requires an additional license.
Hybrid means a deliberately small subscribed footprint alongside an OpenJDK majority. There are two flavors, and confusing them is expensive. Transitional hybrid is a phased migration where you keep a subscription covering the not-yet-migrated remnant while you move the bulk of the estate. Permanent hybrid keeps a subscription indefinitely for a genuinely locked set of workloads (Oracle-supported applications with Java bundling clauses, for example) while everything else runs OpenJDK.
The fatal error in hybrid is the employee metric itself. Because the subscription is priced on total counted employees regardless of how many machines actually run Oracle Java, keeping even one subscribed server can force you to license your entire headcount. A hybrid that leaves any Oracle Java in scope may cost the same as subscribing for everything. Hybrid only saves money if the subscribed remnant can be carved into a legacy NUP or Processor contract you already hold, or if you can fully retire Oracle Java from every server before the renewal that would otherwise trigger the full-headcount charge. We model the three patterns with numbers in Full Migration, Hybrid, or Subscribe: Three Java Patterns Modeled.
Because the metric is total headcount, one subscribed server can force you to license the entire company. Hybrid rarely saves what buyers expect.
OpenJDK is the same codebase Oracle builds its JDK from. A migration to Eclipse Temurin, Amazon Corretto, Azul Zulu, Microsoft Build of OpenJDK, Red Hat, or BellSoft Liberica is a distribution swap, not a re-platforming. For the vast majority of standard Java workloads the migration is technically low-risk because the bytecode and APIs are identical for the same feature version. The work is not in the code; it is in inventory, packaging, CI/CD, and vendor selection.
Full migration cuts Java spend by 60 to 90 percent in the estates we advise, because a supported OpenJDK subscription (where you choose to buy support) is priced per instance or per core, not per total headcount, and free community builds carry zero license cost. The residual spend is a support contract sized to the workloads that actually need an SLA, not to your entire payroll. This is the number that wins the CFO conversation, which we structure in Building the CFO business case to leave Oracle Java.
The distribution choice is a support and lifecycle decision, not a technical one, because the runtime is functionally equivalent across builds for a given version. Eclipse Temurin is the vendor-neutral community reference with no commercial obligation. Amazon Corretto is free and supported by AWS, strongest for teams already on AWS infrastructure. Azul offers the deepest commercial support tiers and long-dated LTS commitments for buyers who want a paid SLA. Microsoft Build of OpenJDK fits Azure-centric estates. Red Hat suits organizations standardized on RHEL and OpenShift. BellSoft Liberica offers broad platform coverage including embedded and Alpine builds.
The practical rule: pick one primary distribution to standardize on across the estate, and permit at most one exception distribution for a specific platform constraint. A proliferation of builds recreates the sprawl that made your Oracle inventory unauditable. We compare the leading builds head to head in Choosing an OpenJDK distribution: Corretto vs Temurin vs Zulu vs Microsoft and across the full field in Oracle Java alternatives, distribution by distribution.
| Distribution | Cost | Best fit | Paid support available |
|---|---|---|---|
| Eclipse Temurin | Free | Vendor-neutral default, no lock-in | No (community) |
| Amazon Corretto | Free | AWS-centric estates | Via AWS support |
| Azul Zulu | Free tier + paid | Buyers wanting a strong LTS SLA | Yes, deep tiers |
| Microsoft Build of OpenJDK | Free | Azure-centric estates | Via Microsoft support |
| Red Hat build of OpenJDK | Subscription | RHEL / OpenShift standardized | Yes |
| BellSoft Liberica | Free tier + paid | Broad platform, embedded, Alpine | Yes |
Sold-in-a-quarter migration promises do not survive contact with a real enterprise estate. In our experience a full-estate OpenJDK migration runs 9 to 14 months from kickoff to Oracle Java removed from production, and the calendar is dominated by discovery and third-party dependencies rather than by the runtime swap itself. The phases break down roughly as follows.
We detail the full schedule and the common overruns in How long does an OpenJDK migration take, the 9 to 14 month reality. Plan the program to complete before, not after, the September 16, 2026 JDK 21 cliff if any part of your estate runs that build.
The single most common failure in Java migrations is declaring victory on production servers while Oracle JDK persists in build pipelines and on developer machines. Every one of those is a download-log entry and a potential audit finding, because Oracle's primary audit trigger is the download log itself: Oracle audits enterprises that downloaded Java from the Oracle site without a subscription, and the log is what starts the inquiry.
Discipline means treating the base image and the developer toolchain as first-class migration targets. Replace Oracle JDK in every CI/CD runner and container base image, block Oracle download URLs at the proxy, remove Oracle JDK from developer workstation provisioning, and enforce the approved distribution through your build configuration so a new project cannot accidentally pull Oracle. The detailed procedure is in Cleaning Oracle JDK out of CI/CD pipelines and developer workstations. Skip this and you will pay a subscription bill for a migration you thought was finished.
Oracle's audit trigger is the download log. A migration that leaves Oracle JDK in CI/CD or on laptops is not finished.
The hardest technical problem is the application you did not build that ships an embedded Oracle JDK. You cannot simply swap the runtime because the vendor supports a specific bundled build. Three moves cover most cases: confirm whether the vendor's license grants you Java use rights that flow through their agreement (many do), pressure the vendor to ship an OpenJDK-based build (most major ISVs already have), or isolate and document the embedded runtime so it is defensibly out of your Oracle subscription scope. We work through each in When third-party apps bundle Oracle Java, and the embedded and OEM licensing terms are covered in the Oracle Java embedded licensing and OEM guide.
Also hunt for the paying-twice trap. The most common enterprise discovery is Java rights bundled inside a WebLogic or middleware contract that already covers certain servers, running alongside a separate Java SE subscription covering the same machines. If you hold Oracle middleware, confirm what Java rights it already grants before you buy or renew any Java subscription.
The fear that stalls migrations is: what if we lose support or need to roll back? Address it directly. OpenJDK security patches ship on the same quarterly cadence as Oracle's, sourced from the same upstream project, and reputable distributions release them within days of Oracle. For workloads that require a contractual SLA, buy a commercial OpenJDK support tier from Azul, Red Hat, BellSoft, or your cloud provider, sized to those workloads only. Rollback is straightforward because the distributions are interchangeable at the same feature version, so a pilot that fails validation reverts to the prior build without code changes. The rollback and support-risk analysis lives in OpenJDK support and rollback risk after leaving Oracle Java.
Oracle escalated Java enforcement through 2024 and 2025, and its Global License Advisory Services (GLAS) team now contacts organizations to verify Java compliance, including those that primarily run OpenJDK. Enforcement teams also concentrate on the twelve months before a Database or E-Business Suite renewal, using Java as added leverage. The back-penalty math is designed to intimidate: Oracle can claim three years of past unlicensed use at current Universal Subscription rates, which for a 5,000-employee company could exceed $1.8 million.
Your defense during migration is documentation. Keep a dated record of what you migrated and when, retain proof that Oracle downloads stopped, and be ready to defend a narrow contractor definition against Oracle's expansive one. Do not let a GLAS "friendly review" become a soft audit conducted on Oracle's terms. Run the sequence in our Oracle Java audit defense playbook, and if you are also unwinding legacy application servers, check the Oracle iAS licensing guide for the overlapping middleware exposure.
Run inventory this quarter regardless of destination; you cannot make the decision without knowing where Oracle Java actually runs. If you are on the free Oracle JDK 21 build, treat September 16, 2026 as a hard deadline and start the migration program now to finish inside 9 to 14 months. Defend your contractor headcount before any subscription conversation, because that is where 18 to 28 percent of the quoted cost hides. Pick one primary OpenJDK distribution, clean CI/CD and workstations as rigorously as production, and document every step for audit defense. For the broader exit mapping, our Exiting Oracle Java SE migration map complements the decision and execution work laid out here.
For most enterprises, full OpenJDK migration is the correct answer because the per-employee subscription prices Java against your entire headcount regardless of actual usage. Subscribing is only defensible with a hard Oracle-only dependency such as GraalVM Enterprise, a very small estate where migration will not pay back inside 18 months, or a regulatory need for Oracle's specific contractual terms.
Oracle JDK 21 is free under the NFTC license only until September 16, 2026, with the last free update shipping in July 2026. After that, continued production use defaults to the paid Java SE Universal Subscription billed per employee. If any part of your estate runs the free JDK 21 build, plan to complete migration before that date.
In our experience a full-estate migration runs 9 to 14 months from kickoff to Oracle Java removed from production. The calendar is dominated by discovery and third-party application remediation, not the runtime swap itself, which is technically low-risk because OpenJDK shares Oracle's codebase for the same feature version.
A hybrid rarely saves what buyers expect, because the subscription is priced on total counted employees regardless of how many servers run Oracle Java. Keeping even one subscribed server can force you to license your entire headcount. Hybrid only works if the remnant fits a legacy NUP or Processor contract, or if you fully retire Oracle Java before the renewal that would trigger the full-headcount charge.
Migration reduces audit exposure over time, but the risk during and after is real because Oracle's primary trigger is the download log, and GLAS now contacts OpenJDK users too. Keep dated migration records, prove Oracle downloads have stopped, and remove Oracle JDK from CI/CD and developer machines, not just production, since those persist as download-log entries.
The choice is a support and lifecycle decision, not a technical one, since the runtime is equivalent across builds for a given version. Standardize on one primary distribution (Temurin for vendor neutrality, Corretto or Microsoft for cloud-aligned estates, Azul or Red Hat for a paid SLA) and permit at most one exception build for a specific platform constraint.
Oracle Java SE Universal Subscription bills every employee, not just developers. The 2026 buyer guide to the cost math, audit exposure, and OpenJDK migration.
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.
