Spring Framework 6: The Full Cost of Migrating from v5 to v6

With support for Spring Framework 5.3 ending on August 31, 2024, many organizations are racing to upgrade before serious security issues surface. But as teams dive into the Spring Framework 6 migration, they’re often met with more challenges than expected. This isn’t just a simple version update—migrating to Spring Framework 6 is a complex, resource-intensive process, particularly for those on older dependencies. In this article, we’ll break down the real costs, time commitments, and strategic considerations of a successful Spring Framework 6 migration.

‍

Why is Spring Framework 6 migration significant?

Spring Framework 5 was written with backwards compatibility and support for old versions of dependencies. In contrast, Spring Framework 6 was written to be a framework that focuses on supporting the next decade of new technologies and innovations. As such, Spring Framework 6 significantly increased the minimum versions of many core dependencies such as Java, Jakarta, and Tomcat.

Spring co-founder Juergen Hoeller explained the significance in a presentation he gave in preparation for the launch of Spring Framework 6 in 2022.

‍“This is meant to be a beginning of a new generation. We are drawing a strong line (stronger than you might expect). With Spring Framework 6 we are really trying to prepare everyone - all the applications to be written and all the systems to be upgraded - for 2022 and beyond. So we are really preparing you for another decade. So the baseline upgrades and feature deprecations might be a little stronger and be on the aggressive end of the spectrum in terms of raising the baseline.”

Some organizations have the resources to set themselves up for the next decade of innovation, but many are in positions where migration is not immediately feasible.. For organizations weighing the challenges of staying on Spring Framework 5 versus the resources needed to migrate to Spring Framework 6, the choice can feel like being stuck between a rock and a hard place. For those organizations, we have created Never-Ending Support (NES) for Spring Framework, support for your Spring applications that ensures you stay secure, compliant and stable without migrating. 

Let’s break down the true costs of migration, empowering you to make a business decision that best aligns with your goals and priorities.

‍

Minimum dependency versions

‍

This is not a flip-a-switch migration. The migration to Spring Framework 6 includes multiple rounds of dependency upgrades, each of which will come with its own set of difficulties.

‍

‍

More bad news

Spring Framework 6.0 OSS has also reached end of life so organizations will need to upgrade to at least Spring Framework 6.1 which brings its own set of minimum required dependency upgrades including Jackson, Kotlin, and SnakeYAML to name a few.

‍

So what does it cost?

Migrating Spring Framework apps is more complicated (and costly) than it seems at first glance. The cost grows significantly based on several factors:

• Number of Spring Products (N): More projects = more complexity and a longer timeline.
• Project Size (S): Big codebases with high complexity demand more effort.
• Architecture (A): Monoliths or Microservices? Monoliths are harder to migrate in one go, while microservices multiply the number of migration steps and integration points.
• Shared Libraries (L): Migrating codebases with shared libraries or models generally means you need to do multiple iterations of migration, starting with the libraries and then on through the dependency tree.
• Major Dependency Updates (D): Out of date dependencies will require their own migrations prior to running the Spring migration.
• Spring Project Utilization (U): The more Spring modules a project relies on (Security, Data, Cloud, etc.), the more efforts required to migrate between versions.
• Velocity (V): The speed with which your team migrates. Find this by reviewing migration guides and comparing progress on a complete dev + test + validation cycle.

To get an estimate of a given project, organizations can use the following table to calculate the rough magnitude of effort: 

‍

‍

Here are a few examples for reference:

Example 1:
Small Monolithic Codebase

• Scope: Single, small codebase (up to 30,000 lines of code) with Spring Framework dependencies.
• Requirements: Requires updates to JDK 17, Jakarta, Tomcat, and includes 10 Spring project dependencies.
• Team: 1 full-time developer assigned to migration.
• Estimated Time: Approximately 6 weeks, including setup, testing, and final validation.

Example 2:
Medium Codebase with Microservices

• Scope: A medium-sized codebase (30,000–80,000 lines) with 5 microservices, each sharing 2 common models or libraries.
• Requirements: Requires updates to JDK 17, Jakarta, Tomcat, and includes 30 Spring project dependencies.
• Team: 4 developers working on the migration.
• Estimated Time: Roughly 12–14 weeks due to the added complexity of shared libraries and microservices coordination.

Example 3:
Large, Complex Codebase with Many Microservices

• Scope: Large codebase (80,000+ lines) consisting of 20 microservices, each with shared models or libraries.
• Requirements: Requires upgrades to JDK 17, Jakarta, Tomcat, and includes 100 Spring project dependencies.
• Team: 10 developers dedicated to migration.

Estimated Time: 6–9 months, factoring in dependency updates, integration of shared libraries, and extensive testing.

‍

‍

Additional concerns and considerations:

There’s a lot that can go sideways during migrations. Here are some other things to consider:

1. Automation & Testing Coverage:
   • Weak test coverage will lead to massive regression testing churn during migration.
2. Spring Boot migration:
   • Spring Boot 3 is built on top of Spring Framework 6. If you are using Spring boot and are upgrading to Spring Framework 6 then you will need to plan for additional resources to migrate to Spring Boot 3 as well.
3. Duplicate Development or Stalled Releases:
   • You’ll need to decide between continuing development in both the legacy and migrated code or delaying feature releases until migration is complete. Either way, there’s a cost.
4. Vulnerable to Security Risks:
   • As Spring Framework 5.3 OSS is already end of life, your applications will be at risk of new security vulnerabilities during the whole migration window
5. JDK17 changes
   • From Java8 to Java17, java has changed a lot about the JVM and memory management. Though you will likely see improvements in startup time, garbage collection and general performance with Java17, you will also have to restart the process of fine-tuning performance of your application and servers.

‍

Conclusion?

Migrating to Spring Framework 6 is a significant and resource-intensive investment, especially after support for Spring Framework 5.3 has ended. With increased baseline requirements, complex dependency upgrades, and architecture-specific challenges, a successful migration demands careful planning, dedicated resources, and substantial development costs.

For organizations where migration isn’t feasible, HeroDevs offers a secure alternative with Never-Ending Support (NES) for Spring Framework 5. NES provides ongoing security patches and compliance updates, allowing you to keep your Spring Framework 5 applications secure, stable, and operational—without the disruption or high costs of a full migration to Spring Framework 6. By choosing HeroDevs, you can protect your existing investment and maintain control over your technology roadmap.

‍