Oracle Java migration to OpenJDK, step by step. From first inventory to proof of removal.

The JDK swap is the easy part. An Oracle Java exit succeeds or fails on a complete inventory, blocked build sources and update traffic, answers from vendors who bundle Java, and a removal record that stands up when Oracle audits.

Most Oracle Java advice stops at the decision. It explains that the per employee metric is expensive and that OpenJDK is free, and you should probably leave. That is correct as far as it goes. Migration programs fail later, during execution, and in the same few places each time.

• Undocumented servers. Installs that no inventory ever recorded.
• Bundled runtimes. A third party application that installed Oracle JDK without telling anyone.
• Build automation. A CI pipeline that fetches a paid Oracle build once the free window closes.
• Missing evidence. A removal you cannot prove when Oracle's audit team asks for records.

This guide is for the person who owns the project plan. We have negotiated against Oracle for 25 years, defended its audits, and watched Java migrations both finish and stall. The sections follow the order the work should run in, with the traps that catch experienced teams and the records each phase should leave behind.

A migration that is 95 percent complete still carries the full liability, so the aim throughout is an exit that is finished and documented.

What does staying on Oracle Java cost a typical enterprise?

Staying costs a subscription priced on your whole workforce. On 23 January 2023 Oracle replaced the older Java SE Subscription with the Java SE Universal Subscription and a single per employee metric. The quantity you license is your total employee count, whether or not those people ever run Java.

Oracle's definition of an employee includes full time, part time and temporary employees, plus agents, contractors and consultants. That is why Java moved from a manageable line item to one of the larger Oracle costs in many IT budgets. The rules on who counts are covered in our guide to contractors and consultants in the employee count.

How the list price tiers work

List pricing starts at $15 per employee per month in the 1 to 999 tier and falls to $5.25 in the 40,000 to 49,999 tier. Oracle publishes no rate above 50,000 employees. Independent estimates put the effect of the 2023 metric change at two to five times the prior cost for typical enterprises.

The first row is the arithmetic Oracle prefers you skip. A company with 5,000 employees that runs Oracle Java on 40 servers pays for 5,000 employees, roughly $630,000 a year at list, which implies $10.50 per employee per month. That is about $15,750 per server for software with a free, TCK verified equivalent.

The second row explains why this guide spends so much time on inventory. Removing 36 of 40 servers saves nothing, because the metric does not shrink with usage. The bill only goes away when the last Oracle install is gone and you can show it.

How the numbers change with company size

• 500 employees. At the $15 tier the subscription is $90,000 a year at list. Java usually sits on a few dozen machines owned by one team, so one well run pass can finish the job.
• 5,000 employees. The worked example above, at $10.50 a month. Expect several application owners, a mix of Java 8 and newer versions, and at least a few vendor products with a bundled runtime.
• 45,000 employees. Even at $5.25 the bill is $2,835,000 a year at list. Installs run into the thousands across data centers, cloud images, desktops and acquired subsidiaries, and inventory becomes a program of its own.

Against any of these figures, migration to a free OpenJDK distribution removes the subscription entirely. The project costs staff time, testing and coordination, but you pay it once, while the subscription recurs and grows with headcount.

Our analysis of migration project cost versus staying on the Java subscription models the break even point, and the Oracle Java versus OpenJDK decision guide covers the cases where staying makes sense.

When does free Oracle JDK 21 patching end under the NFTC license?

Free Oracle JDK 21 updates end in September 2026. Oracle's No Fee Terms and Conditions (NFTC) license, introduced in September 2021, allows you to run the current long term support release free of charge until one year after the next LTS release ships. It closed for JDK 17 in 2024 and is closing for JDK 21 now.

JDK 17 left the free window in September 2024; Oracle JDK 17.0.13 and every later update ship under the Oracle Technology Network (OTN) license, which allows personal and development use but not commercial production use without a subscription.

For JDK 21, Oracle states that all updates through September 2026 are available under the NFTC. Starting with the October 2026 Critical Patch Update, due on October 20, 2026, JDK 21 updates switch to the OTN license, and production use requires a paid subscription.

Why your patch pipeline is the real deadline

A patching pipeline that installs an Oracle JDK 21 update released after the boundary date changes your license position on its own, with no approval step. The license change applies to updates released from October 2026 onward. Builds released under the NFTC were licensed on those terms, but they stop receiving free security fixes.

A patching job that fetches the next Oracle build after the NFTC boundary creates a license obligation with no purchase order and no one aware it happened.

Oracle has also started shipping monthly Critical Security Patch Updates alongside the quarterly CPUs. The first arrived on August 18, 2026, the next is targeted for November 17, 2026, and Oracle says to expect several in 2027.

More releases mean more chances for automation to fetch an OTN build, which is why controlling build sources belongs early in the project. The version by version detail sits in our note on JDK 21 updates ending in 2026.

How does Oracle find out you run Oracle Java?

Oracle relies on three discovery channels, and each one should shape your runbook. None of them requires your cooperation.

• Download history tied to Oracle accounts. When someone downloads Java from Oracle's site with a corporate email or an Oracle single sign on account, Oracle logs the IP address, corporate domain, timestamp and account details. That list tells Oracle which companies to approach.
• Update server traffic from your IP ranges. Once installed, Oracle Java's automatic update feature sends a check in to Oracle every time it runs unless someone has disconnected it. Oracle confirms this itself, and every unblocked legacy JRE is a beacon.
• Open source intelligence. Job postings that mention Oracle JDK, public GitHub repositories and product documentation all feed Oracle's targeting.

The practical consequence is timing. Blocking update checks and stopping Oracle downloads is an early step, because each day of continued telemetry strengthens Oracle's argument that you used licensable Java. We run it as a separate workstream, and the mechanics are in the guide to blocking Oracle Java update check ins and telemetry.

How Oracle audits are changing in 2026

In our 2026 engagements, the soft inquiries of prior years are turning into formal audits. The pattern repeats: Oracle License Management Services (LMS), now called Global Licensing and Advisory Services (GLAS), opens with a request for a compliance review. It then asks you to run its scripts across your environment, and those scripts inventory every reachable Oracle Java instance.

Several 2026 renewal letters we reviewed have also dropped the old clause limiting Oracle to one audit every 36 months, which permits audits at any cadence. The shift from LMS to GLAS is covered in what changed in Oracle Java enforcement. If you already have a live inquiry, read the Oracle Java audit guide before you respond to anything.

How do you find every Oracle Java install before migrating?

You find them by combining several discovery methods and reconciling the results, because no single tool sees everything. The JDK swap is rarely the hard part. For standard Java applications the switch is a drop in replacement, and in our experience roughly 80 percent of a typical application portfolio falls into that easy group.

Migrations stall on shadow installs, undocumented Java 8 codebases and applications no one wants to touch. The residual liability after a migration is almost always an inventory failure. Because the metric ignores usage, one forgotten Oracle Java install on one server can in theory price your entire headcount if Oracle audits.

What each discovery method catches

• Software asset management and endpoint agents. Good coverage of managed desktops and servers, weak on containers, appliances and anything outside the agent's scope.
• Filesystem scans. Search for java executables and the release file in each JDK or JRE directory. Scans catch copies unpacked from zip archives that never registered with an installer.
• Package manager queries. On Linux, rpm and dpkg listings show installed JDK packages and their vendor.
• Container image scans. Scan base images and registries, since one Oracle JDK base image can repeat across hundreds of running containers. Our note on Oracle Java in Docker base images covers the licensing side.
• Oracle download and account history. Reconcile what Oracle can see you downloaded against what you found installed, so gaps show up in both directions.

How to tell Oracle JDK from an OpenJDK build

Both report as Java, and only one carries the liability. Run java -version on each binary: Oracle JDK identifies itself as Java(TM) SE Runtime Environment with the Java HotSpot(TM) VM, while OpenJDK builds print OpenJDK Runtime Environment. The release file's IMPLEMENTOR line helps too, but Oracle's own free OpenJDK builds also list Oracle Corporation there.

For each Oracle install, record the version, the dependent application and the owning team, so every removal has an accountable person. The full procedure, including commands and reconciliation logic, is in how to inventory every Oracle Java install before migrating. For the version string edge cases, see distinguishing Oracle JDK from OpenJDK.

Which OpenJDK distribution should replace Oracle JDK?

Any of the four leading distributions will do the job, so pick one and standardize on it. Eclipse Temurin, Amazon Corretto, Azul Zulu and BellSoft Liberica all publish TCK verified builds. Each is certified compatible with the Java SE specification for its version through the Technology Compatibility Kit (TCK), which is why the swap usually needs no application code changes.

One primary distribution keeps patch cadence, packaging and support contracts simple.

The deciding factors are the LTS versions each vendor supports, how long it commits to updates, whether you want a paid support SLA (most offer one while the binaries stay free) and platform fit. Our comparison of OpenJDK alternatives including Temurin, Azul, Corretto and others covers support, patch cadence and migration risk.

Questions to settle before you choose

1. Which of your Java versions, including Java 8, does the distribution still patch, and until when?
2. Do you need JavaFX or a Java Web Start replacement for older desktop applications? Some distributions ship JavaFX bundles and some do not.
3. Will your application vendors certify their products on this distribution, or only on Oracle JDK?
4. If you want paid support, what are the response times, and does the contract cover the older versions you still run?
5. Can the distribution feed your existing package repositories and container registries without manual steps?

How do you test applications before switching JDK vendors?

Test the applications, with their own libraries and settings, on a representative workload before any production change. The pilot replaces Oracle Java with your chosen distribution on a nonproduction system that exercises real behavior. Its purpose is to surface the edge cases TCK compatibility does not guarantee, since proving that Java starts tells you little.

What usually breaks

• Font rendering. Reports, PDFs and desktop screens can lay out differently when the runtime picks up different system fonts.
• Cryptographic providers. Differences in provider configuration and enabled algorithms can break TLS connections or signed file handling.
• Older serialization behavior. Legacy applications that serialize objects across systems may hit changed defaults.
• Third party libraries. Some carry assumptions tied to a specific vendor's runtime.
• JVM tuning flags. Garbage collection and memory settings can behave slightly differently across builds, which shows up only under load.
• Java 8 desktop components. Oracle JDK 8 shipped Java Web Start and JavaFX, which many OpenJDK 8 builds leave out.

For each application in scope, confirm startup, run the functional test suite, run performance and load tests against a baseline, and validate Java integrations such as application servers, agents, monitoring and security tools. Applications on the same major Java version using standard APIs almost always pass unchanged.

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 how to set a performance baseline, is in testing application compatibility when switching JDK vendors.

Why we pilot the hardest applications first

The usual advice is to open with a quick win: migrate a simple, low risk application, show success and build momentum. We disagree, because easy applications pass whenever you reach them, so testing them first tells you nothing about your timeline.

The legacy Java 8 system with a removed API or a vendor specific library decides your end date, so pilot it first while there is still time to fix or replace it. Timebox it without rushing, since a font or cryptography fault found in testing costs a ticket and the same fault in production costs executive support.

What about third party applications that bundle Oracle Java?

Bundled runtimes carry the same Oracle exposure as any other install, so each one needs a written answer from its vendor. Many enterprise applications install their own Oracle Java runtime, and a generic endpoint scan looking for standalone JDK installs never sees it. This phase is what separates a complete migration from a 95 percent one.

For each third party application, establish three things. First, whether it bundles Oracle Java or a redistributable OpenJDK. Second, whether the vendor allows pointing the application at an external JDK. Third, whether the vendor's own license already covers the embedded runtime.

• Identify every application that installs a bundled JVM, beyond the standalone JDK installs.
• Ask each vendor, in writing, whether the bundled runtime is Oracle licensed and whether its agreement covers your use.
• Where the application allows it, repoint it to your standard OpenJDK distribution and remove the bundled Oracle runtime.
• Where it does not, escalate to the vendor for an OpenJDK based release or a covering redistribution license.
• Track each application to closure, because one unmanaged bundled runtime undermines your proof of removal.

Do not assume, and do not accept a verbal answer from a support engineer. The procedure for reconfiguring applications is in migrating third party apps that bundle Oracle Java, and the rules on redistribution rights are in the guide to Oracle Java embedded licensing and OEM distribution.

How should you phase the rollout across a large environment?

Phase by risk and by the number of systems a failure would affect, with each wave gated on the previous one passing validation. Once inventory, distribution choice and testing are done, rollout is a coordination problem more than a technical one. The sequence that works is nonproduction first, then low risk production, then business critical systems.

Package the new OpenJDK build into your standard deployment tooling, such as configuration management, golden images, container base images and package repositories. Adoption then becomes a controlled push instead of manual work on each server.

Remove Oracle JDK from those standard images at the same moment you add OpenJDK. If you only add the new runtime, you have doubled the surface area and proven nothing. The phasing model, including wave sizing and rollback criteria, is in phasing a Java vendor migration across a large environment.

The two rollout disciplines that matter most

First, block the source. Change your internal build pipelines and package mirrors so they can no longer fetch Oracle licensed binaries, which closes the NFTC automation trap for good. Developer laptops and build agents are a common leak, covered in our note on CI/CD and developer workstation cleanup.

Second, keep a running reconciliation between the frozen inventory and the current state. At any moment you should be able to say exactly how many Oracle installs remain and where they are. That count turns rollout activity into audit evidence.

How do you stop Oracle Java from contacting Oracle?

Remove the installs where you can, disable automatic updates where you cannot yet, and block the traffic at the network edge. Every Oracle JRE or JDK that remains installed, even briefly during rollout, attempts update check ins unless disconnected. Oracle logs those check ins, and they become evidence of use.

• Remove Oracle JDK from all standard build images and golden images, so it stops spreading from the source.
• Disable the Java auto update feature on legacy Oracle installs that cannot be removed immediately. On Windows, the Oracle JRE installer configuration file accepts AUTO_UPDATE=Disable for new installs, and the Update tab in the Java Control Panel covers existing ones.
• Block outbound traffic to Oracle's Java update endpoints at the network egress layer, so even an unconfigured legacy install cannot reach Oracle.
• Restrict access to Oracle's Java download sites from corporate networks and accounts, which closes the download history channel.
• Confirm at the network layer that no traffic reaches Oracle Java update servers before you declare the environment clean.

Treat network verification as the acceptance test for this phase. Zero traffic to Oracle Java update infrastructure across a sustained window closes the detection channel and produces removal evidence at the same time.

Platform by platform configuration is in the telemetry guide linked above, and what Oracle sees from an update check in explains the data involved.

What evidence proves Oracle Java removal in an audit?

The proof is a set of records you create while the work happens, covering every install from discovery to removal. A migration you cannot prove is one Oracle can dispute. In an audit the burden of demonstrating your position falls on you, and evidence created at the time outweighs anything you assert later.

Build one removal record for the whole company. Each Oracle install needs its entry in the original inventory, the action taken, the date, and post migration scan results. Add the network evidence of blocked telemetry and the written answers from third party vendors.

Keep the package indefinitely, because Oracle's audit reach can extend years back. Which artifacts hold up and which do not is covered in documenting proof you removed Oracle Java.

What have we seen go wrong in Oracle Java migrations?

The same five failures recur across the migrations we have supported, and each one is avoidable if it is named in the project plan from the start.

Incomplete inventory

This is the dominant failure. Teams trust one discovery tool, miss bundled runtimes and never check Oracle download history. Use several discovery methods, hunt for runtimes inside vendor products, and reconcile against what Oracle can see.

The automation crossing the boundary

A scheduled job fetches an Oracle update released after the NFTC date and relicenses the environment. The fix is to block Oracle binary sources before rollout starts, since blocking them afterwards leaves the gap open for the whole rollout.

Adding OpenJDK without removing Oracle Java

• What happens. Both runtimes sit side by side, and applications with a hardcoded JAVA_HOME or a bundled launcher keep calling the old one.
• What it costs. Scans keep finding Oracle binaries, so the removal record never closes and the subscription stays payable.
• How to avoid it. Define done for each system as Oracle removed and scan confirmed.

Skipping the pilot on legacy applications

Java 8 codebases and applications using removed APIs surprise teams in production. Pilot them first, as described above.

No removal evidence

The migration succeeds technically but cannot be demonstrated when an audit letter arrives. Capture artifacts continuously; reconstructing them months later rarely works.

What will Oracle's account team say while you migrate?

Expect Oracle to push for a subscription before your migration finishes, and to use your download history and any remaining installs to do it. These are the lines we hear most, with the replies that hold up.

If you need a bridge subscription, what should the contract say?

Sometimes a legacy application cannot move before the October CPU and you decide to license for a year. If so, ask for these terms in writing.

• Employee count stated in the order. Record the count Oracle accepted at signing, so any later dispute starts from an agreed number.
• No automatic renewal. The subscription ends on the date your migration plan says it will.
• Past use settled. Written confirmation that the subscription resolves any prior use, so a later audit cannot reopen it. Our guide on pushing back on retroactive fee demands explains why this matters.
• Term length matched to the plan. One year if that is what the plan needs, with no multiyear discount that commits you beyond the exit.

How does the Java exit fit your other Oracle contracts?

Treat it as the first test of a discipline you will reuse elsewhere with Oracle. If you also run Oracle databases, middleware or cloud services, the same sequence applies: inventory, remove dependencies on Oracle licensed components, and document your position before Oracle documents it for you.

• Strategy. Our Oracle Java SE exit map sets out the strategic sequence.
• Renewal in parallel. The 20 critical procurement insights for Oracle Java licensing and renewals cover negotiation if a renewal runs alongside the technical exit.

When a renewal date and a migration deadline fall in the same quarter, sequence them on purpose. Renewing under pressure a subscription you are three months from eliminating commits you to fees for a term you will not need. The technology is the easy 80 percent; the risk sits in inventory completeness, telemetry silence, bundled runtimes and provable removal.

What to do next

1. This week. Freeze Oracle JDK 21 at the last update released under the NFTC and block your pipelines and mirrors from fetching the October 2026 CPU or any later Oracle build.
2. Within two weeks. Block Oracle Java update traffic at the network edge and restrict Oracle Java downloads from corporate accounts.
3. Within a month. Run at least three discovery methods, reconcile them with your Oracle download history, and freeze a dated inventory with an owner for every install.
4. Next. Choose one OpenJDK distribution, then pilot your hardest legacy applications on it before anything else.
5. In parallel. Send written questions to every third party vendor whose product bundles Java, and track each answer to closure.
6. During rollout. Migrate in waves by risk, removing Oracle binaries as you add OpenJDK, and log every action with its date.
7. At close. Run a final scan, export the egress logs, assemble the removal record, and store it with your contract files.

Frequently asked questions