Spring Boot 2.7 Nears End of Support: Boot 4, Extended Support, or a TypeScript Rebuild?

If your core system runs on Spring Boot 2.7, it hasn't seen a single open-source security patch since November 2023 — and on December 31, 2026, commercial VMware Tanzu support goes away, and with it the last safety net. What many IT leaders have been pushing ahead of them for more than two years now has a hard due date. Five and a half months is enough for an orderly decision. It is no longer enough for an orderly decision plus a full migration project.

Hence this article: no alarmism, just a sober decision tree. Three paths are open — migrating to Spring Boot 4, buying extended support, or rebuilding service by service on a TypeScript stack. Each path is the right one for certain situations. Which one is right for yours comes down to three criteria: the application's remaining lifespan, your team situation, and how deeply the system is integrated.

A quick reminder of how we got here: open-source support for Spring Boot 2.7 already ended in November 2023 with the final courtesy patch, 2.7.18. Since then, Boot 2.7 has existed only behind a paywall — VMware Tanzu extended commercial support through December 31, 2026. After that, the only option left is third-party vendors who maintain patches for end-of-life versions for a fee.

That alone would be a manageable deadline. What makes the situation delicate is what happened in parallel: Spring Boot has no LTS model. Every minor version gets twelve months of open-source support, and then it's over — 3.3 expired in June 2025, 3.4 in December 2025, and since the end of June 2026, when 3.5 reached end of support, the entire 3.x line has been without open-source patches. As of today, only the 4.x line is maintained. If you diligently migrated to Boot 3 back in 2023, you're already facing another mandatory upgrade.

The pattern behind this is the real finding: the Spring stack structurally forces you onto a permanent upgrade treadmill — or into support contracts. For comparison: Node.js 24 runs as Active LTS through October 2026 and then receives maintenance patches until April 30, 2028, free of charge and with roughly 30 months of predictability per LTS line. That difference is not a feature argument; it's an operating cost line item — we ran the full numbers in our decision-maker comparison of NestJS vs. Spring Boot.

The jump from Boot 2.7 to the 3.x or 4.x line is not a version bump; it's a platform change: Spring Boot 3 strictly requires Java 17 or newer, on top of the namespace move from javax to jakarta — a change that cuts through every single dependency. For many existing landscapes, that means two modernizations in one project: first the runtime, then the framework. According to New Relic 2024, nearly 30 percent of Java production applications were still running on Java 8 — if that's where you stand, you have the longest road ahead.

And the JDK question opens a second file: licensing. Oracle's per-employee model charges $15 per employee per month (for companies under 1,000 employees) — you pay for the entire workforce, not the actual Java users. According to Gartner, that makes Java licensing two to five times more expensive than the old costs. As a sample calculation: a mid-sized company with 500 employees would land at roughly $90,000 per year. OpenJDK distributions are the fair, workable alternative — but the clock is ticking there too: Oracle Premier Support for JDK 17 ends on September 30, 2026, and free Temurin community support for Java 8 ends in November 2026.

That this is no theoretical risk is documented in the July 2025 survey by Azul and the ITAM Forum: 73 percent of companies were audited by Oracle over Java in the past three years, and one in four spends more than $500,000 per year resolving license non-compliance. The Boot 2.7 question is therefore really a stack question — which is exactly why it pays to lay all three paths side by side instead of reflexively booking the upgrade.

The default path, and for many systems the right one. You stay in a familiar ecosystem, your team's Spring expertise remains fully usable, and the migration is a well-documented route. Two things need honest budgeting: the mandatory bundle of Java 17+ and the jakarta migration — and the fact that after migrating, you're back inside the twelve-month window. The next mandatory upgrade is built in by design. Path A is not a one-time project; it's entry into a permanent cycle that belongs in your operating cost plan as a recurring item.

Buying time. Through the end of 2026, the Tanzu contract carries you; after that, third parties like HeroDevs take over patch delivery for end-of-life versions. That is a legitimate path — for applications with a defined expiration date. If a system will be replaced in two years anyway, paid standstill is cheaper than any migration. Just don't kid yourself: extended support buys time, not a future. The migration won't get cheaper later, the team keeps working on yesterday's stack, and the staffing side counts too: senior Java developers cost €75,000 to €95,000 per year according to Robert Half — and for legacy-version expertise, the market will get tighter, not looser.

The path hardly any Spring migration guide mentions — for obvious reasons. If a mandatory upgrade touches every dependency anyway, that is the natural moment for the fundamental question of whether every service really has to keep living on the JVM. This is not a big-bang rewrite: it's the incremental rebuild of individual services via the strangler pattern. New TypeScript services built in NestJS dock onto the existing system through API contracts and take over responsibility step by step. NestJS brings along the concepts your team knows from Spring — dependency injection, modules, guards — and with roughly three million weekly npm downloads and production use at Adidas, Autodesk, and Decathlon, it is no niche experiment. For the newly built services, the JDK licensing question disappears entirely; the runtime foundation, Node 24 LTS, is covered free of charge through 2028. How coexistence with the Java core system works in practice — API contracts, team boundaries, data ownership — is what we described in our article on two-speed IT alongside the Java core system.

First: the application's remaining lifespan. Will the system still be under active development in five years? Then path B is out — paid standstill is the most expensive option for living systems, because it only postpones the decision and makes it pricier. For systems with a decided retirement date, the opposite holds: there, extended support is the most honest path, and any migration would be burned budget.

Second: the team situation. A well-rehearsed Spring team with secured succession makes path A cheap and low-risk. If you're already struggling to fill Java positions, factor the talent market into the math: according to the Stack Overflow Developer Survey 2025, 48.8 percent of professional developers use TypeScript, versus 29.6 percent for Java. And the switch from Java to TypeScript is more feasible than many expect — precisely because NestJS adopts Spring's architectural patterns, it is not a culture break for a Java team but a language change on familiar architecture.

Third: integration depth. A monolithic system with dozens of deeply entangled interfaces cannot be meaningfully carved out service by service — there, the path runs through A or B. A landscape with reasonably clean service boundaries and API contracts, by contrast, is the ideal case for path C: start with the service under the highest pressure to change, and leave the rest running in peace.

One line we draw deliberately ourselves: for CPU-intensive workloads — batch processing, compute-heavy data jobs, massive parallelism — the JVM remains the stronger platform; independent benchmarks show a 30 to 68 percent advantage over Node.js there. Those services don't belong in TypeScript just because a deadline is looming. The home turf of Node and NestJS is I/O-heavy API and web services. My experience from architecture reviews: exactly those services make up the bulk of most Boot 2.7 landscapes — and almost no landscape is an either-or. The realistic target state is almost always deliberate coexistence — path A or B for the core, path C for everything that needs to evolve fast.

The concrete next step is not a migration project; it's an inventory. List every service on Boot 2.7 — and, if you're honest, the ones on 3.x as well — with three data points: expected remaining lifespan, change frequency over the past twelve months, and the number and depth of its interfaces. Then assign each service one of the three paths — per service, not across the board. If you're planning your 2027 budget in the fourth quarter, you need that mapping beforehand; otherwise the calendar decides the path instead of the architecture.

If you want to work through the three-path question concretely for your landscape: as a TypeScript agency, we build path C — the service-by-service rebuild in NestJS and Next.js — ourselves, and that is exactly why we will tell you openly in a 30-minute intro call if path A or B is the better one for your system. A deadline is a poor architect — an inventory with clear criteria is a better one.

As of July 2026. Support and version dates per endoflife.date, spring.io, and the Oracle support roadmap; license prices are US list prices, salary ranges per Robert Half, sample calculations labeled as such.