How to exit your Java SE Subscription.

For most organisations, the Oracle Java SE Subscription is now an optional cost. Since Oracle moved Java to the employee metric in 2023, the annual bill has been decoupled from actual Java use — and for an enterprise with a large headcount and a modest Java footprint, that bill can run into seven figures. The good news is that a clean exit is achievable. The runtime can be replaced with a free, binary-compatible OpenJDK build, and the subscription can be allowed to lapse. But exit is a project, not an email. This guide sets out the whole sequence.

Why organisations exit the subscription

The reasons are almost always financial, and they have intensified since the metric change. A subscription priced per employee charges you for your whole workforce regardless of how many machines run Oracle’s JDK. A company with 8,000 employees can owe Oracle close to a million dollars a year even if Java runs in a handful of applications. Renewal quotes frequently arrive with double-digit percentage increases, and Oracle steers legacy customers toward the more expensive Universal metric.

The deciding insight is usually this: the thing you actually need — a working, patched Java runtime — is available for free. OpenJDK builds from Eclipse Adoptium (Temurin), Amazon (Corretto), Azul (Zulu), BellSoft (Liberica) and Red Hat are built from the same source as Oracle’s JDK, are licensed under the GPL with the Classpath Exception, and are free for production use. Once that registers, the subscription stops looking mandatory and starts looking like a choice.

Is exit feasible for you?

For the large majority of organisations, yes. The cases where exit is harder, or needs more care, are specific and identifiable:

• You rely on Oracle commercial-only features. A small set of capabilities historically required the paid product. Most workloads use none of them, but confirm.
• You run Oracle Java embedded in other Oracle products. Java inside products such as WebLogic is governed by that product’s licence and is a separate question — exiting the standalone Java SE Subscription does not change it.
• You have applications certified only against Oracle JDK by a third-party vendor. This needs a vendor conversation, but OpenJDK compatibility is now so strong that most vendors support it.
• You need a commercial support contract for Java itself. If you genuinely require vendor support, note that Azul, Red Hat, BellSoft and others sell OpenJDK support — usually well below Oracle’s employee-metric price.

None of these is a blocker for most estates. They are simply items to check during inventory rather than discover during migration.

Step 1: Build a complete Java inventory

Every successful exit starts with knowing exactly what you run. You cannot migrate or decommission what you have not found. The inventory needs to capture, for every Java installation across servers, desktops, containers, and cloud: the vendor (Oracle JDK or an OpenJDK build), the version, the deployment context (production, test, development, or embedded in another product), and the application that depends on it.

Most organisations are surprised by what this reveals. A common finding is that a large share of the estate is already on free OpenJDK builds, and that genuine Oracle JDK use is concentrated in a smaller set of applications than expected. That is encouraging — it means the migration scope is narrower than the subscription implies. Our Java usage tracking guide covers discovery tooling in detail.

Step 2: Choose your OpenJDK target

You do not have to standardise on a single OpenJDK distribution, but most organisations should. The leading free builds are all production-grade and binary-compatible; the choice comes down to support model, release cadence, and operational fit.

Match the OpenJDK version to your Oracle JDK version where possible — a like-for-like move from Oracle JDK 17 to Temurin 17, for example, minimises change. If some applications are on very old releases, this is also an opportunity to plan version upgrades, but keep that separate from the licensing exit so the two projects do not entangle. See our comparison of Eclipse Temurin vs Oracle Java for a closer look.

Step 3: Migrate production off Oracle JDK

Replacing the runtime is the technical core of the exit, and it is lower-risk than most teams expect because the builds are binary-compatible. A disciplined sequence looks like this:

• Pilot in non-production. Swap the JDK on development and test environments first. Run the application’s standard test suite and confirm parity.
• Test deliberately. Functional, performance, and startup testing on the new runtime. Watch for anything that touched Oracle-specific behaviour. Our migration testing strategy sets out a full test plan.
• Roll production in waves. Migrate by application or environment group, not all at once. Each wave validates the approach and contains risk.
• Update build and deployment pipelines. Container base images, CI/CD configuration, installer packages, and infrastructure-as-code all need to point at the new JDK so that new instances never reintroduce Oracle JDK.
• Verify nothing reinstalls Oracle JDK. Auto-update settings, golden images, and provisioning scripts are the usual culprits. Lock them down.

For the bulk of standard Java SE workloads, this is a routine change. The technical risk is real but manageable; the licensing saving is permanent.

Step 4: Handle the contract correctly

Exiting the subscription is as much a contract exercise as a technical one. Oracle’s Java SE Subscription is a term agreement, and how you leave it matters.

First, find your renewal date and notice requirements. Many subscriptions auto-renew unless cancelled within a defined window before the term ends. Missing that window can lock you into another full year. Diary the notice deadline well in advance.

Second, understand that the subscription is not perpetual. When it lapses, you lose the right to run the licensed Oracle JDK builds and to download further Oracle updates. That is precisely why the OpenJDK migration must be substantially complete before the term ends — you are not allowed to keep using Oracle’s JDK after the subscription stops.

Third, send a clear, written non-renewal notice within the contractual window. Keep it factual and unambiguous. Do not let the decision ride on a verbal conversation with a sales representative.

Step 5: Give notice and decommission

With migration complete and notice served, finish the job cleanly. Remove remaining Oracle JDK binaries from machines where they are no longer needed — not to hide anything, but because a stray Oracle JDK install after the subscription lapses is an unnecessary compliance risk. Document the final state: which OpenJDK build runs where, and confirmation that no Oracle JDK remains in production.

Then keep it that way. The estate that exits successfully and then drifts back into Oracle JDK — through a developer download here, an unlocked auto-update there — can find itself exposed again. A lightweight ongoing scan closes that gap; our continuous management service exists for exactly this.

The renewal and exit traps to avoid

A realistic timeline

For a mid-sized enterprise, plan for three to six months from decision to clean exit, working back from the renewal date. Inventory and target selection take a few weeks. Pilot and testing take several more. Production migration in waves is the longest phase. Contract notice must land inside the cancellation window regardless of where migration stands — which is why starting at least two quarters before renewal is wise. A rushed exit is where mistakes — and renewed subscriptions — happen.

Getting independent help

Exiting the Java SE Subscription combines a technical migration with a contractual deadline, and getting the sequencing wrong is expensive. Independent, buyer-side advisers — with no Oracle partnership and no resale incentive — have helped clients eliminate Java licensing cost entirely as part of more than $180M in total savings across 340+ Java engagements.

Our Java Migration service and Renewal Advisory are built to take an organisation from a costly subscription to zero Java licensing spend without business disruption.

Frequently asked questions