The CTO guide to Java migration strategy.

When Oracle moved Java SE to an employee-based subscription, it converted a runtime that engineering had treated as free infrastructure into a recurring, headcount-linked cost — and in doing so, it made the Java runtime a CTO-level question. Migrating off Oracle Java is no longer a procurement footnote. It is a decision about who controls one of the most fundamental layers of your technology stack, what that layer costs, and how exposed your organisation is to a vendor's pricing strategy. This guide treats it accordingly: as strategy, not as a ticket to be closed.

Why this lands on the CTO's desk

For most of Java's history, a CTO never had to think about the Java runtime. It was free, ubiquitous, and binary-stable; engineers downloaded a JDK and moved on. Three changes ended that.

First, Oracle restructured Java licensing repeatedly — from the old BCL, to the restrictive OTN terms, to the current Java SE Universal Subscription priced per employee. The runtime stopped being free and became a contract. Second, Oracle began enforcing that contract through audits, turning latent Java sprawl into quantified financial exposure — claims that routinely reach seven figures. Third, the employee metric coupled Java cost to organisational headcount, meaning the cost now grows independently of any technology decision engineering makes.

Together, those changes mean Java now sits at the intersection of cost, risk and architectural control — three things a CTO owns. Delegating the response purely to procurement treats it as a price negotiation. Delegating it purely to a platform team treats it as a packaging exercise. It is neither. It is a strategic decision about a foundational layer, and it belongs to the CTO. Our broader Oracle Java strategy overview sets out the market context.

Frame it as a platform decision

The most important thing a CTO does on Java migration is set the frame. Framed as a cost-cutting exercise, it competes for attention with every other cost line and gets deprioritised. Framed as a compliance clean-up, it feels like overhead. Framed correctly — as a platform decision about owning your runtime layer — it becomes a strategic initiative with a clear owner and a clear thesis.

The thesis is straightforward. Java is open-source software. The OpenJDK project, which Oracle itself leads, is the upstream source for every mainstream Java distribution, including Oracle's own JDK. An enterprise can run production Java on a free, fully supported OpenJDK distribution — Eclipse Temurin, Amazon Corretto, Azul Zulu, Microsoft's build, Red Hat's build — that is binary-compatible with Oracle's at the same version. Migration is therefore not a downgrade or a workaround. It is the decision to consume Java the way the platform was designed to be consumed: as an open standard, from a distribution you choose, rather than as a proprietary product you rent. Framed that way, the conversation with the board is about strategic control, not just savings — and the savings, which are large, become the supporting evidence rather than the headline.

The technical reality: lower risk than it sounds

The single biggest misconception a CTO has to dispel — in their own mind and across the engineering organisation — is that migrating off Oracle Java is a risky, application-rewriting project. It is not. The technical reality is far gentler than the words "Java migration" suggest.

OpenJDK distributions are built from the same source code as Oracle's JDK and are verified against the same Java SE specification through the Technology Compatibility Kit. At a given Java version — say, Java 17 — Eclipse Temurin 17 and Oracle JDK 17 are binary-compatible. An application compiled and tested on one runs on the other without code changes. For the large majority of an enterprise estate, migration is a swap: replace the JDK on the host, repoint the relevant environment variables and packaging, redeploy, and validate. No recompilation against a new API, no rewrite.

The genuine technical work is concentrated in two narrow areas. First, applications pinned to an old Oracle JDK version — Java 8 or 11 — may, as a matter of good hygiene, be moved to a current LTS at the same time; that is a version upgrade, a separate and optional decision from the distribution change. Second, a small number of applications may depend on something Oracle-specific — a commercial feature, an obscure flag, or a vendor certification — and those need individual attention. Identifying that minority precisely is the purpose of the application-compatibility review described in our compatibility guide. The CTO's job is to make sure the organisation understands that the default case is a swap, so that the project is scoped to its real risk and not its imagined one. Our OpenJDK versus Oracle JDK comparison covers the technical equivalence in depth.

Choosing the distribution

"Migrate to OpenJDK" is not a complete instruction, because OpenJDK is consumed through distributions, and choosing one is a CTO-level standardisation decision. The mainstream options are all free, all TCK-verified, and all production-grade; they differ mainly in their support model, release cadence and ecosystem fit.

The CTO decision is to pick one as the organisational standard rather than letting teams choose individually, because a single standard simplifies governance, patching and support. The choice should follow your existing cloud and OS alignment: a heavily AWS estate has a natural fit with Corretto, an Azure estate with Microsoft's build, a Red Hat estate with Red Hat's. Where there is no strong alignment, a vendor-neutral choice such as Temurin avoids re-creating lock-in. Our enterprise distributions guide compares them in detail.

Building the migration roadmap

A migration of any scale needs a roadmap the CTO can defend to the board and hold the organisation to. A reliable structure has five phases.

Phase 1 — Discover

You cannot migrate a Java estate you have not mapped. Phase one is a complete inventory: every Oracle JDK instance, its version, its licence basis, and the application it serves — across servers, desktops, containers and cloud. This is also the phase that quantifies current exposure, and it is the foundation of both the migration and any parallel compliance position. The detailed mechanics are in our step-by-step migration planning guide.

Phase 2 — Assess compatibility

Run the application-compatibility review to separate the large majority of straightforward swaps from the small minority needing individual attention. The output is a categorised application list, which becomes the basis for sequencing.

Phase 3 — Pilot

Migrate a representative sample — a non-critical production service, a test environment, a developer cohort — to the chosen distribution. The pilot proves the swap, exercises the rollback, and produces the evidence that turns engineering scepticism into confidence.

Phase 4 — Roll out in waves

Migrate the estate in waves, sequenced by risk: low-risk, straightforward applications first to build momentum, business-critical and complex applications later when the process is well-rehearsed. Development and test environments typically lead, production follows.

Phase 5 — Decommission and govern

Remove the last Oracle JDK instances, confirm none remain, and stand up the governance that keeps them gone. This phase is where the cost saving becomes permanent rather than temporary.

Managing the risk

A CTO sponsoring a migration owns its risk profile, and there are three risks worth managing explicitly.

Application-specific failure. Mitigated by the compatibility assessment and the pilot — you find the awkward applications before production does — and by per-wave rollback plans. Because the runtimes are binary-compatible, rollback is genuinely simple: revert the JDK swap.

Audit exposure during migration. The migration period is a sensitive window. An organisation that is mid-migration still has Oracle JDK in the estate and may receive an Oracle review in the meantime. The CTO should ensure the migration runs alongside a deliberate compliance posture, not instead of one — the two efforts are complementary, and our note on the Oracle Java audit process explains why timing matters.

Re-contamination. The subtlest risk is that Oracle JDK creeps back in after migration — through a new server build, a developer's habit, a bundled installer. Without governance, a clean estate slowly re-contaminates and the saving erodes. This is managed in phase five and beyond.

Governance after the migration

A migration that is not followed by governance is a temporary saving. The CTO should put three controls in place. First, a standard: the chosen OpenJDK distribution is the organisational default, documented and built into base images, container images and provisioning. Second, a gate: introducing Oracle's JDK becomes a deliberate, approved exception rather than a default download — ideally enforced in the build pipeline. Third, monitoring: periodic scanning confirms no Oracle JDK has reappeared. Together these convert the migration from a one-off project into a durable platform state, the role of an ongoing continuous management programme.

The support build-versus-buy question

One decision a CTO should make consciously is the support model. Free OpenJDK distributions come with community quarterly updates, which for most production estates is entirely sufficient. Some organisations — regulated industries, those running versions past their free-update window, those wanting a contractual SLA and indemnity — choose to buy a commercial OpenJDK support contract from a vendor such as Azul or Red Hat. Even with that contract, total cost stays far below the Oracle subscription, because commercial OpenJDK support is typically priced on the actual server or core footprint rather than on employee headcount. The CTO question is not "free or paid" in the abstract; it is "what level of support does our risk profile actually require," answered estate by estate. Our commercial Java support comparison lays out the options.

Measuring success

A CTO-sponsored initiative needs a clear definition of done. For a Java migration, four metrics capture it:

• Oracle JDK instances remaining: the target is zero, verified by scan.
• Recurring Java licence cost: the target is the elimination of the Java SE subscription line entirely.
• Audit exposure: with no Oracle JDK in the estate, there is nothing for Oracle to audit — exposure goes to zero.
• Governance in place: the standard, the gate and the monitoring are operational, so the state is durable.

Reported against those four metrics, a Java migration is one of the cleaner strategic wins available to a CTO: a foundational platform layer brought under the organisation's own control, a recurring cost eliminated, and a category of audit risk closed — with, for most estates, modest technical risk. That is the result behind much of the $180M+ in total client savings documented across more than 340 engagements.

Frequently asked questions

This article is general information on Oracle Java licensing, not legal advice. Oracle's licensing terms and metrics are determined by Oracle and change over time. Consult a qualified independent Java licensing specialist on your specific estate and migration plan.