Spring Boot 2.7: Upgrade or Extended Support?

Upgrade Spring Boot 2.7 if the application will outlive 2029, and use extended support to cover the time the upgrade takes, not to avoid it. Open source support for 2.7 ended on 30 June 2023, the last public release is 2.7.18 from 23 November 2023, and Spring lists commercial support for the line until 30 June 2029. That window makes staying a legitimate choice. It does not make it a free one.

Three questions settle most cases: how many applications are on 2.7, whether they already run on Java 17, and when the next release train has room. The rest of this post covers what the upgrade involves, where to land, and when extended support is the right bridge. Dates for every Boot line are in Spring Boot end of life: EOL dates for 2.7, 3.x and 4.x.

The jump from 2.7 to 3.x is the hard one. Spring's Spring Boot 3.0 migration guide sets the order, and most of the work falls in five places:

• Latest 2.7.x first. The guide says to upgrade to the latest 2.7.x before you start, which is 2.7.18.
• Java 17. Spring Boot 2.7.18 requires Java 8 and is compatible up to Java 21. Spring Boot 3.0 requires Java 17 or later. For many 2.7 applications the JDK change is a project on its own.
• javax to jakarta. Jakarta EE now uses jakarta packages, not javax, so imports change and every dependency, direct or transitive, needs a release that uses the new packages. Libraries Boot does not manage, Spring Cloud for one, need a compatible version chosen before you start.
• Components that changed underneath you. Boot 3.0 moves to Spring Security 6.0, which applies authorization to every dispatch type, to Hibernate 6.1 and to Spring Batch 5.0, where @EnableBatchProcessing is now discouraged. Only the health endpoint is exposed over JMX by default, and classes deprecated in 2.x are gone.
• The embedded server. Boot 2.7 embeds Tomcat 9.0 on Servlet 4.0. Boot 4.1 needs Servlet 6.1, which means Tomcat 11 or Jetty 12.1.

The spring-boot-properties-migrator module reports renamed and removed properties while you work. Take it out once the migration is done.

Spring Boot 3.5 is the obvious landing spot and the wrong place to stop. Its open source support ended on 30 June 2026, so a team that stops there is back to needing a patch route within months. It does carry the longest commercial window of any line, to 30 June 2032, which makes it a sound stop where Boot 4 is too much for now.

Boot 4.0 has open source support to 31 December 2026 and commercial support to 31 December 2027. Boot 4.1 has open source support to 31 July 2027 and commercial support to 31 July 2028. The Spring Boot 4.0 migration guide says to upgrade to the latest 3.5.x first, so the realistic path is 2.7, then 3.x, then 3.5, then 4.x. Both hops need Java 17, and Boot 4 adds its own changes: Jackson 3 as the preferred JSON library, smaller modules in place of large jars, and no Undertow support.

Extended support is the right call when:

• Dozens of applications sit on 2.7 and each has to move on its own release train. Support covers the ones still waiting.
• A dependency has no jakarta release, or a vendor-supplied library pins you to Java 8.
• An audit, a certified environment or a freeze makes a change riskier than a patch.
• The test suite is too thin to trust a two-hop upgrade.

Upgrading is the right call when one or two applications are on 2.7, they already run on Java 17, and the team has a quarter. The upgrade is a fixed cost. A subscription is paid every year until you do it anyway.

Extended support patches the line you run. It does not move your JDK, your libraries or Tomcat 9 forward, and the EOL guide lists which Framework and Security versions sit behind 2.7. The paid routes are Broadcom's Spring subscription, which AceMQ resells to US customers, and other vendors; Tanzu Spring licensing and consulting sets out the Broadcom route.

This order isolates one kind of failure at each step:

1. Inventory every Spring Boot application with ./mvnw dependency:tree or ./gradlew dependencies, and record the Boot, Framework and Security versions and the JDK.
2. Move to 2.7.18 and add the properties migrator.
3. Move the JDK to 17 while still on 2.7, which Boot 2.7.18 supports. A failure now is a JDK problem, not a Spring one.
4. Do the jakarta and Spring Security 6 work on the way to 3.5.
5. Move to 4.x when the application next has a release window.

AceMQ inventories Spring estates, picks a route for each application and supports the result 24/7 with a 15-minute emergency response. For a Spring Boot 2.7 or 3.x estate, see Spring Boot extended support and upgrade services.

• Spring: Spring Boot generations and support dates
• Spring Boot 3.0 Migration Guide
• Spring Boot 4.0 Migration Guide
• Spring Boot 2.7.x reference: system requirements
• Spring Boot 4.1 reference: system requirements
• Maven Central: spring-boot 2.7.18

Dates and requirements checked on 20 October 2026.