Engineering Practitioner Brief / 18 May 2026

Java and Spring Legacy Cost

Java has unusually long-lived production deployments and Spring is the framework most of them run on. That combination makes Spring upgrades the most common single-framework cost line in enterprise tech-debt conversations. This page collects the per-step cost across the JDK ladder (8 to 21), the Spring ladder (3 to 6), and the Java EE to Jakarta EE rename that wraps both. Numbers assume US fully-loaded engineer rates of around $85 per hour.

The JDK Ladder

Java versions matter for Spring because each Spring major has a JDK floor. Spring 5 requires Java 8. Spring 6 requires Java 17. The JDK ladder is therefore a prerequisite for the Spring ladder, and the cost of moving each step is roughly stable per application.

The JDK 8 to 11 step is the most expensive single hop because of the Java Platform Module System and the removal of internal com.sun.* APIs that many libraries depended on. The JEP 320 removal of CORBA and Java EE modules from the JDK (JDK 11) also forces affected applications to add explicit dependencies they had previously been getting for free. The official Oracle JDK Migration Guide enumerates the changes per release.

The Spring Ladder

Spring releases maintain backward compatibility well enough that single-major-version upgrades are usually straightforward. Multi-major jumps compound the deprecation work and often pull in transitive library upgrades that have their own breaking changes.

The Spring 5 to 6 step is the most expensive single hop in the modern era because of the javax-to-jakarta rename. Spring Boot 3 inherits the same constraint. Most teams treat the JDK upgrade, the Spring upgrade, and the Jakarta rename as a single multi-month project rather than three sequential ones, because the test and deploy overhead is dominated by the cutover and is paid once.

The Java EE to Jakarta EE Rename

When Oracle transferred Java EE stewardship to the Eclipse Foundation in 2017, the Eclipse Foundation was prohibited from continuing to use the javax package namespace for new versions. The result was the Jakarta EE 9 release in 2020, which renamed every javax.* package to jakarta.*. Spring 6 and Spring Boot 3 require Jakarta-namespace APIs.

The mechanical part is well-handled by the OpenRewrite migration recipes: import statements, fully-qualified names in strings, and most third-party library references get rewritten automatically. The harder part is libraries that have not yet published Jakarta-namespace versions. As of 2026, the major libraries (Hibernate, Tomcat, Jetty, Jersey, Bean Validation implementations) all have Jakarta-namespace releases. Smaller libraries and internal forks often do not, and have to be either upgraded, patched locally, or replaced.

Reference timing: a 200K-line Spring application with a typical library footprint takes 100 to 250 engineer-hours for the namespace rename alone, of which 60 to 80 percent is handled by OpenRewrite. The remaining hours are manual repairs for libraries without Jakarta releases.

The Legacy CI Tax (Hudson and Ancient Jenkins)

Hudson was renamed Jenkins in 2011. Some enterprise installations are still running Hudson, or running Jenkins versions from before 2018. The Jenkins security advisory feed publishes dozens of CVEs per year, some of which affect old core versions that are no longer eligible for patches. The decision to leave legacy Jenkins running is the decision to accept that risk.

The cost of upgrading a 10-year-old Jenkins is dominated by plugin recreation. Modern Jenkins plugins often have different configuration interfaces than their old counterparts. Pipeline scripts written for freestyle jobs do not run on declarative pipelines without rewriting. Some plugins are abandoned and have no modern equivalent, forcing a substitute plugin choice or a custom build step.

Typical sizing: 80 to 300 engineer-hours per Jenkins instance, plus 4 to 12 hours per build pipeline rewrite. For an enterprise running 50 build pipelines on a legacy Jenkins, the full migration is a quarter-long project. Migration to a managed CI like GitHub Actions, GitLab CI, or CircleCI is usually a similar magnitude of work and reduces the long-term maintenance overhead. See the sister site cicdcost.com for the comparative-cost arithmetic.

The Dependency Layer Beneath Spring

Spring rarely runs alone. The libraries that show up most often in Spring tech-debt audits are also the ones that block upgrades:

• Hibernate. Major upgrades roughly track Spring majors. Hibernate 5 to 6 was the javax-to-jakarta hop; Hibernate 7 (2025) brought further breaking changes. Most JPA-heavy applications spend 40 to 100 hours per major Hibernate upgrade on subtle query-semantics differences.
• Jackson. Stable interface, occasional breaking changes around polymorphic deserialisation and Kotlin support. Upgrade cost typically low (under 20 hours per app per major) but worth keeping current because of regular CVE flow.
• JUnit. JUnit 4 to JUnit 5 is a substantial test rewrite. For a large test suite, 40 to 150 hours of test refactoring, partly automated by IntelliJ's inspection.
• Lombok. Lombok occasionally breaks when newer JDKs change internal compiler APIs. Keeping Lombok current with the JDK is a small but recurring tax.
• Tomcat or Jetty. Embedded servlet container choice propagates Spring constraints. Tomcat 10+ is Jakarta-namespace; Tomcat 9 is the last javax line. Switching servlet container is rare but happens when one drops support for the target JDK.

Recommended Sequence for a Spring 3 / JDK 8 Starting Point

A pragmatic ordering when starting from a Spring 3, JDK 8, javax-namespace baseline:

1. JDK 8 to JDK 11. The biggest single-hop JDK cost; pay it first while still on a stable Spring 4 or 5.
2. Spring 3 to Spring 5 in two steps (3 to 4, then 4 to 5). Build pipelines and tests should still run cleanly on JDK 11 throughout.
3. JDK 11 to JDK 17. Smaller hop, sets up Spring 6 eligibility.
4. Apply the OpenRewrite javax-to-jakarta recipe on the Spring 5 codebase. Verify in a long-running branch.
5. Spring 5 to Spring 6, with the Jakarta namespace already in place. The Spring 6 upgrade becomes mostly mechanical.
6. JDK 17 to JDK 21. Additive for most applications; virtual threads become available for new code.

Total elapsed time for a 200K-line Spring application: typically 12 to 18 months of effort, with shipping continuing throughout via the ladder pattern. See framework migration cost for the per-LOC summary across multiple stacks.

Related Reading

• Framework migration cost
• Dependency debt cost
• .NET Framework legacy cost
• JavaScript and Node legacy cost
• Legacy code refactoring cost

Frequently Asked Questions