Lessons Learned from Upgrading a Legacy Spring Boot Application to 2.0

Our team was among the first at Snowball to adopt Spring Boot (v1.2.4 released in mid‑2015). Over the years many versions (1.2, 1.3, 1.5) have been used across teams, leading to middleware version conflicts. We finally upgraded the entire backend to Spring Boot 2.0 during a dedicated time window in April.

New Features – Spring Boot 2.0 brings Reactive Spring & WebFlux thanks to Spring 5.0, introducing a fully reactive programming model, HTTP/2 support, enhanced Actuator, Quartz integration, and more.

Reactive programming (RP) emphasizes asynchronous, message‑driven flows. While most Java libraries remain blocking, Spring’s new stack provides reactive alternatives; however, JDBC is still blocking, and we hope Spring Data Reactive will address this.

Component replacements include Lettuce for Redis (instead of Jedis), Caffeine for caching (instead of Guava), and HikariCP as the default connection pool (replacing Tomcat Pool). These choices reflect performance and simplicity considerations.

Upgrade Process – Official guidance suggests first moving to 1.5 as a stepping stone, but we took a more aggressive approach, updating dependencies, configurations, and code in a single large PR (over 250 files changed). We leveraged starters such as spring-boot-starter-json, spring-boot-starter-test, and spring-boot-starter-cache to simplify dependency management.

Configuration changes were extensive; the new spring-boot-properties-migrator module helps migrate keys, and we recommend using lower‑case kebab‑case in .properties and .yml files.

Path Matching Issue – Spring Boot 2.0 disables suffix‑based path matching by default. Our team’s REST endpoints did not use suffixes, but another team added ".json" extensions, causing all those endpoints to fail. The fix was to re‑enable suffix matching.

HTTP PUT Method Filter – During testing we discovered duplicate parameters on PUT requests. The HttpPutFormContentFilter (introduced in 1.5) processes PUT/PATCH bodies, but legacy clients sent parameters both as query strings and in the body, leading to conflicts. Temporarily disabling the filter resolved the issue until clients were updated.

Swagger Compatibility – After the upgrade Swagger stopped working. The solution involved removing old security configurations and adding resource mappings to make Swagger UI compatible with Spring Boot 2.0.

Summary – The three‑week upgrade covered more than ten subsystems. Apart from the single production incident (path‑matching), the migration was smoother than expected. Key take‑aways: deep familiarity with the codebase, thorough reading of official docs beyond upgrade guides, and allocating ample, focused time.

We also note that Snowball is hiring Java engineers, DevOps engineers, test engineers, and algorithm engineers; interested candidates can refer to the original posting for details.