The October 2026 Critical Patch Update, not September 2026, is the real deadline, which leaves most large estates four quarterly waves to retire Oracle JDK 21
Oracle's last free NFTC update for JDK 21 lands in the September 2026 CPU, and the October 2026 CPU is the first one that requires a Java SE Universal Subscription at $5.25 to $15.00 per employee per month. Java 11 paid Extended Support expires in the same month, so two waves collide in one freeze window. Sequence by patch exposure and legal entity boundaries, not by headcount of installs, because entity-level exits are what make a 78 percent scope reduction defensible.
Prepared by Redress Compliance · August 24, 2026 · Oracle Java advisory. Migration and audit-defense engagements 2024 to 2026.
Executive summary
The cliff is a patch-supply event, not a shutdown, so the correct sequencing variable is patch exposure across four remaining CPU windows, not install count.
Nothing stops running on October 21, 2026, and the NFTC does not retroactively make an existing JDK 21 deployment unlicensed, but every internet-facing or regulated workload still on Oracle JDK 21 after the October 2026 CPU is either unpatched or billable.
Two expiries land in the same month, so the September 2026 freeze window carries Java 11 Extended Support end-of-life plus the JDK 21 NFTC cutoff at once.
Estates that planned a single Java 21 wave usually discover a second population of Java 8 and Java 11 servers competing for the same change windows, the same test rigs, and the same three regression engineers.
Bill scale is set by headcount, not footprint, so a 12,000-employee enterprise pays roughly $1,188,000 per year at list whether it runs four Oracle JDK installs or four thousand.
That arithmetic means partial migration saves nothing unless it removes an entire legal entity from scope, which is why wave boundaries should follow entity lines rather than application tiers.
Landing on JDK 25 buys about two years of free updates to October 2028, not the eight years some published guides claim. Oracle's own FAQ and blog disagree by a month (September versus October 2028), so plan the next migration to complete inside 2027 and treat 2028 as contingency, not runway.
The migration clock: what actually expires, and when
The date most program plans are anchored to is wrong by one quarter, and the error runs in the buyer's favor only if you catch it.
Oracle's own blog is explicit: the release of Oracle JDK 25 in September 2025 opened the one-year transition window for NFTC users of JDK 21, all JDK 21 updates through and including the September 2026 CPU remain under the No-Fee Terms and Conditions.
And updates beginning with the October 2026 Critical Patch Update move to the Java SE OTN license, the same license already governing Java 8, 11, and 17.
That means October 2026 is the first patch you cannot legally take in production without a Java SE Universal Subscription at $5.25 to $15.00 per employee per month.
Azul reads it more conservatively, noting that Java 21 builds from Java.com stay free until September 16, 2026 and that the last free NFTC-licensed Oracle JDK 21 update in practice arrives in July 2026.
Both readings can be true: Oracle's grant runs to September, but the binary many estates actually pull down is the July drop. Plan against July, not September, and treat the extra quarter as buffer rather than runway.
| Item | What ends | Effective CPU or date | Consequence if you miss it |
|---|---|---|---|
| Oracle JDK 21 (NFTC) | Free updates | September 2026 CPU (last free); October 2026 CPU first paid | Subscription required to patch, $5.25 to $15.00 PEPM |
| Java.com JDK 21 binaries | Free download and use | September 16, 2026 | Consumer download path closes |
| Practical last free binary (Azul reading) | Free NFTC build delivery | July 2026 CPU | Two fewer patch cycles than the plan assumes |
| GraalVM for JDK 21 | NFTC terms | October 2026 CPU | Moves to GraalVM OTN License, second inventory line |
| Oracle JDK 22, 23, 24 (non-LTS) | NFTC grant | September 2026 | Six months of patches post-release only |
| Java 11 paid Extended Support | Vendor patching | September 2026 | Second wave collides in the same freeze window |
| Oracle JDK 25 (landing zone) | NFTC grant | October 2028 (Oracle blog) vs September 2028 (Oracle FAQ) | Two years, not eight; sources conflict |
Correct the record inside your own program documents before anything else. At least one widely circulated migration guide claims Java 21 is free until September 2028 and Java 25 free until September 2033, "8 years." Both figures are wrong and both conflict with Oracle's primary sources.
JDK 25 gets roughly two years of NFTC coverage, ending one year after the next planned LTS, and Oracle's blog and FAQ disagree with each other by one month on when that is. If your steering committee is working off the 2033 number, your rollout is under-resourced by a factor of four.
The second thing to correct is the panic framing. Nothing switches off in October 2026. What ends is Oracle's provision of free updates, not your right to keep running Java 21. The license does not reach backward and make an existing deployment unlicensed; it stops the free flow of patches forward.
That distinction is the entire basis for a phased plan: this is a patch-supply event, not a shutdown event, so you sequence by security exposure rather than by calendar. It also means the JDK 25 landing zone is a trap if you treat it as an endpoint.
Two years of NFTC coverage, ending in late 2028 on the more generous reading, is not a destination. Estates that hop 21 to 25 will run this exercise again in 2028.
Our position with clients is to land on a non-Oracle distribution and stop paying the transition tax; the OpenJDK execution guide covers the mechanics of that landing.
Wave design: sequencing by patch exposure, not by install count
Big-bang cutovers fail on estates of this size for a predictable reason: the freeze window is fixed by Oracle's CPU cadence, and a single rollback consumes the whole window. Four waves mapped to the remaining quarterly CPUs gives you a rollback lane in each one.
The ordering rule is patch exposure, meaning how badly an unpatched CVE hurts you and how fast an auditor or regulator would notice, not how many installs sit in a wave. Internet-facing and regulated workloads move first because they are where an unpatched October 2026 CPU becomes a finding.
Internal server-side follows. Developer workstations and CI come third, because build-time JDK swaps surface compatibility breaks cheaply and your engineers are the ones who can fix them.
Embedded and third-party-bundled runtimes go last, and they go last for a hard reason: you do not control the vendor's release train, so that wave's duration is set by someone else's roadmap. Start the vendor letters in wave one even though the wave executes in wave four.
| Wave | Target CPU | Workload class | Typical share of estate | Primary risk |
|---|---|---|---|---|
| 1 | Jan 2026 | Internet-facing, regulated, PCI/HIPAA scope | 5 to 10% | Regulator visibility, CVE exposure |
| 2 | Apr 2026 | Internal server-side, middleware, batch | 25 to 35% | App compatibility, cert chains |
| 3 | Jul 2026 | Developer workstations, CI/CD, build agents | 15 to 20% | Build breakage, toolchain pinning |
| 4 | Oct 2026 | Embedded runtimes, third-party-bundled JDKs | 40 to 50% | Vendor release train outside your control |
Two constraints shape wave sizing. First, the Employee metric carries an overlooked ceiling: you may install and run on up to 50,000 processors, exclusive of desktop and laptop processors, and exceeding it requires additional license.
Heavy server-side fan-out, containerized JVMs in particular, can approach that ceiling faster than headcount suggests, so count processors in waves one and two rather than assuming the employee metric is unbounded. Second, desktop Java is the loudest install count and the lowest patch risk.
It is explicitly outside the processor ceiling, it is rarely internet-facing, and it is where third-party dependencies cluster. Putting it early because it dominates the inventory report is the most common sequencing error we see.
Where a vendor ships Oracle Java inside its product, the licensing question is separate from the technical one; who is actually licensed for embedded JDKs determines whether wave four is your problem or theirs.
Defend an Oracle Java audit without overpaying
Oracle now audits Java SE on employee count, not installs, which can multiply the bill several times over. How to defend the notice and exit to OpenJDK.
Get the white paper →Why entity boundaries beat application tiers as your wave lines
Under the Employee metric, technical progress and financial progress are unrelated variables.
Oracle's price list defines "Employee" as all your full-time, part-time and temporary employees plus all full-time, part-time and temporary employees of your agents, contractors, outsourcers and consultants that support your internal business operations.
And it states plainly that the licensed quantity is determined by the number of Employees, not the number who actually use the Programs.
That single sentence collapses the entire logic of application-tier phasing. A 12,000-employee enterprise pays $1,188,000 per year at list whether it runs four Oracle JDK installs or four thousand. Migrate 3,900 of those four thousand installs and the invoice does not move by a dollar.
The only thing that moves the invoice is removing a population of employees from the counted base, and populations of employees are attached to legal entities, not to application tiers.
Work the two plans side by side. Plan A is the one most estates build first: rank applications by patch exposure and business criticality, pick the top 200, migrate them across all 14 legal entities in the group.
Twelve months later you have removed Oracle JDK 21 from your most exposed workloads, you have real risk reduction, and your renewal quote is identical because all 14 entities still have Oracle Java somewhere.
Plan B targets three subsidiaries, clears every Oracle binary from every server, container image, desktop, and vendor-shipped runtime inside those three entity perimeters, and leaves the group's most exposed applications for wave two.
Plan B produces a worse patch posture at month twelve and a materially better commercial position, because it is the only plan that can support the divestment-style scoping argument we have modelled at roughly 78 percent off a group baseline: licensing only the legal entities that still run Oracle Java after a partial migration.
The risk-first objection is legitimate and should not be waved away. If patch exposure does not drive sequencing, you are knowingly running unpatched internet-facing Java into and past the October 2026 CPU. The resolution is that these two ordering principles operate at different altitudes.
Entity lines set the wave. Patch exposure sets the order inside the wave. Within subsidiary three, you clear the internet-facing estate first, then the internal server tier, then desktops, then the vendor-embedded runtimes that nobody logged in the CMDB.
Across waves, you accept that a high-exposure application in subsidiary nine waits, and you compensate with compensating controls: network isolation, WAF rules, and where necessary a paid bridge on a small named footprint. The residual risk is bounded and priced.
Unfocused technical progress across 14 entities is not.
There is a second reason entity boundaries win: they are the only wave lines that survive contact with Oracle's own audit questions. Oracle will not dispute that you removed a JDK from a server. It will dispute whether the entity you carved out is a real entity. Expect three specific probes.
First, shared services: if the migrated subsidiary consumes payroll, ERP, or service desk from a group shared services function that still runs Oracle Java, Oracle will argue the subsidiary's employees support, and are supported by, an Oracle Java environment.
Second, outsourcer and contractor staff, who are explicitly inside the definition and who are frequently counted against the group rather than the entity.
Third, the CMDB itself, where entity attribution on assets is usually stale, inherited from an acquisition three years ago, and contradicted by the HR system of record.
So the boundary has to be true in three places simultaneously, and the migration plan must generate evidence in all three. It must be true in HR: a defensible employee headcount per entity, including contractors, with an attestation date.
It must be true in the CMDB and in discovery output: zero Oracle binaries attributed to that entity's asset population, including images, embedded runtimes shipped by third-party vendors.
And GraalVM for JDK 21, which moves to the OTN license on the same October 2026 CPU and is the most commonly missed inventory line.
And it must be true in the contract: the subscription's licensed entity list, affiliate definition, and any change-of-control or divestiture language have to name what you are excluding.
Our execution work on this is set out in the OpenJDK migration execution guide, and the third-party question is unpacked in when a vendor ships Oracle Java inside its product.
Practical consequence for your wave map: draw the lines first from the legal entity register and the HR headcount file, then overlay the application portfolio, then sequence inside each block by patch exposure.
If an entity's Oracle footprint is 12 applications, put it in wave one regardless of how boring those applications are, because it converts to headcount removed.
If an entity's footprint is 400 applications with deep vendor-embedded dependencies, it belongs in the final wave and probably belongs in a negotiated paid subscription scoped to that entity alone.
| Wave line chosen | Technical outcome at month 12 | Effect on Employee count billed | Audit defensibility |
|---|---|---|---|
| Application tier (top 200 apps, all 14 entities) | Best patch posture | Zero change, all 14 entities still in scope | Strong technically, worthless commercially |
| Legal entity (3 subsidiaries cleared fully) | Weaker patch posture, compensating controls needed | Removes 3 entities' headcount from base, modelled at up to 78% off group baseline | Only if HR, CMDB, and contract agree |
| Hybrid (entity sets wave, exposure sets order within wave) | Acceptable posture, bounded residual risk | Same headcount reduction as entity plan | Strongest, evidence generated per entity |
The table's uncomfortable reading is that the middle row buys the savings and the top row buys the sleep. Most estates instinctively build the top row because it is what a risk register rewards and what an application owner will fund.
The hybrid row is the only one that satisfies both, and it works only because the two ordering rules never compete: entity lines decide which block moves, patch exposure decides what moves first inside that block.
One warning the table cannot carry. A 78 percent reduction is a modelled outcome, not a contractual entitlement. Oracle has no obligation to accept entity-scoped licensing and will open by insisting the group is the licensable unit.
What makes the argument stick is not the percentage, it is the evidence pack: entity-level headcount attested by HR, discovery output showing zero Oracle binaries per excluded entity, and contract language that already recognises those entities as separable.
Build the pack during the migration, not after the renewal quote arrives.
Freeze windows, rollback, and the September 2026 collision
Freeze windows should be anchored to the quarterly CPU cadence, not to your fiscal or calendar quarters, because the CPU date is what changes your license position. The last free NFTC update for JDK 21 ships in the September 2026 CPU; the October 2026 CPU is the first that requires a subscription.
That gives you four usable quarterly waves. The complication is that Java 11 paid Extended Support expires in the same month, so the September 2026 window absorbs two migrations at once: NFTC users falling off JDK 21 and paying customers falling off Java 11 Extended Support.
Assume that window is oversubscribed for change capacity, vendor support attention, and third-party ISV certification turnaround. Anything you can pull into the March or June 2026 CPU windows should be pulled forward.
Rollback is where phased Java plans quietly fail, because the fallback binary is the Oracle binary you are trying to prove you removed.
Rolling back a single service to Oracle JDK 21 on October 15, 2026 recreates a license event and, worse, a download log entry and a telemetry check-in that Oracle can later cite as evidence of continued use.
Design rollback in CPU cycles, not days: keep a dual-runtime coexistence period of one full CPU quarter per wave, where both runtimes are installed and the switch is a configuration change rather than a reinstall. That way rollback never requires a fresh Oracle download after the cutoff.
Before wave one begins, close the telemetry path as described in our guide on blocking Oracle Java update check-ins, and record the block date, because that timestamp becomes part of your evidence pack.
Set a hard rule that no post-October 2026 rollback may pull a binary from Oracle.
If a workload fails on the replacement JDK after the cutoff, the fallback is the cached pre-cutoff Oracle binary already on the host under NFTC terms, or it is a rollback to the previous application release, not a new acquisition.
Anything else converts an operational incident into a licensing admission.
The mechanic that matters most here is boring and easy to skip: freeze the estate on the CPU calendar and give every wave a full quarter of dual-runtime coexistence. A one-week rollback window forces a reinstall under pressure, and pressure is exactly when someone downloads from Oracle.
A one-quarter window makes rollback a config flip with no download, no telemetry, and no new evidence against you.
What we see in the field: recurring patterns across large estates
The enforcement picture behind this deadline is not speculative. Gartner has estimated that roughly one in five organizations running Oracle Java will face an audit, and Azul's survey work found that 21 percent of respondents had already been through an Oracle Java audit.
Set against that, understand what Oracle actually has: no agent, no remote scanning capability, no telemetry that reaches into your estate uninvited.
What Oracle has is download logs tied to Oracle accounts, My Oracle Support sign-in records, the answers your own people give during a soft audit email exchange, and LMS scripts that you have to agree to run. Every one of those is a disclosure you control.
That asymmetry is the entire reason a phased migration is worth sequencing properly rather than executing in panic: the evidence Oracle builds its case on is evidence you supply.
Gartner has estimated roughly one in five organizations running Oracle Java will be audited.
Azul's survey found 21 percent of respondents had already faced an Oracle Java audit.
The failure patterns repeat with tedious consistency across large estates. First, GraalVM is missed entirely in inventory, even though Oracle confirmed that GraalVM for JDK 21 moves to the GraalVM OTN license from the October 2026 CPU alongside the JDK itself.
Second, third-party bundled JDKs surface in the final wave, when the schedule has no slack left, because the ISV shipped an Oracle runtime inside its installer and nobody read the redistribution terms.
That question of who is actually licensed when a vendor ships Oracle Java inside its product is worth settling in wave one, not wave four. Third, teams assume non-LTS builds 22, 23 and 24 are safe; they are not, they ride the same September 2026 NFTC expiry.
Fourth, legacy perpetual Java SE Advanced holdings get counted as credit against the Universal Subscription. They earn nothing. They are audit cover and migration runway, and that is all they are. Fifth, budgets add a 22 percent support uplift on top of the subscription price.
There is no such line on the Universal Subscription, and that error inflates a business case by more than a fifth before anyone starts negotiating.
- Percentile standing for your exact deal size and industry, from real closed transactions
- Scenario simulation before the call: test alternative terms and see the financial impact of each
- A negotiation playbook, talking points, and a two page executive brief on day one
Your first five moves
- Fix the calendar to the CPU cadence, this quarter. Rewrite any plan citing 2028 or 2033 as the JDK 21 free-support horizon (both figures circulate in widely-read migration guides and both are wrong), anchor every milestone to the October 2026 CPU as the first paid update, and treat JDK 25 as a landing zone that buys until 2028 at best, not eight years.
- Run a full inventory before you design a single wave. Include GraalVM for JDK 21, non-LTS builds 22, 23 and 24, runtimes embedded inside third-party applications, developer laptops, container base images and build agents; anything you discover after wave two becomes a scope problem you cannot price, and the OpenJDK execution guide sets out the discovery sequence that surfaces embedded runtimes early.
- Redraw wave boundaries onto legal entities, then prove them. Reconcile entity structure against HR headcount data and the CMDB so that each wave retires Oracle Java from a complete, nameable legal entity, because entity-scoped exits are what make a partial subscription defensible (we have modelled reductions around 78 percent off a group baseline where the boundaries held).
- Lock the September 2026 freeze window now, not in mid-2026. Java 11 paid Extended Support expires in the same month as the JDK 21 NFTC grant, so two waves land in one change-control window; book it with the change board twelve months out, define the rollback trigger per wave, and refuse late additions to that window.
- Stage removal evidence against Oracle's Q4, March through May. Capture per-entity proof of uninstall, replacement vendor deployment and download-account closure as each wave completes, so that by spring you can either negotiate an entity-scoped subscription from a position of documented reduction or hold a defensive audit line without improvising the paperwork.
Frequently asked questions
Is the Java 21 deadline September 2026 or October 2026?
Both, depending on what you are measuring. The last free NFTC update for Oracle JDK 21 is delivered in the September 2026 Critical Patch Update, and the October 2026 CPU is the first update that requires a paid Java SE OTN license.
Plan freeze windows against the quarterly CPU cadence, because Azul's guidance suggests the July 2026 CPU may be the last free binary that many estates actually pull.
Does Oracle Java stop working after September 2026?
No. What ends is Oracle's provision of free updates, not your right to keep running the binaries you already deployed. The NFTC does not reach back and make an existing JDK 21 deployment unlicensed.
The exposure is that you stop receiving security patches, and any new update you install from October 2026 onward triggers a subscription obligation.
How long does Java 25 stay free?
Oracle's blog states JDK 25 updates remain under the NFTC until October 2028, one year after the next planned LTS (Java 29). Oracle's own JDK License FAQ says September 2028. Ignore third-party guides claiming free support until 2033, which contradict Oracle's primary sources.
Sequence your estate to land well inside 2027 rather than betting on the later reading.
Does migrating half the estate cut the Java subscription bill in half?
No. The Java SE Universal Subscription is priced on total employees, not Java footprint, so a 12,000-employee enterprise pays roughly $1,188,000 per year at list whether it runs four installs or four thousand.
The only phasing that reduces cost is one that removes entire legal entities from scope, which can support a divestment-style scoping argument modelled at up to 78 percent off a group baseline.
Does GraalVM fall under the same deadline?
Yes, and it is the most commonly missed inventory line. Beginning with the October 2026 CPU, GraalVM for JDK 21 updates move to the GraalVM OTN License Including License for Early Adopter Versions.
Any GraalVM for JDK 21 install left in place after that CPU carries the same exposure as an Oracle JDK 21 install.
What about non-LTS versions like Java 22, 23 and 24?
They ride the same clock. Versions 21, 22, 23 and 24 remain free under the NFTC only until September 2026. Non-LTS Oracle Java also receives patches for only six months after release, with twelve months from release to reach an LTS for the NFTC grant to stay valid.
Treat every non-LTS install as an immediate wave-one candidate.
How does Oracle find out we are still running Oracle Java?
Oracle has no agent on your systems and cannot remotely scan servers. The dominant targeting signal in 2026 is download history, particularly signing in to fetch updates from My Oracle Support, supplemented by voluntary disclosure during soft audits and LMS scripts during formal audits.
That is evidence of downloads, not deployments, which is why your removal evidence and download hygiene matter more than install counts.
