Why most enterprises migrate
The migration decision follows directly from the employee metric. Because the Java SE Universal Subscription prices Java against total workforce rather than deployment, the typical enterprise, which adopted Java when it was free and never built a Java centric business, faces a cost out of all proportion to its actual use. When the alternative is a free runtime that is functionally identical, the business case for migration writes itself.
The scale of the saving is what makes this the highest leverage move in Java licensing. An organisation facing a six or seven figure annual subscription for Java that runs on a modest number of servers can, through a disciplined migration, reduce that recurring cost to zero. There are few licensing decisions where the upside is so large and the technical risk so contained. This article sits beneath the Oracle Java licensing pillar and assumes the cost case has already pointed toward exit.
Is migration actually feasible?
For the overwhelming majority of workloads, yes, and the reason is technical. The free OpenJDK distributions are built from the same OpenJDK source code that Oracle JDK is built from, so the runtime behaviour, the APIs, and the performance characteristics are equivalent. Replacing Oracle JDK with Eclipse Temurin, Amazon Corretto, or a certified build such as BellSoft Liberica is, for a standard application, a matter of installing the new runtime and pointing the application at it, with no change to the application code itself. The detailed equivalence and the differences that do exist are set out in the OpenJDK versus Oracle JDK comparison.
The migration is rarely a coding project. It is an inventory project. The hard part is knowing where every Oracle binary lives.
The genuine exceptions are narrow. Applications that depend on Oracle's specific commercial features, a small set of capabilities that were never part of the open source builds, require either replacement of those features or a continued Oracle relationship for the affected systems. Some third party software ships with a particular Java requirement, and a few vendors certify only against Oracle JDK. These cases are real but rare, and identifying them precisely is part of the feasibility assessment rather than a reason to abandon the migration wholesale.
The migration in five steps
A defensible migration follows a consistent sequence. Each step produces an artefact that becomes part of the evidence base, so the work is structured from the outset to be auditable.
- Discover. Inventory every Java runtime across the estate, servers, desktops, build pipelines, containers, and embedded instances, recording the vendor, version, and source of each. This is the foundation and the step most often done incompletely.
- Classify. Separate Oracle JDK instances from existing OpenJDK and from Java bundled inside third party products, and flag any use of Oracle commercial features.
- Select. Choose the target OpenJDK distribution or distributions, matched to platform and support needs, and validate the chosen builds against representative workloads.
- Replace. Roll out the new runtime, decommission the Oracle binaries, and update build and deployment automation so that no pipeline reintroduces Oracle JDK.
- Evidence. Produce a final inventory demonstrating that no Oracle JDK remains and that no Oracle commercial feature is in use, retained as the record of compliance.
The sequence is deliberately bracketed by inventory work, because the value of the migration is destroyed if a single Oracle binary survives undetected. The same discovery discipline underpins our Java advisory service and broader audit defence engagements.
The evidence Oracle expects
A migration is only as good as the proof that it is complete, because Oracle's compliance posture does not reset when you stop paying. Oracle retains download telemetry, the record of Oracle JDK downloads tied to your corporate domain, and may use it to open a review months or years after you have moved on. The defence against that review is a documented inventory, dated and retained, showing that every Oracle JDK instance identified in discovery was removed and that the estate now runs only free, non Oracle Java.
| Evidence artefact | What it proves | When it is needed |
|---|---|---|
| Pre migration inventory | Scope of Oracle JDK before exit | Establishes the baseline |
| Removal log | Each Oracle binary decommissioned | Rebuts a residual install claim |
| Post migration inventory | Estate now free of Oracle JDK | Core defence in a review |
| Commercial feature audit | No Oracle only features in use | Closes the feature exposure |
| Pipeline configuration | No automation reintroduces Oracle JDK | Prevents silent regression |
Holding this evidence converts a potentially open ended audit conversation into a short one. When Oracle points to historical download data, the customer that can produce a dated post migration inventory closes the question rather than negotiating it. The mechanics of how these reviews begin are detailed in the Java audit triggers guide.
The pitfalls that sustain a claim
Most failed migrations fail in the same predictable ways, and all of them are discovery failures. The forgotten build server still compiling against Oracle JDK. The developer laptop with a local Oracle install. The container base image that bundles Oracle JDK without anyone noticing. The legacy desktop application that was deferred and quietly kept running Oracle Java. Any one of these can sustain an Oracle claim against the entire employee population, because the metric does not scale with the size of the residual deployment; a single licensable instance can, in Oracle's reading, require the whole subscription.
The other recurring pitfall is the unexamined commercial feature. An application may run on a free OpenJDK build yet still invoke a capability that is licensable only under Oracle, leaving exposure even though the binary itself is free. Catching this requires checking not just which Java is installed but how it is used, which is why the classification step is as important as the discovery step. These are precisely the gaps an Oracle review is designed to find.
Timing the exit
When to migrate depends on the customer's current position. An organisation with no Oracle Java agreement and exposure based only on historical downloads should move quickly and quietly, completing and evidencing the migration before any Oracle outreach forces a reactive timetable. An organisation holding a current Universal Subscription should align the migration with the renewal date, so that it can decline renewal having already removed the requirement.
The most favourable position belongs to holders of a legacy per processor subscription, who can carry out the migration under the cover of an agreement that still provides licensed use, removing the requirement entirely before the legacy terms lapse. In every case the principle is the same: control the timetable, finish before Oracle sets the clock, and never let a soft audit email dictate the pace of the exit.
The buyer side view
The practical takeaway is that migration is the default rational response to Oracle's Java pricing for most enterprises, and the only real risk lies in doing it incompletely. The technology is equivalent and free; the saving is large and recurring; the single thing that can go wrong is a surviving Oracle binary that nobody inventoried. Treat the migration as an inventory and evidence project first and a technical project second, and the risk collapses.
Discover exhaustively, classify carefully, replace cleanly, and document everything so the exit is defensible years later. Time the move to your contractual position, and never let Oracle's outreach set your schedule. For most organisations this single project turns a recurring seven figure cost into zero. Begin with the Java licensing pillar for the full picture, the distribution comparison to choose a target, and the Java advisory service to run the migration as a controlled, evidenced programme.
Migrating off Oracle Java: frequently asked questions
Is it hard to migrate off Oracle Java?
For most applications it is a binary substitution with no code change, because the free OpenJDK distributions are built from the same source as Oracle JDK. The difficulty is evidentiary: finding every Oracle JDK instance and proving its removal. The technical equivalence is detailed in the OpenJDK versus Oracle JDK comparison.
Which OpenJDK distribution should I migrate to?
Common production choices include Eclipse Temurin, Amazon Corretto, the Microsoft Build of OpenJDK, Azul Zulu, and Red Hat builds. All provide free, long term supported builds with no Oracle subscription; the right one depends on platform and support needs.
Can Oracle still audit me after I migrate off Oracle Java?
Yes. Oracle can raise a review based on historical download telemetry, which is why the migration must be evidenced. A single remaining Oracle JDK can sustain a claim, so retain a dated post migration inventory. See the Java audit triggers guide.