This is the end-to-end operational runbook for removing Oracle Java from your estate and standing up a free OpenJDK distribution in its place. It tells you exactly what to inventory, how to test, how to phase rollout, how to kill Oracle telemetry, and how to prove removal in a way that survives an audit.
This is the end-to-end operational runbook for removing Oracle Java from your estate and standing up a free OpenJDK distribution in its place. It tells you exactly what to inventory, how to test, how to phase rollout, how to kill Oracle telemetry, and how to prove removal in a way that survives an audit.
Most Oracle Java content stops at the decision. It tells you the per-employee metric is expensive, that OpenJDK is free, and that you should probably leave. That advice is correct and useless. The decision is easy. The execution is where migration programs die: on the servers nobody documented, the third-party app that quietly bundles Oracle JDK, the CI pipeline that pulls the next Oracle build after the free window closes, and the removal you cannot prove when Oracle's audit team asks for evidence.
This guide is written for the person who owns the project plan. We have negotiated against this vendor for 25 years, defended the audits, and watched migrations succeed and stall. What follows is the sequence that works, the traps that catch experienced teams, and the specific artifacts you need to produce so that leaving Oracle Java is final and defensible rather than 95 percent complete and still a liability.
On 23 January 2023 Oracle replaced the older Java SE Subscription with a single per-employee metric. This is the fact that turned Java from a manageable line item into a top-tier cost exposure. Under the Java SE Universal Subscription, the quantity you must license is your total employee count, not the number of people who actually run Java. Oracle's own definition includes full-time, part-time, and temporary employees plus agents, contractors, and consultants.
List pricing starts at $15 per employee per month at the 1 to 999 tier and steps down to $5.25 at the 40,000 to 49,999 tier, with no published rate above 50,000 employees. Do the arithmetic that Oracle wants you to avoid. A company with 5,000 employees that runs Oracle Java on 40 servers pays for 5,000 employees, which is roughly $630,000 per year at list, or about $15,750 per server. You are not paying for Java. You are paying a headcount tax that happens to be triggered by Java.
A 5,000-employee company running Oracle Java on 40 servers pays for 5,000 employees. That is $15,750 per server per year for software that has a free, TCK-verified equivalent.
Independent estimates put the metric change at two to five times the prior cost for typical enterprises. Against that, a well-run migration to a free OpenJDK distribution eliminates the subscription entirely. The project cost is real (staff time, testing, rollout coordination), but it is a one-time expense measured against an annual, escalating, headcount-linked liability. If you want the full financial model, our companion analysis on migration project cost versus staying on the Java subscription lays out the break-even math, and the broader Oracle Java versus OpenJDK decision guide covers the cases where staying makes sense.
Oracle's No-Fee Terms and Conditions (NFTC) license, introduced in September 2021, lets you run the current Oracle JDK long-term support release for free until one year after the next LTS release ships. This is a moving window, and it has already closed once and is about to close again.
JDK 17 left the free window in September 2024. JDK 21 receives free NFTC updates only until September 2026. Oracle has stated the last free update to Oracle JDK 21 under the NFTC will be distributed in July 2026, after which JDK 21 updates fall under the Oracle Technology Network (OTN) license and production use requires a paid subscription. JDK 25 will carry NFTC coverage until September 2028.
| Oracle JDK LTS | Free NFTC updates end | Status for a 2026 migration |
|---|---|---|
| JDK 17 | September 2024 | Already licensable if patched past that date |
| JDK 21 | September 2026 (last free build July 2026) | The deadline your project must beat |
| JDK 25 | September 2028 | Longest runway, but still a Oracle-licensed binary |
Here is the trap that catches disciplined teams. A patching pipeline that pulls the next Oracle build after the boundary date silently converts an entire estate from unlicensed-and-fine to licensable-and-owed, with no purchase order, no approval, and no one in procurement aware it happened. The version clock is not just a deadline for finishing your migration. It is a live risk in your automation right now, which is why blocking telemetry and controlling build sources (covered below) is not optional cleanup, it is core to the project.
A patching process that pulls the next Oracle build after the NFTC boundary converts your estate from unlicensed to licensable with no purchase order and nobody aware it happened.
You cannot plan a clean exit without knowing exactly how Oracle detects Java. Oracle uses three primary discovery patterns, and every one of them should shape your runbook.
The operational conclusion is direct. Blocking auto-update pings and removing Oracle download activity is not a nice-to-have at the end of the project. It is an early step, because every day of continued telemetry strengthens Oracle's case that you were using licensable Java. We treat this as a dedicated workstream and cover the mechanics in the guide on blocking Oracle Java update check-ins and telemetry.
On the audit posture: our field experience across 2026 engagements is that the soft inquiries of prior years are turning into formal audits. The pattern is consistent. Oracle License Management Services (LMS) opens with a request for a compliance review, asks you to run their scripts across your environment, and those scripts inventory every reachable Oracle Java instance. Worse, several 2026 renewal letters have removed the historic audit cap language that limited Oracle to one audit per 36 months, permitting audits at any cadence. If you are staring at a live inquiry, read the Oracle Java audit defense playbook before you respond to anything.
The single most important sentence in this guide: the JDK swap is not the hard part, knowing what you have is. For standard Java applications the switch is a drop-in replacement, and in our experience roughly 80 percent of a typical portfolio falls into that easy category. Migrations do not stall on technology. They stall on shadow installations, undocumented Java 8 codebases, and applications nobody wants to touch.
The residual liability after migration is almost always an inventory failure. If you migrate 95 percent of your estate but miss a handful of servers running Oracle JDK, and Oracle audits, those installations can still trigger the full per-employee obligation. Because the metric is decoupled from usage, one forgotten Oracle Java install on one server can theoretically price your entire headcount. That is the asymmetry that makes inventory the make-or-break phase.
Inventory every Java runtime by version, vendor, and dependent application. Do not trust a single discovery method. Combine software asset management data, endpoint agents, filesystem scans for java executables and release files, package manager queries, and container image scans. Reconcile against your own Oracle download history so you know where Oracle-licensed binaries actually landed. The detailed procedure, including the commands and the reconciliation logic, sits in how to inventory every Oracle Java install before migrating.
The technical reason migration works is the Technology Compatibility Kit (TCK). Eclipse Temurin, Amazon Corretto, Azul Zulu, and BellSoft Liberica all publish TCK-verified builds, meaning each is certified compatible with the Java SE specification for its version. TCK verification is why swapping Oracle JDK for one of these is typically a drop-in replacement requiring no application code changes.
Standardize on one primary distribution to keep your patch cadence, packaging, and support relationships simple. The practical decision drivers are the LTS versions each vendor supports, the length of their update commitment, whether you want a commercial support SLA (most distributions offer a paid support tier while the binaries remain free), and platform fit. Do not over-engineer this choice. All four leading distributions are production-grade. Our comparison of OpenJDK alternatives including Temurin, Azul, Corretto, and others covers the tradeoffs on support SLA, patch cadence, and migration risk.
| Distribution | Vendor | TCK-verified | Typical fit |
|---|---|---|---|
| Eclipse Temurin | Eclipse Adoptium | Yes | Vendor-neutral default, broad platform coverage |
| Amazon Corretto | Amazon | Yes | AWS-heavy estates, long-term free updates |
| Azul Zulu | Azul | Yes | Broad version range, strong commercial support option |
| BellSoft Liberica | BellSoft | Yes | Full JRE and native image options, embedded scenarios |
Pilot before you promise. Replace Oracle Java with your chosen OpenJDK distribution on a representative, non-production workload that exercises real application behavior. The goal of the pilot is not to prove that Java runs. It is to surface the edge cases that TCK compatibility does not guarantee: font rendering, cryptographic provider differences, older serialization behavior, third-party libraries with vendor-specific assumptions, and JVM tuning flags that behave subtly differently across builds.
Structure compatibility testing around the applications, not the JDK. For each application in scope, confirm startup, run the functional test suite, run performance and load tests against a baseline, and validate any Java-specific integrations (application servers, agents, monitoring, security tooling). Applications on the same major Java version and standard APIs will almost always pass without change. The ones that need attention are legacy Java 8 codebases, anything using deprecated or removed APIs, and applications with hardcoded assumptions about the Oracle runtime. The full method, including what to test and how to establish a performance baseline, is in testing application compatibility when switching JDK vendors.
TCK verification guarantees specification compatibility, not that your specific application, with its specific libraries and tuning flags, behaves identically. Pilot the applications, not the JDK.
Timebox the pilot but do not rush it. A pilot that catches a font-rendering or cryptography issue in a controlled environment saves you a production incident that would otherwise derail executive confidence in the whole program. Confidence is a resource in these projects. Spend it carefully.
This is the phase that separates a complete migration from a 95 percent one. Many enterprise applications bundle their own Oracle Java runtime, install it silently, and are never captured by a generic endpoint scan looking for standalone JDK installs. These bundled runtimes carry the same Oracle licensing exposure as any other Oracle Java install.
For each third-party application in scope, you need to determine three things: whether it bundles Oracle Java or a redistributable OpenJDK, whether the vendor permits pointing the app at an external JDK, and whether the vendor's own license already covers the embedded runtime. Some vendors ship OpenJDK and there is nothing to do. Some ship Oracle Java under a redistribution agreement that covers you. Some ship Oracle Java and leave the licensing to you, which is the case you must fix. Do not assume. Get it in writing from the vendor. The procedure for handling these, including how to reconfigure apps to use your standard OpenJDK, is in migrating third-party apps that bundle Oracle Java, and the broader rules on redistribution rights sit in the guide to Oracle Java embedded licensing and OEM distribution.
With inventory complete, distribution chosen, and applications tested, rollout becomes a coordination problem rather than a technical one. Phase by risk and by blast radius, not alphabetically. The standard sequence that works is: non-production first, then low-risk production, then business-critical systems, with each wave gated by successful validation of the previous one.
Package the new OpenJDK build into your standard deployment mechanism (configuration management, golden images, container base images, package repositories) so that adoption is a controlled push rather than manual per-server work. Crucially, remove Oracle JDK from your standard build images at the same time you add OpenJDK. If you only add the new runtime without removing the old, you have doubled your surface area and proven nothing. The full phasing model, including wave sizing and rollback criteria, is in phasing a Java vendor migration across a large estate.
Two rollout disciplines matter more than the rest. First, block the source. Update your internal build pipelines and package mirrors so they can no longer pull Oracle-licensed binaries, which closes the NFTC automation trap permanently. Second, keep a running reconciliation between your original inventory and current state, so at any moment you can say precisely how many Oracle installs remain and where they are. That running count is what turns rollout into evidence.
We covered why telemetry matters in the detection section. Here is what to do about it as an execution step. Every Oracle JRE or JDK that remains installed, even briefly during rollout, will attempt automatic update check-ins to Oracle unless disconnected. Those check-ins are logged and become evidence of use.
Treat network-level verification as the acceptance test for this phase. When your egress logs show zero traffic to Oracle Java update infrastructure across a sustained window, you have both closed the detection channel and produced a piece of removal evidence. The detailed configuration for each platform is in blocking Oracle Java update check-ins and telemetry.
A migration you cannot prove is a migration Oracle can dispute. The final and most under-appreciated phase is producing documentation that establishes, on your own records, when and how Oracle Java left your estate. This matters because in an audit the burden of demonstrating your position falls on you, and contemporaneous evidence is worth far more than an after-the-fact assertion.
Build a removal record for the whole estate. It should include the original inventory with every Oracle install identified, the migration action taken for each (removed, repointed, replaced), the date, and post-migration scan results confirming no Oracle-branded binaries remain. Add the network evidence of blocked telemetry. Keep this package indefinitely, because Oracle's audit reach can extend years back. The full evidentiary standard, including which artifacts hold up and which do not, is in documenting proof you removed Oracle Java.
A migration you cannot prove is a migration Oracle can dispute. Contemporaneous removal evidence is worth more in an audit than any after-the-fact assertion.
| Evidence artifact | What it proves | When to capture |
|---|---|---|
| Pre-migration inventory | The full population of Oracle installs you set out to remove | Start of project, frozen and dated |
| Per-install action log | That each Oracle install was removed, repointed, or replaced | During rollout, per system |
| Post-migration scans | No Oracle-branded Java binaries remain | After each wave and at project close |
| Blocked-telemetry network logs | Oracle Java is no longer communicating with Oracle | During and after the telemetry phase |
| Build-source controls | Pipelines can no longer pull Oracle-licensed binaries | At rollout, retained ongoing |
Across the migrations we have supported, the same handful of failures recur. Name them in your project plan so you can design against them.
Java migration rarely happens in isolation. If you carry other Oracle estate (databases, middleware, cloud), the same discipline applies: inventory, decouple from Oracle-licensed dependencies, and document your position before Oracle documents it for you. Our Oracle Java SE exit map frames the strategic sequence, and the 20 critical procurement insights for Oracle Java licensing and renewals covers the negotiation posture if you are handling a renewal in parallel with the technical exit. If a renewal deadline and a migration deadline are competing for the same quarter, sequence them deliberately: you do not want to renew under pressure a subscription you are three months from eliminating.
The bottom line for the person running this project: the technology is the easy 80 percent. Your leverage and your risk both sit in inventory completeness, telemetry silence, third-party bundled runtimes, and provable removal. Execute those four with discipline, beat the September 2026 NFTC clock on JDK 21, and you convert a recurring headcount-linked liability into a one-time, closed project.
For most estates the technical swap is fast because TCK-verified OpenJDK builds are drop-in replacements requiring no code changes. The timeline is driven by inventory completeness, third-party bundled runtimes, and testing legacy applications, not by the JDK swap itself. Plan the project around finding and proving removal of every Oracle install, and start early enough to finish before the September 2026 NFTC deadline for JDK 21.
Eclipse Temurin, Amazon Corretto, Azul Zulu, and BellSoft Liberica are all TCK-verified and production-grade. Choose based on the LTS versions each supports, whether you want a paid support SLA, and platform fit, then standardize on one to simplify patching. Temurin is a common vendor-neutral default; Corretto suits AWS-heavy estates.
Oracle JDK 21 receives free updates under the No-Fee Terms and Conditions license until September 2026, with the last free build distributed in July 2026. After that, JDK 21 updates fall under the OTN license and production use requires a paid per-employee subscription. Your migration should be complete, or your Oracle binary sources blocked, before that window closes.
Oracle uses three discovery patterns: download history tied to corporate emails or Oracle accounts, automatic update check-in telemetry from installed copies, and open source intelligence such as job postings and public repositories. Blocking auto-update traffic and restricting Oracle downloads should be an early execution step, not final cleanup, because ongoing telemetry becomes audit evidence.
Incomplete inventory. Because the Oracle metric is decoupled from usage and priced on total employees, a single missed Oracle install on one server can theoretically trigger the full per-employee obligation in an audit. Use multiple discovery methods, hunt for Java bundled inside third-party applications, and produce provable removal records for every system.
You need to prove it. In an audit the burden of demonstrating your compliance position falls on you, and contemporaneous evidence outweighs any after-the-fact claim. Keep the pre-migration inventory, a per-install action log, post-migration scans showing no Oracle binaries, and network logs confirming blocked telemetry, retained indefinitely given Oracle's multi-year audit reach.
Oracle Java audit defense advisory. Stop the LMS notice in its tracks. SE Universal scope, employee metric defense, third party audit framework.
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.
