Oracle Java SE Licensing Migration Checklist

Oracle Java SE Licensing Migration Checklist

Oracle’s changes to Java SE licensing – notably the new per-employee subscription model – have significantly increased costs and compliance risks for many organizations.

Under Oracle’s current rules, any commercial or production use of the Oracle JDK now requires a paid subscription. Continuing to run Oracle Java without proper licensing can invite audits and hefty back-charges.

In fact, Oracle ramped up Java license audits after 2019, and Gartner projects that by 2026 over 20% of organizations using Java will be audited by Oracle.

CIOs and procurement leaders are therefore exploring migrations to OpenJDK or OpenJDK-based distributions (Amazon Corretto, Eclipse Temurin by Adoptium, Azul Zulu, BellSoft Liberica, etc.) which offer Java without Oracle’s fees.

This advisory checklist outlines a practical, risk-mitigated migration path – covering legal, compliance, and technical steps – to help organizations smoothly transition off Oracle Java SE.

Read Oracle Java SE Audits: Proactive Defense Strategies for CIOs and Procurement Leaders.

1. Inventory Current Java Usage and Licenses

Begin by thoroughly assessing your current Java footprint and license exposure:

• Discover All Java Installations: Create an inventory of all servers, VMs, containers, and desktops running Java. Note Java versions (e.g. 8, 11, 17) and editions (JDK/JRE) on each system. Don’t forget build servers, CI agents, and less obvious places (cron jobs, embedded devices) where Oracle Java might be installed.
• Identify Oracle JDK Instances: Pinpoint where Oracle’s Java SE is in use. These are the installations carrying compliance risk if not licensed. Remember that since 2019, using Oracle JDK in internal business or production systems without a subscription is considered non-compliant. Any Oracle JDK installed for more than just development/testing may require a license under Oracle’s OTN terms.
• Map Java to Applications: Link each Java installation to the applications or services it supports. Highlight mission-critical systems and third-party applications that depend on Java. This helps prioritize testing and ensures you don’t overlook an obscure app during migration.
• Check for Oracle-Specific Features: Determine if any applications use Oracle-specific Java features or APIs. Most standard Java code will run on OpenJDK with no changes. However, confirm you’re not relying on components that might not be present in OpenJDK (e.g. Oracle’s older UI toolkits or Java Web Start, which was discontinued in Java 11). If you use JavaFX on JDK 8 or other optional components, note that some OpenJDK builds might exclude these by default (e.g. Amazon Corretto’s Java 8 includes JavaFX only until 2026).
• Employee Count & License Status: Document how many employees or devices currently require Java and what Oracle licenses you have. Oracle’s new Java SE Universal Subscription counts all employees (including part-time and contractors) for pricing. Compare your usage against licenses owned. If you’re on Oracle’s subscription, note renewal dates and any cancellation notice period. If you’re not currently licensed, quantify the potential liability (e.g. number of Oracle JDK installations) to understand audit risk.

👉 Tip: Engage your software asset management or SAM team to assist with the Java inventory. Many organizations find this step more time-consuming than expected.

Tools like Lansweeper or Flexera can scan for Java installations to ensure nothing is missed. Early in the process, consider informing your legal team of the migration plan so they’re prepared to address any Oracle inquiries during the transition.

2. Assess Legal and Compliance Obligations

Migrating off Oracle Java has legal implications that must be managed in parallel with technical work:

• Review Oracle Contracts: Check your Oracle Java SE subscription or support agreements for any clauses on termination, end-of-use, or transition. Plan the timing so that you can exit Oracle licensing cleanly (e.g. target the end of a subscription term to avoid renewal fees). If you have Oracle Java embedded in any vendor systems (Oracle databases, middleware, or applications that bundle Java), confirm whether those are separately licensed or exempt when used within that product.
• Audit Preparation: Until migration is complete, maintain vigilance on compliance. Oracle’s License Management Services have been known to initiate “friendly” inquiries about Java usage that precede audits. Ensure you can readily demonstrate where Oracle Java is still in use and your plan to retire it. Gartner analysts warn that Oracle is aware of widespread Java deployments and will likely target many organizations with audits. Proactively remediating unlicensed installs (by replacing or removing them) is the best defense against audit findings.
• Employee Count Definition: If you are (or were) on Oracle’s per-employee licensing, clearly understand how “employee” is defined in your contract. Oracle’s definition can be broad – including all employees and contractors regardless of direct Java usage. This is important for two reasons: (1) to avoid under-counting and incurring compliance issues, and (2) to measure the cost savings of migration. For example, at $15 per employee/month, a company of 1,000 employees would pay ~$180K/year for Oracle Java (even if only a fraction actively use it). This cost is entirely avoidable by moving to free OpenJDK distributions.
• Plan for Support Continuity: Decide how you will handle Java support post-migration. Oracle’s subscription includes support and quarterly updates; moving to an OpenJDK distro means you’ll either rely on community updates or purchase support from a vendor (more on this in the next section). Factor this into your contract planning – for example, you might switch to a third-party Java support provider immediately after Oracle support lapses, to ensure no gap in patch availability.

👉 Outcome: By the end of stages 1 and 2, you should have a clear picture of your Java usage and a roadmap for exiting Oracle agreements without falling out of compliance. Document this as part of your migration plan, so stakeholders (including finance and legal) approve the approach.

Read Company Journey: From Oracle Java to OpenJDK.

3. Choose an OpenJDK Distribution (Vendor-Neutral Evaluation)

Not all OpenJDK builds are identical in terms of support and update policies. In this stage, select a Java runtime that fits your organization’s needs:

• Consider Major Distributions: Evaluate well-known OpenJDK-based distributions. Major options include Eclipse Temurin (Adoptium), Amazon Corretto, Azul Zulu, BellSoft Liberica, Red Hat OpenJDK, IBM Semeru, among others. All of these are based on the same OpenJDK source and are Java SE standard compliant, meaning applications that run on Oracle’s JDK will also run on these alternativesazul.com. The table below compares a few key attributes: DistributionLicense & CostFree Updates (LTS)Support OptionsEclipse Temurin (Adoptium)Open source (GPL+Classpath), no costCommunity-maintained updates for LTS (Java 8, 11, 17, 21).
  Typically timely with each quarterly security release.Community support; no official vendor support (but third parties like IBM can support it).Amazon CorrettoOpen source (GPL), no costAmazon provides free LTS updates (Java 8 until 2030, 11 until 2031, 17 until 2029, etc.). Quarterly security patches are guaranteed at least until those dates.AWS covers it as part of AWS Support plans; no separate cost. Suitable if you’re on AWS, with community forums for others.Azul ZuluOpen source (GPL), no cost for community buildsProvides free builds for LTS versions. Azul backports security fixes; older versions (Java 6, 7, etc.) are supported for customers.Paid support available from Azul (e.g. Zulu Enterprise). They offer extended patch support beyond free update timelines for a fee.Oracle OpenJDKOpen source (GPL), no cost to useFree updates for the current LTS only, until one year after the next LTS (per Oracle’s NFTC terms). For example, Oracle’s OpenJDK 17 updates stopped one year after Java 21’s release.Paid support requires subscription (effectively the Oracle Java SE subscription). Using Oracle’s build without subscription beyond the free period re-enters compliance risk.Red Hat OpenJDKOpen source (GPL), no cost (with Red Hat subscription)Red Hat provides updates for LTS releases (via the community and RHEL channels). JDK 11 and 17 updates are available long-term (Red Hat was lead maintainer for OpenJDK 8/11).Support included for Red Hat customers (RHEL, RHEL-based products). Community can access updates via Adoptium. Third-party support possible. Table: Comparison of popular Java (OpenJDK) distributions and their support models.
• Match Your Java Version: Choose a distribution that offers the version you need. If your applications run on Java 8 or 11 today, ensure your chosen vendor provides builds for that version and plans to supply security updates for it going forward. For example, Amazon Corretto and Eclipse Temurin continue to provide free Java 8 updates well beyond Oracle’s public EOL. If you plan to upgrade to a newer Java version (e.g. moving from Java 8 to Java 17 as part of this migration), factor that in – you might go straight to an LTS like 17 or 21 on the new platform.
• Evaluate Vendor Stability: Since you are effectively relying on the new vendor for JVM updates, evaluate their track record. Look at how quickly they release patches after Oracle’s quarterly updates, and how long they commit to support LTS releases. For instance, Amazon has committed to support Java 11 until at least 2031 with free updates, and Java 17 until 2029. Azul and BellSoft similarly have long support offerings (paid) for older versions. Ensure the choice aligns with your organization’s support horizon and upgrade cycle.
• Support Needs: Decide if you require a support contract for Java. Many OpenJDK users operate with community support (especially for non-critical workloads). However, for mission-critical systems, you might opt for paid support from a vendor like Azul, Red Hat, or BellSoft to have access to guaranteed patches and expert assistance. Even with a vendor-neutral approach, it’s not uncommon to budget for optional support – e.g. some organizations budget a modest per-server fee for Java support to mitigate risk of downtime. If you choose a free community route (like Temurin without any paid support), ensure you have internal expertise to handle JVM issues and promptly apply updates.
• Compatibility Considerations: All reputable OpenJDK distributions pass the Java TCK (Technology Compatibility Kit), meaning they are functionally equivalent to Oracle JDK for standard Java APIs. In practice, migrations between Oracle and OpenJDK distributions are usually seamless for server-side applications – one study finds that 99% of the time applications run without issues on a new JDK. Nevertheless, consult documentation or migration guides from your chosen distribution for any minor differences. For example, some builds might have different default Garbage Collectors or exclude some optional components (as noted with JavaFX). It’s also wise to check if your enterprise software vendors certify or support their products on the chosen OpenJDK variant. Many vendors officially support “Java 8/11/17” rather than a specific build, but a few might list only Oracle by name. Given that since Java 11 Oracle JDK equals OpenJDK source, this is usually a formality – still, it’s worth validating for critical third-party apps.

4. Set Up Test Environments and Proof of Concept

With an OpenJDK distribution selected, perform thorough testing before any production switch:

• Install OpenJDK in Parallel: In a controlled test environment, install the chosen OpenJDK distribution side by side with Oracle Java. For example, you might deploy the OpenJDK on a QA server that still has Oracle JDK present. This allows direct comparisons. Configure your test application or service to use the new JDK by updating the JAVA_HOME path or application server settings to point to the OpenJDK install. (On Linux, you might update environment scripts; on Windows, you can adjust the PATH or Java registry reference for that test service.)
• Run Comprehensive Tests: Execute your full regression test suite on the OpenJDK runtime. Pay close attention to any functionality that interacts with the JVM or OS at a low level: file I/O, network communication, threading, encryption, etc. In most cases, these will behave identically. Use tools like jdeps (Java dependency scanner) and jdeprscan to identify any usage of internal or deprecated Java APIs that could behave differently. If your applications log Java version info on startup, verify they recognize the new vendor (some logging might show the JVM name like “Eclipse OpenJ9” if using IBM Semeru with OpenJ9 VM, or “OpenJDK 64-Bit Server VM” for HotSpot – which is fine).
• Performance Benchmarking: Measure performance metrics under load on the new JDK. Monitor throughput, latency, memory usage, and garbage collection behavior. OpenJDK HotSpot from any vendor should perform on par with Oracle HotSpot, but slight variations can occur due to JVM flags or garbage collector differences. For instance, Azul’s Zulu and BellSoft’s Liberica use the same HotSpot, whereas IBM’s Semeru can use a different JVM (OpenJ9) which might have different performance characteristics. Ensure response times and resource usage meet expectations, tweaking JVM parameters if needed (e.g. heap sizes, GC tuning) to mirror your Oracle JDK setup.
• Identify and Fix Issues: If tests uncover any discrepancies or failures, investigate them early. Common issues when moving from older Java versions (e.g. 8 to 11/17) include classpath issues, stricter module system checks, or removed legacy APIs. However, if you kept the Java version constant (e.g. Oracle Java 11 to OpenJDK 11), issues are rare. One real-world example: a rendering library produced slightly different chart images on OpenJDK due to font differences – resolved by explicitly installing font packages. Document any changes or workarounds applied during testing. This documentation will be invaluable for production rollout and for demonstrating due diligence in an audit.
• Test Third-Party Products: If you have commercial software (middleware, application servers, etc.) that will run on the new JDK, test those as well. Most enterprise software that “requires Oracle Java” actually runs fine on OpenJDK builds, but verify in a staging environment. Check support forums or vendor knowledge bases for any known issues with OpenJDK. In many cases, vendors have started officially supporting OpenJDK distributions as the community pressure has grown. If not, consider raising the question to the vendor – the more customers ask, the more likely they’ll update their support statements.

5. Update Build Pipelines and Deployment Processes

A successful migration requires updating all the places where Java is referenced in your IT toolchain:

• CI/CD and Build Tools: Reconfigure your continuous integration (CI) pipelines and build servers to use the new JDK. For example, update Jenkins configurations or agent Docker images to point to the OpenJDK installation. In Jenkins, you might add the new JDK in the global tool configuration and switch jobs to use it. Similarly, for Azure DevOps or GitLab CI, update the build agent images or environment variables (JAVA_HOME) to the new distribution. This ensures all new builds and tests run on the OpenJDK going forward.
• Application Packaging: If your deployment bundles a JRE (for instance, some apps package a private JRE for consistency), rebuild or repackage that with the OpenJDK runtime. Remove references to Oracle JDK paths in your build scripts, Dockerfiles, or Infrastructure-as-Code templates. For example, if your Dockerfile previously used FROM oracle/serverjre:8, switch to an OpenJDK base image like FROM eclipse-temurin:8-jre or FROM amazoncorretto:17-alpine as appropriate. Ensure configuration management (Chef, Puppet, Ansible, etc.) is updated to install the selected OpenJDK on VMs instead of Oracle.
• Environment Variables: Standardize environment settings to point to the new JDK. Set the JAVA_HOME variable on all servers and in all deployment scripts to the OpenJDK install path. Update system PATHs if needed so that the java and javac commands resolve to the new distribution. It’s wise to do this in test and dev environments first and have developers update their local setups accordingly. Provide a quick internal guide for developers on installing the new JDK on their workstations and updating their IDE configurations, so everyone is aligned on using the new runtime.
• Quality Gates: Implement checks to avoid “configuration drift” back to Oracle. For instance, you can create a script to scan for any Oracle JDK directory names on servers or a CI job that fails if an Oracle JDK is detected. This helps ensure no new Oracle installations creep back in, intentionally or by accident.
• Security and Patching Process: Treat the OpenJDK updates with the same rigor you treated Oracle’s patches. Oracle releases Critical Patch Updates (CPUs) quarterly, and most OpenJDK vendors follow the same quarterly cycle. Set up a process to download and deploy the new OpenJDK version every quarter (or more frequently if emergency fixes appear). Subscribe to your vendor’s security advisory mailing list or RSS feed to stay informed. For example, Amazon publishes Corretto updates in January, April, July, October in line with Oracle’s CPU schedule. Establishing this process now ensures you remain secure post-migration.

6. Plan the Migration Rollout (Phased Approach with Rollback)

Approach the production migration in well-defined phases to mitigate risk:

• Phased Rollout Strategy: Do not switch everything at once. Start with non-critical or lower environment systems and gradually work up to mission-critical ones. For instance:
  1. Dev/Test First: Swap out the JDK on development and test servers as a trial run. These environments are low risk and will flush out any environment-specific issues.
  2. Pilot in Production: Choose a small subset of production – e.g. one microservice or a batch of less critical app servers – and migrate them to OpenJDK. Monitor them closely (both application metrics and JVM-level logs/garbage collection) for at least one full business cycle. This pilot can build confidence and uncover any surprises before a company-wide change.
  3. Gradual Expansion: If the pilot is successful, continue migrating the rest of the Java workloads in waves. You might do it application by application, or by groups (e.g. one data center at a time, or 10% of servers at a time using a canary approach). Avoid waiting too long between phases, so you maintain momentum and don’t end up with two Java platforms in parallel indefinitely.
• Communication and Coordination: Treat this as a formal change management project. Inform stakeholders and users about the changes and schedule maintenance windows if needed. For example, if a restart is required to switch JVMs, schedule it in an approved downtime window. Communicate the high-level timeline to application owners and IT support teams so they know when each system will transition. Having executive buy-in (e.g. a CIO mandate) will help prioritize resources and minimize pushback.
• Prepare a Rollback Plan: Even with thorough testing, have a contingency plan in case something goes wrong after migration. Do not uninstall Oracle JDK immediately on day one. Keep the Oracle JDK binaries available on standby (you might just leave them installed but unused, or keep an archive ready to reinstall) until you’re confident in stability. If an issue arises, you should be able to quickly revert by resetting JAVA_HOME and PATH to the Oracle JDK and restarting the application. Document the exact steps to rollback beforehand – e.g. “if we see unacceptable performance, we will switch back to Oracle Java 11 by doing X, Y, Z.” Also preserve any configuration needed by Oracle Java (such as specific security policy files or cryptographic provider settings) until the migration is finalized, in case you need to revert.
• Monitoring During Transition: As you migrate each phase, intensify monitoring. Leverage APM tools to watch for error rates, memory/CPU anomalies, or any unusual behavior on the new JDK. Often, there is no issue, but if, for example, garbage collection patterns change slightly, you want to catch any performance regression early. Have your ops team prepared to compare metrics from before vs. after the JDK switch. In cloud or container environments, ensure your resource limits and autoscaling settings still make sense if the JVM’s footprint changes even slightly.
• Final Cutover and Cleanup: Once all systems are successfully running on the OpenJDK distribution and you’ve observed stability over a few patch cycles, you can proceed to decommission Oracle Java entirely. Uninstall Oracle JDK from servers and laptops to prevent any inadvertent use (and to eliminate lingering compliance risk). Update your CMDB or asset inventory to mark Oracle Java as “removed” and the new distribution as the current standard. This record-keeping is important both for internal governance and in case of future audits – you can demonstrate that as of XYZ date, Oracle software is no longer in use except where duly licensed. Finally, cancel Oracle Java subscriptions/support contracts at the appropriate time (ensuring you’ve met any notice requirements). Oracle does not automatically cancel contracts, so proactive notification is key to stop the billing.

Recommendations

Migrating from Oracle Java SE to OpenJDK is a significant change, but it can be executed with minimal disruption by following a structured plan.

Here are concise recommendations for CIOs and IT leaders to maximize success:

• Perform Due Diligence Up Front: Don’t skip the inventory and analysis. Knowing exactly where Java is used (and how) is the foundation of a smooth migration. This also arms you with data to quantify cost savings and justify the project (e.g. “we will save $X in Oracle fees by switching” – which in many cases is hundreds of thousands of dollars annually).
• Choose Stable, LTS Paths: Opt for Long-Term Support (LTS) versions of Java on the new platform (Java 17 or 21 as of 2025) for the bulk of workloads. LTS releases get updates for years and will minimize the frequency of future migrations. Avoid non-LTS Java versions in production unless you have a specific need, as they require upgrades every six months.
• Test Rigorously and Gradually: Treat the migration like any major release – test in lower environments, do pilot rollouts, and use automated test suites to compare behavior. Thorough testing and a phased approach will catch 99% of potential issues. It’s far cheaper and easier to fix issues in a test environment than after a production go-live.
• Document and Train: Documentation is your friend. Keep a record of all changes made (new JVM settings, any code tweaks, etc.) and update internal documentation for how Java is managed. Train your development and operations teams on the new JDK – e.g. how to get updates, any new commands or tools, and make sure everyone knows that Oracle Java is now off-limits unless explicitly approved. This prevents accidental reintroduction of Oracle JDK in the environment.
• Monitor and Optimize: After migration, monitor systems closely. In the unlikely event of performance changes or memory issues, fine-tune the JVM parameters or seek vendor support. Over time, keep an eye on new Java releases – plan for future upgrades so you don’t fall behind on security updates. The goal is to maintain a modern Java runtime without vendor lock-in, which gives you flexibility and cost control.
• Engage Vendor Support if Needed: If your organization lacks deep Java expertise or if uptime requirements are extremely high, consider a support contract with one of the OpenJDK vendors as an insurance policy. It’s a fraction of Oracle’s cost and can provide peace of mind that you have experts to call in rare cases (e.g. a JVM bug or optimization question). Some enterprises budget a small portion of their savings from leaving Oracle to pay for this support – a prudent trade-off in critical environments.
• Stay Compliant and Informed: Finally, keep records proving your license compliance. Should Oracle come knocking for an audit, you can confidently demonstrate that Oracle JDK is no longer deployed. Stay informed on Java licensing and support developments – the landscape can evolve, as seen with Oracle’s changes. Being aware of vendor announcements (for example, if Oracle or others adjust licensing again, or if a new LTS version is released) will ensure your Java strategy remains cost-effective and secure.