Engineering Digital
Transformation with
Intelligence
We transform businesses through software innovation and intelligent systems. We enable digital transformation by combining deep engineering capabilities with a strong understanding of business, operational, and industry-specific realities.
Spring Boot 2.x has run out of free runway
28 April 2026.
Reading Time: 4 Minutes.
Spring Boot 2.x exited open-source support in November 2023, the standard commercial extension ended in August 2025, and Spring Boot 3.5 itself reaches end of life in June 2026. Three forces have tightened the window further over the last eighteen months: regulation moved first, tooling commoditised, and CVEs sharpened. The work, when properly scoped, runs as a structured six-week pattern per application, with named exceptions that extend it for reflection-heavy code, hardware-locked dependencies, and regulated workloads. The decision worth making in the first half of 2026 is the planning conversation, not the upgrade itself.
Is the timeline most teams are working from actually right?
No. Spring Boot 2.x open-source support ended in November 2023, and the final patch on the 2.x line was 2.7.18 released on November 23, 2023. Commercial support through Broadcom / VMware Spring Runtime was extended from February 2025 to August 2025 in the standard tier; beyond that, support is available only through the paid Spring Enterprise Repository. Spring Boot 3.5 itself reaches end of life in June 2026. Spring Boot 4.0 is already the current line.
The calendar reads as if there is time. The buying cycle reads otherwise. Procurement, architectural review, scoping, and execution typically consume twelve to eighteen months end to end. A team starting the conversation today is realistically deploying into 2027.
Three forces have tightened the window further over the last eighteen months, and most engineering organisations have not yet absorbed all three.
What changed while teams were not watching?
Three things, in this order: regulation moved first, tooling commoditised, CVEs sharpened. Each on its own would be manageable. Together they have rewritten the cost-of-delay math.
Regulation moved first. The EU Cyber Resilience Act made Software Bill of Materials disclosure a regulatory obligation, not a best practice. An SBOM listing Spring Boot 2.x as an unsupported component is no longer technical debt; it is an audit finding. DORA, in force since January 2025, treats unsupported framework dependencies as ICT third-party risk for financial services. PCI DSS 4.0.1 enforcement (March 2025) does the same for payments.
Tooling commoditised. The Jakarta EE namespace migration (javax.* to jakarta.*) used to be the labour-intensive part of the upgrade. It no longer is. The Spring team’s own Spring Boot Migrator (Apache 2.0, free) handles much of it via OpenRewrite recipes under the hood. The Eclipse Transformer (Eclipse Public License 2.0 / Apache 2.0, free) does bytecode-level transformation, the path Apache TomEE, Payara, and Jakarta EE implementations rely on internally. AWS App2Container containerises generic Java applications including Spring Boot for ECS, EKS, or Fargate deployment. Azure Spring Apps provides a managed migration path for Azure-bound workloads. AI-assisted dependency upgrades catch the residual cases automated recipes miss. The work that used to take eight engineer-weeks now takes two.
CVEs sharpened. The Spring official security advisory page lists active vulnerabilities across the Spring portfolio, and any CVE published against a 2.x line after November 2023 has no open-source patch path. CVE-2024-38807, a signature forgery vulnerability in the Spring Boot jar loader, is one example: discovered in 2024, no open-source fix available for the 2.x line, available only via commercial extension or third-party extended support. The compensating-controls argument that worked in 2024 (we know it is unsupported, but we have other layers) no longer survives a serious security review.
An SBOM listing Spring Boot 2.x as an unsupported component is no longer technical debt. It is an audit finding.
What does the Sprint pattern actually look like?
The work, when properly scoped, runs as a structured Six-to-Eight-week sprint per application. The shape is consistent enough to be repeatable across an estate.
Week one is a dependency scan. Every direct and transitive dependency is catalogued against its current version, target version, and known breaking changes. Spring Boot Migrator or Eclipse Transformer produces the bulk of the inventory automatically. Human review surfaces the edge cases: internal libraries that have not kept pace, third-party libraries without Spring Boot 3-compatible versions, deprecated APIs being used in non-obvious ways.
Weeks two and three are the automation pass. The namespace migration runs at scale across the codebase. Where the automated recipes leave residual patterns requiring judgment, those are reviewed and remediated.
Week four and five addresses the breaking changes Spring Boot 3 introduced: Spring Security configuration restructuring, the servlet API namespace change, deprecated auto-configuration patterns. Each application’s specific exposure has already been documented during the dependency scan, so this week executes against a known scope rather than discovering surprises.
Weeks six and seven are test scaffolding and validation. Existing test coverage is verified against the upgraded codebase, gaps are filled, production-equivalent load testing confirms parity. Cutover is a routine deployment, not a migration event.
While week eight can be parked for production deployment and initial support.
Three things take the work out of this range. Heavy reflection-based code or custom security infrastructure can stretch week four. Applications with hardware-specific or licensing-locked dependencies need architectural workarounds. Regulated workloads requiring validation evidence run closer to ten to twelve weeks even when the engineering work itself is clean.
Why does the planning conversation matter now?
Because the cost of getting it wrong is asymmetric. Spring Boot 4.0’s improvements compound the modernisation argument rather than stand alone. Virtual threads remove a class of performance ceilings that previously required architectural workarounds. GraalVM native image maturity changes cold-start economics for serverless deployment. Spring AI 2.0 is becoming the standard integration surface for LLM workflows inside enterprise Java.
The team that begins the conversation in the first half of 2026 has runway for orderly planning: contracts negotiated against a known timeline, sequencing flexibility against release calendars, engineers allocated against quarterly objectives rather than incident response. The team that begins in early 2027, under audit pressure or after a CVE event, runs the same engineering work against tighter constraints and against vendors who know it. The cost premium shows up across procurement, contracting, and the loss of optionality on sequencing, not as a single line item.
The planning conversation, not the upgrade itself, is what determines which of those two paths an organisation ends up on.
How does an engineering team plan this?
Three questions belong on the planning agenda before the next budget cycle closes:
- What is the actual Spring Boot 2.x exposure across the estate? Application count, version inventory, deployment topology, integration surface. Without this number, the sizing conversation cannot begin.
- What regulatory regimes touch this exposure? CRA scope, DORA classification, PCI scope, sector-specific obligations. Each of these changes the urgency calculation independently.
- What is the realistic target landing zone? Spring Boot 3.x on Java 17 or 21, Spring Boot 4.x on Java 21 or 25, Quarkus for cold-start sensitive workloads, or a managed runtime path. Different applications in the same estate often warrant different answers.
None of these has a generic answer. Each has to be sized against the specific estate. The point of sizing them in the first half of 2026 is that the buying cycle and the regulatory cycle both compound over time, and the cost of the answer being wrong drops sharply with planning runway.
Frequently Asked Questions
When exactly did Spring Boot 2.x open-source support end?
Spring Boot 2.7.18 was released on November 23, 2023 as the final 2.x open-source patch. Open-source maintenance for the entire 2.x line ended on that date. After that, free security patches stopped flowing from the Spring project.
Do we have to migrate to Spring Boot 4 directly, or is Spring Boot 3 enough?
Either is defensible. Spring Boot 3.x on Java 17 or 21 is the lowest-friction landing zone for most applications, and the Jakarta EE namespace migration is the same regardless of target. Spring Boot 4 adds Java 21 baseline, virtual thread maturity, and Spring AI 2.0 as a first-class surface. For estates that will need any of those in the next 18 months, going straight to 4 avoids a second migration.
What takes a Spring Boot 2.x upgrade outside the six-week pattern?
Three things. Heavy reflection-based code or custom security infrastructure can stretch week four. Applications with hardware-specific or licensing-locked dependencies need architectural workarounds. Regulated workloads requiring formal validation evidence run closer to ten to twelve weeks even when the engineering work itself is clean.
