Where Java versions stand
| Version | Released | Oracle Premier Support until | Oracle Extended Support until |
|---|---|---|---|
| Java 8 | March 2014 | March 2022 | December 2030 |
| Java 11 | September 2018 | September 2023 | January 2032 |
| Java 17 | September 2021 | September 2026 | September 2029 |
| Java 21 | September 2023 | September 2028 | September 2031 |
| Java 25 | September 2025 | September 2030 | September 2033 |
Source: Oracle Java SE Support Roadmap, checked 5 October 2026. Oracle’s table carries footnotes on the extended dates, and other JDK vendors publish their own terms — check the distribution you actually run.
The practical point: Java 17, the obvious target a few years ago, has already left Oracle’s Premier Support. A migration started today is usually better aimed at Java 21 or 25.
Three changes that make the jump real work
| Change | Where it came from | What it means for your code |
|---|---|---|
| Java EE and CORBA modules removed | JEP 320, Java 11 | Code using XML web services, JAXB, CORBA or the old transaction APIs needs replacement libraries |
| JDK internals strongly encapsulated | JEP 403, Java 17 | Code and libraries reaching into JDK internals stop working until updated |
| Spring Boot 3 requires Java 17 and Jakarta EE | Spring Boot 3.0 release notes | Moving to a supported Spring Boot means renaming the Java EE APIs throughout the code |
Each of these is well documented. What makes the cost uncertain is how much of your code — and your dependencies — relies on them.
What drives the cost
| Driver | Why it matters |
|---|---|
| Test coverage | Without tests, every change has to be checked by hand — or not at all |
| Old and abandoned libraries | Each needs a newer version or a replacement |
| Framework versions | An old Spring, Hibernate or application server may need its own upgrade |
| Number of services | Ten services can move one at a time; one large application cannot be split as easily |
| Build and deployment | Build tools, containers and servers move with the code |
Upgrade in place, or modernize?
If the code is sound and the framework still exists, an upgrade in place is usually right. If the upgrade means replacing most of the framework anyway, it may be the moment to move module by module to something new, while the old system keeps running the parts that have not moved.
What to have ready before you ask for a quote
- Which Java version and frameworks each application runs on now
- Roughly how many services or modules there are, and their test coverage
- Which libraries and outside systems they depend on
- Which parts can never go down
How Pricient quotes a modernization
Modernization starts with a Legacy System Specification Assessment. It produces a written specification, a risk register, a keep-vs-replace cost comparison and a staged replacement plan, and its fee is credited in full against the first build stage if it starts within 90 days of the report. You can start with a conversation about the system; we ask for read-only code access only when the assessment begins. Tell us what you are running and you get a fixed quote for the assessment.