OpenJDK migration as a ULA exit path

By the Meridian advisory team, former Oracle LMS and GLAS licensing analysts. Updated 4 June 2026.

Can migrating to OpenJDK end an Oracle Java obligation?

Yes, where the migration is complete. OpenJDK is a separate, openly available distribution of the Java platform that does not require an Oracle Java subscription, so once every Oracle Java runtime has been replaced with an OpenJDK build and the Oracle binaries removed, the dependency that drives the Oracle obligation is gone. The single condition is completeness. A migration that covers ninety percent of the estate does not reduce the obligation by ninety percent, because any remaining Oracle Java keeps the requirement alive, and Oracle can see the downloads and installations that prove it is still there. The path works, but only when it is finished and evidenced.

Why OpenJDK changes the Java decision

For a ULA holder, Java usually comes down to three options: certify the Java ULA into perpetual licenses, move to the Java SE Universal Subscription priced on headcount, or remove the Oracle dependency by migrating to OpenJDK. The first two keep you in a commercial relationship with Oracle for Java; the third ends it. That makes OpenJDK the option that changes the shape of the decision rather than just its price, and it deserves to sit in the model from the start rather than as a fallback. We compare the first two paths in Java ULA versus the employee subscription, and a migration belongs alongside them as a genuine third route.

How an OpenJDK migration works as an exit

Discover every Oracle Java instance

The migration begins with discovery, because you cannot remove what you have not found. Oracle Java appears on servers, on desktops, inside bundled third party applications, and in build pipelines and container images. A migration plan built on a partial inventory will leave residue, so the discovery has to be thorough and repeatable, and it should produce the same kind of evidence file that supports any certification.

Replace with an OpenJDK build

Each Oracle Java runtime is replaced with an equivalent OpenJDK build at a matching version. For most applications this is straightforward, because OpenJDK and Oracle Java share the same platform specification, but some workloads depend on Oracle specific tooling or commercial features, and those need attention before they are moved. Testing at the application level is what turns a plan into a safe migration.

Remove the Oracle binaries

Replacement is not removal. The Oracle Java binaries have to be uninstalled, not merely superseded, because an installed but unused Oracle runtime is still an installed Oracle runtime as far as an audit is concerned. This step is where incomplete migrations fail, and it is the one that most needs a verification pass.

Evidence the removal

Finally, document the end state. A record that shows Oracle Java was present, was replaced, and was removed, with the dates and the scope, is what lets you stand behind the migration if Oracle asks later. Evidence is as important here as it is at a certification, because the claim you are making is that the dependency is gone.

A worked illustration

Take an indicative organisation weighing a Java SE Universal Subscription against a migration. The subscription would bill annually on its full headcount for as long as it ran Oracle Java anywhere. Instead it runs a structured migration: it discovers every Oracle Java instance across servers, desktops, and bundled applications, replaces each with an OpenJDK build, uninstalls the Oracle binaries, and documents the end state. Once complete, the recurring Oracle Java cost ends, replaced by the cost of maintaining OpenJDK, which for many estates is materially lower. The figures are indicative and the saving depends on the estate and the headcount, but the structural change is real: the migration removes the dependency that the subscription was pricing.

Step	What it achieves	The failure mode it prevents
Discover	A complete Oracle Java inventory	Hidden residual installs
Replace	OpenJDK builds in place	Broken applications
Remove	Oracle binaries uninstalled	Installed but unused Oracle Java
Evidence	A defensible end state record	An undefendable audit position

What is the main risk in an OpenJDK migration?

The main risk is residual Oracle Java left behind, on a forgotten server, on a fleet of desktops, or bundled invisibly inside a packaged application. Because Oracle can identify downloads and installations, an incomplete migration leaves an audit exposure even after the organisation believes it has moved off, and that exposure can be larger than expected because it is assessed against the whole organisation under the current subscription metric. Thorough discovery, complete removal, and documented evidence are the entire defense, and the risk that follows any Java exit, including a migration, is set out in the Java audit risk after a ULA exit.

Where this leads

OpenJDK migration is the one Java path that ends the Oracle relationship rather than repricing it, and its value rests entirely on completeness. Discover every instance, replace each with an OpenJDK build, uninstall the Oracle binaries, and document the end state, then keep that evidence as your defense. Model it against certifying and against the subscription before you commit, because each estate is different. The full treatment of leaving an Oracle agreement cleanly lives in our pillar, the ULA exit strategy guide.

The takeaway

Migrating to OpenJDK ends an Oracle Java obligation when it is complete, because it removes the dependency rather than negotiating a count. The risk is residual Oracle Java left behind, which keeps the obligation and the audit exposure alive. Discover thoroughly, replace and uninstall completely, and evidence the end state, then weigh the migration against certifying and subscribing on the numbers for your estate.