Leaving Oracle Java retires the per employee bill and hands you two new exposures: who patches your JVM, and what you fall back to when a workload breaks. This page prices both and gives you the rollback runbook.
Leaving Oracle Java retires the per employee bill and hands you two new exposures: who patches your JVM, and what you fall back to when a workload breaks. This page prices both and gives you the rollback runbook.
You are trading a commercial exposure for two operational ones, and they are not the same shape. The commercial exposure was predictable, annual and someone else's to manage. The operational exposures are yours, and they surface at the worst moments.
Both are manageable, and neither is a reason to stay. They simply need designing before cutover rather than discovering during it. The financial case sits on a separate page: the CFO business case for leaving Oracle Java owns the model and the assumptions, while this page owns what happens when something goes wrong.
The financial risk lives at Oracle. The operational risk lives in your production estate. Do not confuse solving one for solving the other.
If you are still choosing between full migration, a hybrid estate and staying on the subscription, read the three migration patterns modeled first. If the decision is made and you are protecting production, start here, then work through the sequencing in the Oracle Java to OpenJDK migration guide.
Not the JVM. Oracle JDK and the mainstream OpenJDK distributions are built from the same upstream source and pass the same Technology Compatibility Kit, so on the same LTS version the runtime behavior is effectively identical. The failures cluster somewhere else entirely.
Knowing where they cluster changes how much contingency you need. You do not need an estate wide safety net. You need a short list of workloads that carry real risk and a specific test for each failure mode.
Failure taxonomy: what actually goes wrong, and how to find it before cutover
| Failure mode | What it looks like | How to detect it before you cut over | Typical fix |
|---|---|---|---|
| Vendor string checks | Application refuses to start, or logs an unsupported JVM warning | Grep the codebase and config for java.vendor and Oracle Corporation | Remove the check, or override the property where the licence allows |
| Hardcoded install paths | Scripts, services and wrappers point at an Oracle specific directory | Search deployment scripts, systemd units and service wrappers for the path | Parameterize the path, standardize on one location |
| JDK internal API use | Illegal access or module errors on start | Run jdeps against the application archives before the swap | Add the required open flags, then plan the code fix |
| Crypto and keystore differences | TLS handshakes fail, or a cipher suite disappears | Compare the security provider list and default trust store between builds | Align the provider configuration, import the missing anchors |
| Fonts, locale and timezone data | Reports render differently, dates shift, PDFs lose glyphs | Diff the tzdata version and the bundled font set | Install the missing font packages, pin the tzdata update |
| Removed or renamed flags | JVM refuses to start after a tuning profile is applied | Replay the full start command against the target build in a lab | Rebuild the tuning profile on current defaults |
| ISV support matrix | Vendor declines to investigate an incident on an unlisted JDK | Ask the vendor in writing, per product, before you schedule the wave | Wait for certification, or accept and document the risk |
Before any wave, run the target build against the workload in a lab with the real start command, the real configuration and the real data volume. Not a smoke test. The failures above almost all appear at startup or on the first TLS handshake, which means a genuine start beats a week of static analysis.
Developer workstations and build agents deserve the same treatment and are usually easier. Work through them first using the CI/CD and workstation cleanup guide, because a build agent still pulling an Oracle JDK will quietly reintroduce Oracle binaries into every artifact you ship.
Yes, and it is the exposure teams miss because they plan only for technical rollback. If a wave fails and somebody restores an Oracle JDK build outside the No Fee Terms and Conditions, the paid subscription requirement returns. Oracle's position is that a subscription applies if any single application uses unlicensed Oracle JDK.
One binary re arms the whole estate. That is what makes an improvised rollback so expensive: the outage lasts an hour, the licensing consequence lasts a renewal cycle.
Oracle publishes an LTS release under the No Fee Terms and Conditions and provides free quarterly updates until roughly one year after the following LTS ships. After that point, later updates for that release move to the OTN terms and require a subscription for production use.
The dangerous property of this rule is that nothing warns you. A patch pipeline that keeps applying Oracle updates on schedule walks an estate out of the free window without a single alert firing. Read the licensing mechanics in the Oracle Java licensing changes overview.
A rollback to Oracle JDK to save an outage can cost more than the outage. Pin the fallback to an OpenJDK build, never to a fresh Oracle patch.
Improvisation is the failure mode. Write the fallback down, stage the binaries, and make the safe choice the easy choice at three in the morning.
Put the runbook in the incident process, not in a migration document nobody reads at three in the morning. Then remove the Oracle binaries from the artifact repository entirely once the last wave lands, because a fallback that no longer exists cannot be chosen by mistake. The audit implications are covered in our Java audit risk assessment.
The question that matters for a critical workload is not price, it is how fast a security fix reaches your runtime and who is contractually on the hook if it does not. The mainstream distributions align to the same upstream quarterly cycle, so leaving Oracle does not slow your patching down.
Support characteristics that matter for a production decision
| Distribution | Cost model | Patch cadence | Contractual SLA | What you are relying on |
|---|---|---|---|---|
| Eclipse Temurin | Free | Quarterly, aligned to upstream | None | A community project with broad vendor participation |
| Amazon Corretto | Free | Quarterly plus out of cycle urgent fixes | None on the free build | A large vendor maintaining it for its own platform |
| Azul Platform Core | Paid, priced per server, JVM or developer | Security fixes ahead of the upstream general availability date | Yes | A commercial relationship with JVM engineering behind it |
| Red Hat build of OpenJDK | Paid, inside a subscription | Quarterly | Yes | An entitlement you may already own with the operating system |
| Oracle JDK | Per employee subscription | Quarterly critical patch update | Yes | The vendor you are trying to leave |
A free build is maintained. A supported build is maintained and somebody owes you an answer. That is the entire difference, and it matters for exactly one class of workload: the one where a JVM level defect becomes an executive incident.
Ask any candidate three questions in writing before you standardize on it.
Project details and published end dates sit on Adoptium, Amazon Corretto and OpenJDK itself. Read them before you rely on a summary, including ours.
Compare the candidates properly with our OpenJDK distribution comparison and the wider alternative Java options overview before you standardize, because standardizing twice is expensive.
For most of the estate, no. Paid OpenJDK support buys three things a free build does not: a contractual response commitment, a named escalation path for JVM level defects, and with one vendor, earlier security delivery. If none of your workloads need those three things, you are buying reassurance rather than risk reduction.
The commercially important point is what the meter counts. Commercial OpenJDK support attaches to infrastructure: a server count, a JVM count, or a developer seat. That is why a hybrid support posture usually costs a fraction of the subscription it replaces.
The common advice is to keep an Oracle JDK fallback available for every migrated workload, on the reasoning that the old runtime is the safest thing to return to. We disagree, and it is the single most expensive piece of conventional wisdom in this whole exercise. It is wrong technically, because the failure modes that actually occur are configuration and dependency problems that returning to Oracle does not fix, and the previous OpenJDK build resolves them just as well. It is wrong commercially, because keeping Oracle binaries staged and reachable is precisely how an estate ends up with a residual deployment nobody authorized. The correct fallback is the previous build of the distribution you migrated to, and the correct end state is that no Oracle Java binary remains anywhere in the artifact chain.
Tier by blast radius and sequence from lowest to highest. The point is not caution for its own sake. It is that each wave produces playbooks, evidence and confidence that the next wave consumes.
Migration tiers and the contingency each one actually needs
| Tier | What sits here | Wave approach | Contingency required |
|---|---|---|---|
| Tier 3 | Development, build agents, internal tools, batch | Single wave, same version swap | Redeploy the previous image. No parallel run needed. |
| Tier 2 | Customer facing but recoverable, moderate integrations | Waves of ten to twenty, staged by domain | Two to four week parallel run, documented OpenJDK fallback |
| Tier 1 | Revenue, regulated, and anything with an ISV matrix constraint | One workload at a time, with load testing | Full parallel run, named rollback owner, staged binaries |
| Embedded | JDKs shipped inside third party products | Vendor led, on the vendor's timetable | Track separately. This is the last thing removed. |
Third party products with a certified configuration naming Oracle JDK are the constraint that no amount of internal testing removes. During an incident, the vendor's support desk will check the runtime before it checks anything else.
Where the answer is unhelpful, that workload stays on its current runtime until the vendor certifies an alternative. That is a scheduling fact, not a failure. Our guide to third party and embedded JDK migration covers the patterns.
A realistic full estate cutover runs nine to fourteen months, as set out in the migration timeline reality check. Rushing tier one to hit an Oracle renewal date is the most common cause of a rollback that becomes a compliance problem.
Sequence the low risk tiers to finish before the renewal so the residual Oracle footprint is already near zero, then take the time tier one actually needs. A small, known, documented residual is a manageable negotiating position. A rushed cutover that half failed is not.
Source: Redress Compliance advisory engagement file, 2024 to 2025.
Because it costs you the saving and keeps the liability. An estate that has migrated ninety percent of its Java and left the rest is paying nothing while still meeting Oracle's condition for requiring a subscription. That is the worst of both positions.
Oracle Java audit activity rose materially through 2024 and 2025, and the common trigger is mundane: a download record showing Oracle Java pulled without a subscription. Reviews are frequently timed ahead of a Database or E Business Suite renewal, so a Java finding becomes a renewal lever rather than a standalone claim.
A migration that cannot be evidenced is a migration you will have to argue about. Build the evidence as you go rather than reconstructing it under a 45 day response clock.
Score your own position with the Java licence risk assessment results guide, and if a subscription is still in place while you finish, work the exit with our Oracle Java SE exit strategies.
Treat support and rollback as design work with a deliverable, not as a risk register entry. Each step below produces an artefact that the next step consumes.
Yes for the mainstream distributions. Temurin, Corretto, Azul and Red Hat all track the same upstream quarterly cycle Oracle uses. Corretto also ships urgent fixes outside that cycle, and Azul's paid tier delivers security fixes ahead of the upstream general availability date.
It can bring the subscription requirement back. Oracle requires a subscription if any single application uses unlicensed Oracle JDK, and any build past the No Fee cutover for that release is unlicensed without one. Fall back to an OpenJDK build of the same version instead.
Roughly one year after the next LTS release ships. JDK 17 left the window in September 2024, JDK 21 leaves in September 2026, and JDK 25 in September 2028. Check the release specific dates on Oracle's published roadmap rather than assuming.
Only for workloads that genuinely need a contractual response commitment, a named escalation path, or earliest patch delivery. Run the long tail on a free build and reserve a paid tier for tier one systems. Commercial builds meter on infrastructure, not on payroll.
Configuration and dependencies, not the JVM. The recurring causes are vendor string checks, hardcoded install paths, JDK internal API use, crypto provider differences, font and timezone data, removed tuning flags, and third party support matrices. All seven are detectable in a lab before cutover.
Get the position in writing, then treat it as a scheduling constraint rather than a blocker to argue with. That workload stays where it is until the vendor certifies an alternative. Meanwhile it should be the only Oracle Java footprint left, sized and documented.
With dated scan evidence covering hosts, images, templates and third party installation directories, repeated after each wave. Also close or log the Oracle Java download channel at the proxy, because download records are a common trigger for a review.
Financially it is the worst available outcome. Oracle requires a subscription where any one application still runs unlicensed Oracle JDK, so a ninety percent migration can carry the full exposure while capturing almost none of the saving. Either finish it or price the residual deliberately.
Migrating Oracle to PostgreSQL removes the licence and the 22 percent support annuity. The break even math, what migrates cleanly, and why a credible exit is leverage even if you s
Gated with a work email on the download page. No sales follow up you did not ask for.
Get the White Paper →
500+ enterprise clients. 11 vendor practices. Industry recognized. One conversation can change what you pay for the next three years.
One buyer side briefing a week. Renewal signals, audit moves, and the levers that work. No vendor spin.
