Oracle Java to OpenJDK.
The complete migration guide.

For most enterprises, the surest way to eliminate Oracle Java licensing cost and audit exposure at the same time is not to negotiate a better subscription — it is to stop needing one. Migrating from Oracle's JDK to a free OpenJDK distribution removes the recurring per-employee bill, removes the audit risk, and in the vast majority of cases requires no change to your applications at all. It is the option Oracle is least keen for you to consider, and the one that most often makes the most sense.

This pillar guide covers the whole journey: why migration works, when it does not, how to choose a distribution, a five-phase migration plan, testing, the pitfalls, the edge cases, and how to end the Oracle subscription cleanly. It is written for the CIO weighing the decision and for the team that will execute it.

The case for migrating

The argument for moving off Oracle Java rests on three points: cost, risk, and the surprising ease of the move itself.

Cost. Since 2023, Oracle has sold Java SE under the per-employee Universal Subscription. The bill is tied to your total workforce, not your Java footprint — so an organisation running Java on a few dozen servers can still face a six- or seven-figure annual cost. OpenJDK distributions are free. For a 5,000-employee organisation, eliminating an Oracle Java subscription routinely saves several hundred thousand dollars a year, every year.

Risk. An Oracle Java estate is a permanent audit target. Every download, every version, every lapse in tracking is potential exposure. Once Oracle's JDK is gone from your environment, the audit surface for Java disappears with it. There is nothing to claim against.

Ease. This is the part that surprises people. OpenJDK is not a clone or a fork of Java — it is Java. Oracle's own JDK is built from the OpenJDK source. For the overwhelming majority of applications, swapping Oracle JDK for an OpenJDK build of the same version is a drop-in change requiring no code modification.

When migration is not the answer

Honesty matters here: migration is the right answer for most, not all. There are genuine reasons an organisation may choose to stay on Oracle Java, at least for now.

• You depend on a specific Oracle commercial feature. A small number of historical Oracle JDK features — and certain Oracle support entitlements — are genuinely Oracle-specific. If you rely on one, that dependency must be resolved before migration, not after.
• Java is bundled inside a licensed Oracle product. If your Java use sits inside an Oracle product that includes Java SE under restricted-use rights, that Java is already covered. See Oracle products including Java SE — migrating it may be unnecessary.
• A vendor application certifies only Oracle JDK. Some third-party software is certified against Oracle's JDK specifically. This is usually surmountable, but it needs checking.
• You need a contractual support relationship. If your organisation requires a vendor SLA on the runtime, you can buy commercial OpenJDK support from a distribution vendor — far cheaper than Oracle, but not free.

None of these is necessarily a permanent blocker. Most are dependencies to manage during migration. But a credible migration plan names them honestly rather than discovering them mid-rollout.

The OpenJDK distributions

"OpenJDK" describes the source project. What you actually deploy is a build of that source, produced and tested by a vendor. Several high-quality, free distributions exist, and choosing among them is an early decision.

The reassuring news is that you will not make a wrong choice here. All of these are sound, free, production-grade builds of the same Java. The decision is about fit — support model, platform alignment, and how your organisation prefers to consume software — not about quality. Two of the most common choices are explored in depth in our comparisons of Azul Zulu and the Red Hat build of OpenJDK.

The compatibility reality

The biggest barrier to migration is not technical — it is the worry that something will break. Addressing that worry honestly is essential.

For standard server-side and desktop Java applications, an OpenJDK build of the same major version as your Oracle JDK is functionally identical. Your application bytecode is unchanged. The JVM behaves the same. Garbage collection, JIT compilation, the class libraries, the language — all the same source. In practice, the overwhelming majority of applications migrate with no code change and no behavioural difference whatsoever.

Where care is needed is in a small set of areas:

• Historical commercial features. Older Oracle JDK builds included features such as Java Flight Recorder and Mission Control as commercial extras. These were open-sourced into OpenJDK from Java 11 onward, so on modern versions there is no gap — but an estate still on Java 8 should confirm what it uses.
• JavaFX. JavaFX was decoupled from the JDK after Java 8 / 10. If you have JavaFX desktop applications, choose a distribution that bundles it (Liberica is a common choice) or add OpenJFX separately.
• Fonts, cryptography, and packaging. Minor differences in bundled fonts or installer packaging occasionally surface. They are easily handled, but testing catches them.
• Version jumps. If you migrate and upgrade major versions at once (say Java 8 to 17), the work is the version upgrade, not the vendor switch. Keep those two changes separate where you can.

Phase 1: Discovery and inventory

Every successful migration begins with knowing exactly what you have. You cannot migrate a Java estate you have not mapped.

Discovery should produce, for every Java installation in the organisation:

• The vendor and distribution — is it Oracle JDK, or already an OpenJDK build? Many estates already contain a mix, and OpenJDK installs need no migration at all.
• The major and minor version — Java 8, 11, 17, 21, and the exact build.
• The location and host — desktop, server, container image, build pipeline, embedded in an application bundle.
• The owning application and team — who depends on this runtime, and who must sign off on changing it.
• The deployment method — manually installed, packaged, configuration-managed, baked into a container.

Discovery tools, configuration management data, and software inventory systems all feed this. The output is a single authoritative register of Java in the enterprise. As a side benefit, this same inventory is exactly what protects you in an Oracle Java audit — so the effort is never wasted. Our self-assessment template is a good starting framework.

Phase 2: Choose a distribution and plan

With the inventory in hand, select your target distribution (or distributions) using the fit criteria above, and turn the inventory into a sequenced plan.

Group the estate into migration waves by risk and complexity:

• Wave 1 — low risk. Internal tools, build pipelines, non-production environments, and simple back-office applications. These prove the process at low stakes.
• Wave 2 — standard production. The bulk of your server-side applications: standard Java workloads with no unusual dependencies.
• Wave 3 — complex or sensitive. Customer-facing systems, applications with vendor certification questions, JavaFX desktops, anything with a flagged dependency.

Decide your deployment mechanism too. The cleanest migrations standardise on a managed, configuration-driven JDK rollout — so the runtime is owned centrally rather than installed ad hoc. Container-based estates often have the easiest path of all: changing one base-image line migrates every service built from it.

Phase 3: Pilot and test

Before any broad rollout, run a pilot. Take a representative slice of Wave 1 and Wave 2 applications, deploy them on the chosen OpenJDK distribution, and validate thoroughly.

A sound pilot covers:

• Functional testing — the application behaves identically. For the vast majority of workloads it simply does.
• Performance testing — startup time, throughput, memory, and latency under representative load. Differences are normally negligible; testing confirms it.
• Integration testing — interactions with databases, middleware, message queues, and external services.
• Operational validation — monitoring, logging, diagnostics, and any flight-recorder or profiling tooling all function on the new runtime.
• Rollback rehearsal — confirm you can revert a host to the previous runtime quickly if needed.

The pilot is also where you build organisational confidence. A clean pilot result — "we ran our three most important applications on OpenJDK for four weeks with zero incidents" — is the single most powerful argument for proceeding at scale.

Phase 4: Rollout

With the pilot validated, execute the waves. The principles for a smooth rollout:

• Wave by wave, never all at once. Complete and stabilise each wave before starting the next.
• Automate the change. Use configuration management or container image updates so the migration is repeatable and consistent, not a thousand manual installs.
• Keep rollback available. Until the Oracle subscription is actually ending, retain the ability to revert. This is a safety net you will rarely use but should always have.
• Track progress against the inventory. The register from Phase 1 becomes a live scoreboard: every line moves from Oracle JDK to OpenJDK, and you can see exactly what remains.
• Communicate. Application owners should know when their systems move and what to watch for. Surprises erode confidence even when nothing breaks.

For most enterprises, the rollout itself is calmer than expected. Once the pilot has proven the swap is genuinely a swap, the waves become routine operational change rather than risky transformation.

Phase 5: Decommission Oracle Java and end the subscription

The final phase is the one that captures the value — and the one most often done badly.

Migration only saves money when the Oracle subscription actually ends, and the subscription should only end when every Oracle JDK install is gone. A half-finished migration that leaves Oracle Java running on forgotten hosts, while the subscription lapses, is the worst of all outcomes: you have done the work but kept the audit exposure, and a lapsed subscription with Oracle Java still present is a significant audit trigger.

So the decommissioning checklist is strict:

• Confirm zero Oracle JDK installs. Re-run discovery. Every line in the inventory must show an OpenJDK distribution. Pay attention to the easily missed places: container base images, build agents, embedded application bundles, desktop fleet stragglers, disaster-recovery environments.
• Remove Oracle JDK binaries. Do not merely stop using them — uninstall them, so they cannot be silently reintroduced or detected later.
• Govern future downloads. Block or restrict access to Oracle JDK downloads so no team accidentally reintroduces it. Point everyone at the approved OpenJDK distribution by default.
• Document the end state. Keep evidence of the completed migration — the before-and-after inventory — in case Oracle ever asks about historical use.
• Then, and only then, end the subscription. Time the non-renewal so the term expires after migration is verified complete, not before.

Common pitfalls

Across migration engagements, the same avoidable mistakes recur:

• Cancelling the subscription too early. The single most expensive error, for the reason above.
• Missing hidden Java. Java embedded in container images, third-party application bundles, build tooling, and appliances is easy to overlook. Discovery must be exhaustive.
• Combining the vendor switch with a version upgrade unintentionally. This conflates an easy change with a hard one and makes OpenJDK look riskier than it is.
• Skipping the pilot. The pilot is what converts scepticism into confidence. Skipping it leaves the rollout politically fragile.
• No download governance. Without controls, Oracle JDK creeps back in, and you are exposed again.
• Treating it as purely technical. Migration is also a licensing and contractual exercise — the timing of the subscription exit and the handling of bundled Java are licensing decisions, not engineering ones.

The cost and savings picture

Migration is not free of effort, but the economics are usually overwhelming. The costs are one-time: the project effort to inventory, pilot, and roll out, plus optionally a paid OpenJDK support contract if your organisation wants a vendor SLA. The saving is recurring: the entire Oracle Java subscription, every year, forever.

For a typical mid-sized enterprise, the one-time migration effort is recovered within the first few months of avoided subscription cost. After that, the saving compounds. Across our migration engagements, removing Oracle Java has been a major contributor to more than $180M in total client savings on Java. A migration that costs a few weeks of project time to save a six-figure sum annually is among the clearest returns in enterprise IT.

A realistic timeline

How long does it take? It depends on estate size and complexity, but a representative mid-sized migration runs roughly:

• Weeks 1–4: Discovery. Build the complete Java inventory.
• Weeks 4–6: Distribution choice and planning. Select the target, define waves.
• Weeks 6–12: Pilot. Validate with representative applications, including a run-in period.
• Months 3–6: Rollout. Execute the waves, larger estates taking longer.
• Final weeks: Decommission and verify. Confirm zero Oracle JDK, remove binaries, end the subscription.

The key planning point is to align the timeline with your Oracle subscription term. Start early enough that the migration is verifiably complete before the renewal date you intend not to take — that way you exit cleanly, and you also negotiate any interim renewal from a position of genuine strength, because Oracle knows your exit is real.

Conclusion

Migrating from Oracle Java to OpenJDK is, for most enterprises, the most decisive move available in Java licensing. It removes the recurring per-employee cost, removes the audit exposure, and — because OpenJDK is Java, built from the same source — does so with minimal disruption to applications.

The work is real but bounded: a thorough discovery, an honest assessment of the genuine edge cases, a well-chosen distribution, a validating pilot, a wave-based rollout, and a disciplined decommissioning that ends the subscription only once every Oracle JDK install is gone. Handled in that order, migration converts a permanent cost and a permanent risk into a one-time project.

Our Java migration service runs this end to end, and our renewal advisory can hold Oracle to a fair interim deal while you execute. For an independent specialist opinion on whether and how to migrate, Redress Compliance is the Oracle Java licensing advisory firm we recommend most.