The JVM is almost never what breaks, and your fallback must be OpenJDK not Oracle
Leaving Oracle Java retires the per-employee subscription and hands you two new exposures: who patches your JVM, and what a workload falls back to when a cutover fails. The first is a support question, the second a rollback trap, and the trap is the dangerous one. Rolling a broken workload back to a current Oracle JDK build under outage pressure can re-trigger a paid subscription for the entire estate. Both exposures are manageable, but only if you design them before cutover rather than discover them during it.
Prepared by Redress Compliance · August 9, 2026 · Oracle advisory. Based on 35 to 45 Oracle Java migration engagements, 2024 and 2025.
Executive summary
You are trading one commercial exposure for two operational ones, and they are not the same shape. The per-employee subscription was predictable, annual, and someone else's to manage; the two exposures that replace it are yours and surface at the worst moments.
The support exposure is who ships the security fix, how quickly, and who you call when the JVM itself is the suspect rather than your code. The rollback exposure is what a workload falls back to when a cutover fails, and whether that fallback quietly reintroduces a licensing obligation.
Both are manageable and neither is a reason to stay, but they need designing before cutover: the financial risk lives at Oracle, the operational risk lives in your production estate, and solving one does not solve the other.
The JVM is almost never what breaks, so you do not need an estate-wide safety net. 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: vendor string checks, hardcoded install paths, JDK internal API use, crypto and keystore differences, font and timezone data, and removed or renamed flags.
What you need is a short list of workloads that carry real risk and a specific test for each failure mode, detectable before cutover by grepping for java.vendor, searching deployment scripts for Oracle paths, and running jdeps against the application archives.
The rollback trap is the one that costs money: your fallback must be OpenJDK, not Oracle.
Rolling a workload back to a current Oracle JDK build during an outage can re-trigger a paid subscription for the whole estate, because the fresh Oracle binary reintroduces the licensing obligation you just retired.
The No-Fee window is time-boxed per release: Oracle publishes free updates for an LTS release until roughly one year after the next LTS ships, then subsequent updates move to the OTN terms.
So the rollback runbook must point at an OpenJDK build of the same version, staged and tested in advance, never at whatever Oracle binary is closest to hand under pressure.
Free does not mean unsupported, and an incomplete migration is the worst outcome available. The mainstream free OpenJDK builds track the same quarterly upstream cycle as Oracle, so free does not mean slow; what paid support buys is an SLA, an escalation path, and with one vendor earlier delivery.
Tier the cutover by blast radius, not application count, because most estates have a long tail that moves in one wave and a short list that needs a parallel run.
The real blocker is the ISV support matrix: a vendor that names Oracle JDK in its certified configuration will not be argued out of it during an incident.
And embedded JDKs are removed last but found first, so a single Oracle binary inside a third-party product keeps the compliance exposure alive after the visible migration is finished.
Where same-version swaps actually fail
| Failure mode | What it looks like | How to detect it before cutover |
|---|---|---|
| Vendor string checks | App refuses to start or warns of an unsupported JVM | Grep code and config for java.vendor and Oracle Corporation |
| Hardcoded install paths | Scripts and services point at an Oracle-specific directory | Search deploy scripts, systemd units, and wrappers for the path |
| JDK internal API use | Illegal access or module errors on start | Run jdeps against the application archives before the swap |
| Crypto and keystore | TLS handshakes fail or a cipher suite disappears | Compare the security provider list and trust store between builds |
| Fonts, locale, tzdata | Reports render differently, dates shift, PDFs lose glyphs | Diff the tzdata version and the bundled font set |
| Removed or renamed flags | JVM refuses to start after a tuning profile is applied | Replay the full start command against the target build |
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 JVM is almost never what breaks; the failures cluster in the environment around it, on vendor string checks, hardcoded paths, crypto providers, and the third-party support matrix, not on bytecode behavior.
That changes how much contingency you need: not an estate-wide safety net, but a short list of workloads that carry real risk and a specific test for each failure mode.
Each mode is detectable before cutover, by grepping the codebase for java.vendor, searching deployment scripts for Oracle-specific directories, running jdeps against the application archives, and diffing the security provider list and tzdata version between builds.
The full sequencing sits in the Oracle Java exit guide, and the distribution options in the OpenJDK comparison.
The rollback trap, and how to close it
- Does your rollback point at Oracle or OpenJDK? Rolling a workload back to a current Oracle JDK build during an outage can re-trigger a paid subscription for the whole estate, so the fallback must be an OpenJDK build of the same version.
- Is the fallback staged in advance? The runbook must point at a tested OpenJDK build, never at whatever Oracle binary is closest to hand under outage pressure, because improvised rollbacks are what turned projects bad in our file.
- Do you know your No-Fee window? Oracle publishes free updates for an LTS release until roughly one year after the next LTS ships, then updates move to the OTN terms, so the free build has a per-release clock.
- Have you found every embedded JDK? Embedded JDKs are removed last but found first, and a single Oracle binary inside a third-party product keeps the compliance exposure alive after the visible migration ends.
- Is the migration actually complete? An incomplete migration is the worst outcome available: you carry the full audit exposure and capture almost none of the saving. The audit exposure detail sits in the Java back-penalty guide.
The Oracle Java audit-defence and exit kit
The rollback runbook, the failure taxonomy, the No-Fee window math, and the buyer-side moves off the per-employee subscription.
Get the white paper →How the support model and the cutover tiering work
Free does not mean unsupported, and paid does not mean faster.
The mainstream free OpenJDK builds track the same quarterly upstream cycle as Oracle, so the security fixes arrive on the same cadence, and what paid support buys is an SLA, an escalation path, and, with one vendor, earlier delivery, not a better patch.
That reframes the support question: you are choosing a service level and an escalation path, not a source of fixes, so match the tier to the workload rather than buying paid support estate-wide by reflex.
Tier the cutover by blast radius, not by application count, because most estates have a long tail that can move in one wave and a short list that needs a parallel run, and sizing contingency by application count over-protects the tail and under-protects the short list.
The real blocker is the ISV support matrix: a vendor that names Oracle JDK in its certified configuration will not be argued out of it during an incident, so those workloads either stay on a supported Oracle-compatible path or move only once the ISV certifies the target.
Embedded JDKs are removed last but found first, because a single Oracle binary inside a third-party product keeps the compliance exposure alive after the visible migration is finished.
And an incomplete migration is the worst outcome available since you carry the full audit exposure and capture almost none of the saving.
The end-of-life timing sits in the OpenJDK end-of-life roadmap, the audit position in the Java audit guide, and the distribution trade-offs in the Azul Zulu comparison and the Amazon Corretto comparison.
- Percentile standing for your exact deal size and industry, from real closed transactions
- Scenario simulation before the call: test alternative terms and see the financial impact of each
- A negotiation playbook, talking points, and a two page executive brief on day one
What we saw across Oracle Java migration engagements, 2024 and 2025
Across the 35 to 45 Oracle Java engagements we worked in 2024 and 2025, the applications that genuinely failed on a same-version distribution swap were a small minority, and they clustered in the same four places every time. The common advice frames the JVM swap as the risk.
We disagree, because the projects that went badly were not the ones with technical failures:
Share of applications that genuinely failed on a same-version distribution swap, clustered in the same handful of environment checks.
What an improvised rollback to a current Oracle JDK build during an outage can re-license, the single most expensive mistake in the file.
The projects that went badly were the ones that improvised a rollback under outage pressure and reached for whatever Oracle binary was closest to hand, re-triggering a paid subscription for the whole estate.
The buyer-side move is to design both exposures before cutover: build the failure taxonomy per workload and detect each mode with a specific test, stage an OpenJDK rollback of the same version so no Oracle binary is ever the fallback.
Tier the cutover by blast radius so the long tail moves in one wave and the short list runs in parallel, respect the ISV support matrix rather than arguing it during an incident, and hunt every embedded JDK so the migration is complete rather than leaving the audit exposure alive.
The wider library sits in the Oracle practice.
Your first five moves
- Build the failure taxonomy per workload, detecting vendor strings, hardcoded paths, internal API use, crypto differences, tzdata, and removed flags before cutover, because the JVM itself almost never breaks.
- Stage an OpenJDK rollback of the same version, so the fallback is never a current Oracle JDK build, which can re-license the whole estate during an outage.
- Tier the cutover by blast radius, not application count, moving the long tail in one wave and running the short list in parallel.
- Respect the ISV support matrix, because a vendor that names Oracle JDK in its certified configuration will not be argued out of it during an incident.
- Hunt every embedded JDK, because they are removed last but found first, and an incomplete migration carries the full audit exposure for almost none of the saving. The Oracle practice runs the runbook with you.
Frequently asked questions
What actually breaks when you leave Oracle Java?
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 in the environment around the JVM: vendor string checks, hardcoded install paths, JDK internal API use, crypto and keystore differences, font and timezone data, and removed or renamed flags.
Each is detectable before cutover with a specific test, so you need a short list of at-risk workloads, not an estate-wide safety net.
Why is rolling back to Oracle JDK a trap?
Because rolling a broken workload back to a current Oracle JDK build during an outage can re-trigger a paid subscription for the whole estate. The fresh Oracle binary reintroduces the licensing obligation you just retired, turning an operational incident into a commercial one.
Your fallback must be an OpenJDK build of the same version, staged and tested in advance, so the rollback runbook never points at whatever Oracle binary is closest to hand under outage pressure. Improvised rollbacks were what turned projects bad in our file.
What is the Oracle Java No-Fee window?
Oracle publishes free updates for an LTS release under its No-Fee Terms and Conditions until roughly one year after the next LTS ships, then subsequent updates for that release move to the OTN terms. It is time-boxed per release, so the free build carries a per-release clock.
This matters for rollback planning: a fallback binary has to be a distribution you can keep patching, which is why the staged fallback should be a mainstream OpenJDK build rather than an Oracle build approaching the end of its free window.
Does free OpenJDK mean unsupported?
No. The mainstream free OpenJDK builds track the same quarterly upstream cycle as Oracle, so the security fixes arrive on the same cadence; free does not mean slow. What paid support buys is an SLA, an escalation path, and, with one vendor, earlier delivery, not a better or faster patch.
So the support decision is a choice of service level and escalation path, not a choice of who ships the fix, and it should be matched to the workload rather than bought estate-wide by reflex.
How should I sequence an Oracle Java migration?
Tier the cutover by blast radius, not by application count. Most estates have a long tail that can move in one wave and a short list that needs a parallel run, so sizing contingency by application count over-protects the tail and under-protects the short list.
Respect the ISV support matrix, because a vendor that names Oracle JDK in its certified configuration will not be argued out of it during an incident, so those workloads move only once the ISV certifies the target distribution.
Why are embedded JDKs the last risk to clear?
Because embedded JDKs are removed last but found first. A single Oracle binary bundled inside a third-party product keeps the compliance exposure alive after the visible migration is finished, so a scan that stops at your own applications misses it.
An incomplete migration is the worst outcome available: you carry the full audit exposure and capture almost none of the saving. Hunt every embedded JDK so the migration is genuinely complete and the exposure is actually retired.
How to Negotiate the Oracle Java Employee Agreement: Honest Leverage in a Captive Deal
Priced per employee, every employee, from $15 down to $5.25. At renewal your leverage is thin and OpenJDK threats rarely land. The one-year runway, trading through the wider Oracle relationship, and containing what you sign.
