EOSL Alerts

Oracle JDK 17 LTS EOL September 2026 Budget Guide

Updated 3rd Party Support Team

Why Oracle JDK 17's EOL Matters in Your Next Budget Cycle

Oracle JDK 17 (LTS) is set to reach end of life (EOL) on September 30, 2026 — approximately 13 months from now. For organizations running this version at scale, that date lands squarely in the next fiscal year. If you're drafting budgets today, this is the moment to decide how you'll handle the transition.

This article walks through what the EOL date actually means, what upgrading a large JDK fleet involves, why many teams fail to migrate in time, and how to compare the costs of migration, vendor extended support, and third-party support. We'll also cover what to include in a budget request now, before renewal negotiations begin.

What the September 2026 Date Means

Oracle JDK 17 is a long-term support (LTS) release — the latest version in this line is 17.0.20. When Oracle ends support for JDK 17, that means:

  • No more public updates: security patches, bug fixes, and performance improvements stop.
  • No more active support: Oracle's support team will not assist with JDK 17 issues after September 30, 2026.
  • No new features or enhancements (though this was already minimal for an LTS release).

After EOL, the only way to keep getting updates is to purchase extended support from Oracle (at a premium), migrate to a newer JDK (e.g., JDK 21 LTS or the next LTS release), or switch to a third-party support provider.

For most enterprise shops, JDK 17 isn't just a single runtime — it's embedded in application servers, build pipelines, CI/CD systems, and dozens of internally developed applications. Stopping support on a piece of infrastructure that touches everything creates real risk.

What Upgrading at Scale Typically Involves

Upgrading from JDK 17 to a newer LTS release (e.g., JDK 21 or the upcoming JDK 25 LTS) is not a simple swap. In a large enterprise, the process often includes:

  • Application compatibility testing: New JDK versions deprecate APIs, remove modules, and change default behaviors. Each application must be tested and potentially refactored.
  • Dependency updates: Frameworks, libraries, and middleware that depend on JDK internals — like Java EE, Spring Boot, Hibernate, or custom class loaders — may need version bumps or patches.
  • Build and CI/CD changes: Maven, Gradle, Docker base images, and deployment scripts must be updated to reference the new JDK.
  • Monitoring and tooling updates: APM agents, profilers, and management tools may require new versions to support the target JDK.
  • Dev/test/staging cycles: For a fleet of hundreds or thousands of JVMs, a full migration cycle can take 6–12 months — often longer if applications are under active development.

Given that internal roadmaps, staff availability, and competing priorities frequently push these projects to the right, many teams will not finish migrating before Oracle's deadline. That's why the budget decision needs to happen now.

Why Teams Often Can't Migrate in Time

Even organizations that plan early run into bottlenecks:

  • Vendor application dependencies: If you run a commercial Java application (e.g., an ERP, CRM, or middleware product), the vendor may not certify on the new JDK until after Oracle's EOL.
  • Legacy code: Applications written in older Java styles (e.g., with --illegal-access flags, or using sun.* APIs) may break without significant rework.
  • Staff bandwidth: The same team that would migrate the JDK is also responsible for security patching, incident response, and feature development.
  • Testing complexity: Large integration test suites are slow and brittle. Full regression testing on a new JDK can take weeks per application.

If any of these scenarios apply to your environment, it's wise to budget for a bridging solution — either extended support from Oracle or third-party support — to cover the gap between EOL and actual migration completion.

Comparing the Cost of Options

When you write your budget request, you need figures for three scenarios:

1. Migrate to a Newer JDK

  • Direct costs: Developer time (hours × hourly rate), testing infrastructure, potential downtime for cutover.
  • Indirect costs: Delays to other projects, risk of production incidents during migration.
  • Timeline: 6–18 months depending on fleet size and app complexity.

2. Oracle Extended Support (post-EOL)

  • Cost: Typically 20–50% of your current Oracle Java subscription fee, per year. The exact percentage depends on your license agreement and support tier.
  • Duration: Must be purchased annually, usually for up to 3 years after EOL.
  • Risk: Still leaves you on JDK 17; you'll eventually need to migrate anyway.

3. Third-Party Support

  • Cost: Often 40–60% less than Oracle's extended support. Fixed annual fee, no per-JVM or per-core overage surprises.
  • Coverage: Continues to deliver security patches, bug fixes, and critical updates for JDK 17 after Oracle stops.
  • Flexibility: You can sustain JDK 17 for as long as needed — 1 year, 5 years, or longer — until your migration is truly complete.

For most enterprises, the decision comes down to: spend money on migration (and risk not finishing in time), pay Oracle a premium for extended support (and still need to migrate later), or use third-party support to decouple the timeline from the vendor's calendar.

What to Put in the Budget Request Now

When you submit next year's budget, include a line item that addresses the JDK 17 gap. A defensible request would contain:

  • A clear EOL date: September 30, 2026.
  • Current JDK 17 footprint: Number of JVMs, application servers, and critical workloads running JDK 17.
  • Migration plan and timeline: If you intend to migrate, show a realistic schedule with a buffer for delays. If you know you can't finish by September 2026, state that explicitly.
  • Cost comparison: A table showing estimated migration cost, Oracle extended support cost, and third-party support cost.
  • Fallback option: A recommended third-party support provider as a benchmark. Get a quote now to lock in a fixed number before Oracle's renewal push.

Example budget line:

"JDK 17 Post-EOL Support (FY2026–2027): $XX,XXX — third-party maintenance to cover JDK 17 security patches and bug fixes for approximately 24 months following Oracle's EOL, while migration to JDK 21 completes."

Get a Third-Party Support Quote Before Renewal Talks

Before you sit down with Oracle for your next renewal, get a third-party support quote as a benchmark. Contact us for a no-obligation price on covering your Oracle JDK 17 fleet past September 2026. Having that number in your back pocket gives you leverage — either to negotiate a lower extended-support fee from Oracle or to choose a simpler, lower-cost alternative that keeps your team on the schedule that actually works for your business.

For more details on Oracle's product lifecycle, see our Oracle software support page. The lifecycle data used in this article is sourced from endoflife.date/oracle-jdk.

How we can help

Keep it supported after end of life

The vendor's date doesn't have to be yours. Our engineers keep Oracle JDK 17 (LTS) running after official support ends — independent third-party support that covers most operational issues, typically at 40-70% below the last renewal quote.

Oracle OS software support →

Migration services

When you do decide to move, we plan and execute the migration. Your current environment stays under vendor support while your contract is active — and if the renewal lapses mid-move, our third-party support covers most issues until the last workload is off it.

Migration & hybrid cloud services →

24×7 remote administration

Short on hands to run it day to day? Our NOC engineers monitor, patch and administer your environment around the clock — incident response included, at a fraction of the cost of an in-house night shift.

24/7 operations & remote administration →

Talk to a support specialist

Speak with an engineer, not a sales rep. We respond within 24 hours.

Your quote will be sent to this address.

By submitting this form, you agree to our Privacy Policy.