Does OpenJDK remove the Oracle Java subscription cost?
OpenJDK migration removes the Oracle Java subscription cost for every system that moves to a non Oracle build, because the per employee Universal Subscription only applies to Oracle's own Java SE distribution. OpenJDK is the open source project that Oracle Java SE is built from, and several vendors package and support production ready OpenJDK builds at no license fee. A server or desktop running one of those builds is not running Oracle Java, so the employee count that drives the subscription simply does not reach it.
This is what makes migration the exit rather than a discount. Negotiating the subscription lowers a recurring bill but keeps the buyer inside a metric that grows with headcount. Migrating off Oracle Java ends the recurring bill for the migrated systems outright. Because the Universal Subscription counts all employees and contractors regardless of who actually uses Java, the saving is not proportional to a small technical footprint; it is proportional to the whole workforce, which is why the exit is so valuable even for organisations with modest Java estates.
Is OpenJDK the same as Oracle Java?
OpenJDK and Oracle Java SE share the same core, because Oracle builds its Java SE from OpenJDK, so for the large majority of applications the runtime behaves identically and no code changes are required. The Java language, the class libraries, and the virtual machine that applications depend on are common to both. When teams test a migration, the typical finding is that applications run unchanged on a reputable OpenJDK build, which is what makes the move practical at scale rather than a rewrite.
The real differences sit around the runtime, not inside it. They are the vendor relationship, the support and patching model, the update cadence, and occasionally specific commercial features or tools that some applications were built to assume. A careful migration identifies those edge cases up front: a dependency on a feature that is packaged only with Oracle's distribution, or a vendor support requirement that names a particular Java. Most estates have few such cases, and each has a known answer, but they are the reason migration is a managed project rather than a switch flip, and any item where the entitlement is unclear should be flagged as contract dependent.
| Option | License basis | Recurring Oracle cost |
|---|---|---|
| Oracle Java SE Universal Subscription | Per employee | Workforce wide |
| OpenJDK from a supported vendor | No license fee | None |
| OpenJDK self supported | No license fee | None |
| Mixed estate, partial migration | Per employee on remainder | Reduced |
What does an OpenJDK migration involve?
An OpenJDK migration involves four stages: inventory the Java estate, select a target distribution, test and migrate applications, and remove Oracle binaries so the exit is provable. Inventory comes first because a buyer cannot migrate what it cannot see, and Oracle Java hides in servers, desktops, build pipelines, and software bundled by other vendors. The inventory records each Java installation, its version, the application it serves, and whether the entitlement is clear or contract dependent.
Selection chooses a vendor OpenJDK build that matches the versions in use and offers a support model the organisation is comfortable with. Testing then validates applications against the new runtime, prioritising the systems with the largest exposure or the nearest renewal. Migration proceeds in waves, and the final stage matters as much as the first: removing the Oracle binaries and the access that allowed them, so that the estate not only runs OpenJDK but can be shown to run nothing else. That clean removal is what converts a technical migration into a defensible licensing position.
Can you migrate to OpenJDK during an Oracle audit?
You can migrate to OpenJDK during an Oracle audit, and doing so strengthens the buyer position by capping future exposure while the past is negotiated. An audit looks backward at use Oracle can evidence and forward at the subscription Oracle wants to sell. Migration does nothing to the backward question on its own, but it removes the forward one: once a system runs OpenJDK, there is no continuing Oracle Java metric to subscribe to. That reframes the negotiation from an open ended recurring commitment to a bounded, one time discussion about historical use.
The sequencing is the buyer move. Oracle's preliminary findings arrive inflated at list price, and an independent line by line review of findings typically cuts claims by 60 to 80 percent by testing what the evidence actually supports. Pairing that review with a credible migration plan changes the leverage, because Oracle is negotiating about a shrinking estate rather than a captive one. A buyer who can show that the Java footprint is moving to OpenJDK has a far stronger hand than one who must price a subscription across the whole workforce indefinitely, and the migration can often be timed to support a settlement rather than complicate it.
What should a buyer watch for in an OpenJDK migration?
A buyer should watch for incomplete removal, hidden bundled runtimes, and support obligations that name a specific Java, because each can quietly leave Oracle Java in the estate after a migration is declared done. Incomplete removal is the most common: applications are moved to OpenJDK but old Oracle installations linger on decommissioned looking servers or in container images, and an audit finds them. The fix is the disciplined removal and scanning step, treated as part of migration rather than an afterthought.
Bundled runtimes are the second watch item, since Oracle Java arrives inside other vendors' products and inside images pulled automatically, so a clean desktop policy does not guarantee a clean estate. The third is contractual: a few third party applications are supported only on a named Java, and forcing a migration there can void support, so those cases are handled individually and flagged as contract dependent. Knowing these failure modes lets the buyer plan a migration that genuinely closes the Oracle Java exposure rather than appearing to, which is the difference between an exit and an expensive surprise at the next audit.
How should a buyer choose an OpenJDK support model?
A buyer should choose an OpenJDK support model by matching the level of assurance to the criticality of the systems, since OpenJDK is free to license but support and timely security patches are where the real decision sits. For systems that run revenue or regulated workloads, a commercial OpenJDK support subscription from a reputable vendor provides patched builds, defined response times, and a named party to escalate to, at a cost that is still far below the Oracle per employee subscription because it is priced on support rather than on the whole workforce. For low risk or internal systems, a self supported model drawing on community builds can be entirely adequate.
The point that matters for licensing is that none of these support choices reintroduce the Oracle Java metric. A commercial OpenJDK support subscription is a support contract for open source software, not an Oracle Java license, so it does not pull the estate back under the per employee count. The buyer can therefore tier the estate, paying for support where it is warranted and self supporting elsewhere, and still keep the whole footprint outside the Oracle subscription. This tiering is the practical way large organisations make the exit both safe and economical, and any vendor support term that names a specific Java should be checked and flagged as contract dependent.
The next step
This article is part of our Java Licensing cluster. Read the pillar, the Oracle Java licensing guide, for the full picture, and these related reads: Java download monitoring and audit triggers, and Java cost modeling, subscription versus migration. To plan a migration alongside an audit, talk to our team through the Java licensing advisory service.