Planning Your Next Spring Boot Upgrade

How often should you upgrade Spring Boot? How important is it to be running the most current version? What should you consider when migrating between major versions? What can be challenging or potentially go wrong during the process?

This blog will address these questions and more so you can avoid rushed upgrades and transition smoothly between major and minor Spring Boot versions.

Spring Boot Release Cycle and Support Overview

Upgrades are often driven by the desire to access to the latest and greatest features and community support windows, so let's start by reviewing how often new versions of Spring Boot come out and how long they are supported. 

The Spring ecosystem (including Spring Boot) recently switched to a time-based release schedule to align better with the six-month OpenJDK release cycle. Major or minor versions now come out twice a year, usually in May and November. Each release only receives community support for 13 months, or about a year — so every year, two new versions are made available and two versions become end-of-life (EOL). 

As of this writing, the current version of Spring Boot is 3.5.2, with the release of 4.0 anticipated in November. Here's a table showing release and EOL dates for Spring Boot versions from the past few years:

Free community support for Spring Boot from the open source community is accessible through forums, GitHub, Stack Overflow, mailing lists, and blogs. Most of these channels are monitored by experienced Spring users and developers providing best-effort support. 

Spring Boot commercial support offered through third-party vendors like OpenLogic come with the benefit of service-level agreements (SLAs) and direct access to professional experts that have a deep knowledge of the Spring ecosystem. These vendors assist in troubleshooting issues, with guaranteed resolution times, as well as providing security patches and updates for EOL versions if they offer long-term support (LTS).

How Often Should You Upgrade Spring Boot?

Waiting to upgrade Spring Boot can leave an application vulnerable to attacks and compromise your ability to service your customers. Patch releases, especially ones related to security, should be applied immediately, and applications should be upgraded every six months for feature releases if you do not have extended commercial support. Major release migrations need to be performed annually. We recommend upgrading frequently and try to be no more than one major release behind the current version to minimize risk and avoid accumulating technical debt.

Back to top

Need Help With Your Spring Boot Upgrade or Migration?

In addition to 24/7 technical support, OpenLogic can assist with planning and executing your next Spring Boot upgrade or migration. Click the button below to talk with one of our Spring experts or get a quote. 

Talk to an Expert

Spring Boot Upgrade Challenges and How to Overcome Them

Most of the challenges that come with upgrading Spring Boot occur when migrating from one major version to another (i.e. from Spring Boot 2 to Spring 3). Below are some of the most common problems teams may experience and what OpenLogic recommends to avoid them. 

1. Component Compatibility Between Major Versions: Spring Boot has a bill of materials (BOM) that depends on certain versions of components like Spring, Spring Data, Hibernate, Jackson, etc. If you need a different version of these components, it could break compatibility with your version of Spring Boot. You might find yourself spending a lot of time investigating and fixing these issues because this can cause cascading affects to other components. For example, Spring Boot 2 uses a 5.x version of Hibernate while the newer Spring Boot 3 utilizes Hibernate 6.x. There are breaking changes between Hibernate 5 and 6 including stricter HQL/JPQL query parsing and data type changes. These issues will arise when performing a build and running the unit tests. 

Remember to not only test your build, including your unit tests, but also do a thorough runtime test of all application functionality. For the above Hibernate example, make sure to upgrade the JDBC driver due to the namespace change. 

2. Breaking Changes From Migrations: The most significant breaking change occurs when migrating from Spring Boot version 2 to version 3. The minimum requirement for Spring Boot 3 is JDK 17 which uses the newer Jakarta namespace that is part of Jakarta EE. This means any javax.* imports will become jakarta.*. Small codebases will have an easier time with this migration, but much larger projects may require significant time and effort to migrate. 

Integrated development environments (IDEs) and command line utilities tools exist to perform this one-time migration automatically and seamlessly. 

3. Performance Testing Scripts and Monitoring: Having performance testing scripts and monitoring is critical to your success with Spring Boot before and after your upgrade. Get a thorough baseline test before you upgrade or apply a patch to ensure your application’s performance is not affected. The tests and infrastructure need to mimic production as close as possible. It is not uncommon to encounter major performance issues after migrating from Spring Boot 2 to 3, usually related to Hibernate/JDBC that they did not have previously. 

Don't forget that a major version upgrade of Spring Boot is a large migration, so test thoroughly.

4. Dependency Issues: Many issues during a Spring Boot major release migration are caused by java.lang.NoSuchMethodError or java.lang.ClassNotFoundException during runtime. This is usually due to a dependency issue in the build. 

You can inspect the effective dependencies of a project that uses the Spring Boot library by running mvn dependency:tree in the same directory your application’s pom.xml resides in. Review the project's Java documentation or the project’s GitHub to determine in which version a method or class was introduced or removed. The IDEs can also be useful, to show you effective build paths.  

Best Practices for Spring Boot Upgrades and Migrations

Upgrading Spring Boot too quickly and deploying to production without a test plan or a full suite of performance test scripts can be as risky as migrating too slowly. For example, OpenLogic has had customers who changed the Java imports to the new Jakarta namespace and threw their application into production only to find performance issues that were not observed in the previous version. The issue was further complicated by the fact that they had no pre-production environment remotely similar to production. 

The following best practices are recommended to keep your upgrade or migration minimally disruptive:

• Test, test, and then test some more. In general, you should have numerous unit tests that validate the logic of the application which provide satisfactory code coverage and thoroughly test integration between components (e.g. auto-wiring). It is essential to have a complete suite of unit, integration, and performance tests which provide complete coverage in the event a small security patch or a large major version migration is causing a problem. Initializing writing these after the application has been live in production for years when an issue arises can be a lot of effort and put extra stress on your delivery timeframes.
• Security urgency and operational stability work hand-in-hand. It is important to use a repeatable playbook for patching so one minor patch does not turn into a bad deployment. Evaluate the urgency of a patch by asking the following questions:
  • What is the severity of the vulnerability and is it security-related?
  • What components does the patch affect?
  • Can you stage the rollout?
  • Does it only affect internal users or all public-facing users?
  • Do you need to upgrade to a minor point on a particular Spring component?  

           Also, resist the urge to make unrelated changes outside of the patch being deployed to minimize additional problems. 

• Plan your migration as a series of small reversible steps. As part of your playbook, consider writing a “rollback book” and testing it. This also applies to changes to the database. Determine if you can stage the rollout as well, although sometimes this is not an option (i.e. some deployments are an all-or-nothing rollout). Monitor the application before and after deployment and note any changes in system resources such as RAM, CPU, or disk activity. Also, remember to test external systems that make non-GUI calls into SOAP and REST endpoints. 

Final Thoughts

Planning and executing a Spring Boot upgrade is not just about staying current — it’s about maintaining security, stability, and performance across your applications. By understanding the release cycle, anticipating common challenges, and following proven best practices, you can approach each upgrade or migration with confidence. Whether you’re moving from one minor version to the next or tackling a major transition like Spring Boot 2 to 3, careful planning and thorough testing are essential to reducing risk. And of course, you can always partner with OpenLogic experts if you need additional guidance or Spring Boot support. 

Support For Your Entire Java Stack

OpenLogic supports Java distributions including OpenJDK, Oracle Java, and Eclipse OpenJ9, and offers free, quarterly OpenJDK builds. We also provide technical support for Tomcat and can assist with implementations, migrations, and upgrades.  

Explore Java Solutions

Additional Resources

• On-Demand Webinar - Modernizing Your Java Application With Open Source
• Blog - Tomcat 11 Overview: Updates and New Features
• Solution - OpenJDK Support and Services
• Blog - Spring RCE 0-Day Vulnerability: What to Know About "Spring4Shell"