Spring Boot & Java migration, one service at a time

Open-source support for Spring Boot 2.7, the last of the 2.x line, ended in November 2023. Since then security fixes for it have come only through paid commercial support, and the libraries around it have moved on: Spring Boot 3 and later need Java 17 as a minimum, use the jakarta namespace, and are what current versions of Hibernate, Spring Security, Spring Cloud and most drivers and SDKs are built for. Every year an application stays behind, the gap it eventually has to cross gets wider.

The risk is usually less visible than the cost. A Java service on an unsupported framework tends to sit behind a login, handle personal or financial data, and depend on dozens of transitive libraries — each a potential vulnerability that the security team cannot patch without the upgrade nobody has scheduled. For our banking and government clients, that is an audit finding, not a technical preference.

There is a positive case too. Newer Java releases bring a faster runtime and better garbage collectors, Java 21 adds virtual threads that Spring Boot can use for request handling with a single property, and current Spring Boot brings first-class observability, native-image support and a security model that is easier to reason about. We measure the effect against a baseline taken before the migration starts, and report the numbers rather than promise them.

Every migration starts with a one- to two-week assessment of the code base as it actually runs. We read the build files and the dependency tree, find every use of javax packages and removed JDK APIs, list the application servers, agents and deployment scripts, check what the tests cover, and run the application on the target Java version to see what fails first. Automated tools do the counting; engineers decide what each finding means.

The output is a plan you can act on with or without us: every module and dependency classified as upgrade, replace or retire, with effort against each; the migration path that fits; the behaviour changes that need a product decision rather than a code change; the order in which services move; and a fixed price for the implementation.

• Code — Java and Spring versions, javax usage, removed APIs, custom security and persistence code
• Dependencies — every library and its supported version, end-of-life components that need replacing
• Runtime — application server, JVM flags, agents, container images, deployment pipeline
• Tests — what is covered, what is not, and what needs characterisation tests before migration
• Deliverables — component-by-component plan, migration path, order of work, fixed-price proposal

Spring Boot 2.7 to 3 is the most common path and the most mechanical one. The javax-to-jakarta change touches imports across the code base and in every library that shares those types; Spring Security drops WebSecurityConfigurerAdapter in favour of SecurityFilterChain beans; Hibernate 6 changes how some queries and ID generators behave; tracing moves from Spring Cloud Sleuth to Micrometer Tracing; and a number of configuration properties are renamed. Recipe-based tools such as OpenRewrite handle most of the mechanical edits; the security configuration and the persistence behaviour are reviewed and tested by hand. From a clean Spring Boot 3 code base, the step to Spring Boot 4 is much smaller.

Spring Boot 1.x, or 2.x before 2.7, goes to 2.7 first. Spring's own guidance is to reach the last 2.x release, clear its deprecation warnings and only then make the jump to 3 — it turns one large, risky change into two smaller ones, each of which can be released and verified on its own.

Java 8 or 11 to 17, 21 or 25 can be done on its own, before the framework moves. Spring Boot 2.7 runs on Java 17, so upgrading the JVM first and the framework second is a common way to split the risk. The work is replacing JDK modules that were removed (JAXB and JAX-WS among them), opening or removing access to internal JDK APIs, updating build plugins, agents and bytecode libraries, and checking garbage-collector and TLS behaviour under production-shaped load.

Spring MVC applications that are not on Spring Boot at all — WAR files on WebLogic, WebSphere, JBoss or Tomcat, configured in XML — are the largest job. We move configuration to Java, externalise it, and either keep a WAR on a current Jakarta EE server or move to Spring Boot's embedded server in a container. Where the application is a monolith, we split it one bounded context at a time behind a routing layer, so the old and new code run side by side until the last route moves. How the resulting services are designed is covered on our Spring Boot microservices page.

Bank of Baroda's Early Warning System was a monolith built for one bank's data. After the mergers with Vijaya Bank and Dena Bank it had to ingest the merged entities' data as well, under tighter RBI scrutiny. We decomposed it into Spring Boot microservices on Java 11 behind Liferay DXP 7.4, with Angular portlets for the risk officers. Ingestion now scales independently of the analytics and the approval workflow — which is how the system absorbed three times the data volume — and risk-review cycles fell from two days to four hours. The migration plan included verification before cut-over, and no data was lost.

ICICI Bank ran four separate Java applications, each with its own infrastructure, team and login. We moved them onto one platform in phases, one application at a time, each phase ending with that application's users and data fully moved before the next began. The business logic stayed in Java 11 and Spring MVC where it belonged, while the screens were rebuilt as React portlets — infrastructure cost fell 45 % and pages loaded 55 % faster.

The same discipline runs through our CareEdge work, where several applications were consolidated into one platform alongside a Spring Boot early-warning system. The architecture behind these systems is written up in Building an Early Warning System on Spring Boot.

The hardest part of a migration is knowing that the new version behaves like the old one. Before we change code we write characterisation tests around the behaviour that matters — API responses, calculations, scheduled jobs, error handling — so the old system documents itself. Contract tests pin every API the service exposes and consumes, and integration tests run against real databases and brokers with Testcontainers rather than mocks.

We also take a performance baseline on the old version — throughput, latency, memory, start-up time — and run the same load against the migrated one. For data-heavy services we compare outputs of the old and new versions on the same input, and where the risk justifies it we run both in parallel in production with the new one in shadow mode before it takes real traffic.

• Characterisation tests written first, against the running system
• Contract tests on every API, so consumers are not surprised
• Testcontainers integration tests against real databases and message brokers
• Performance baseline before migration, compared after
• Shadow or parallel running for high-risk, data-heavy services

The assessment is a fixed fee and takes one to two weeks. As a rough guide, a single Spring Boot 2.7 service with reasonable test coverage moves to Spring Boot 3 in one to three weeks; a service on an older Spring Boot, or with little test coverage, takes longer because the tests have to be written first; and a Spring MVC monolith split into Spring Boot services runs over several months, released in slices so the business sees progress long before the last route moves. The assessment turns these ranges into a dated plan for your code base.

Six things set the cost: the number of services and modules; how much of the code depends on javax APIs and removed JDK features; custom security and persistence code; test coverage, because missing tests have to be written before anything else; the number of environments and the state of the pipeline; and how much downtime the business can accept. We quote the implementation as a fixed price for the scope in the assessment, with change control for anything found afterwards.

Cut-over is rehearsed to a script. Services move one at a time, behind a gateway or load balancer that can send traffic to either version; the old version stays deployed and ready for an agreed rollback window; and the decision to go ahead or roll back is made against a checklist of tests, metrics and reconciliation results, not a feeling. Database schema changes are versioned with Flyway or Liquibase so that they move with the code and can be rolled forward or back.

After cut-over comes a hypercare period with the engineers who did the migration on call, then an optional support retainer that applies Spring Boot and Java updates as they are released — so the next upgrade is a routine dependency bump rather than another project. When the services sit behind a Liferay portal, our Liferay upgrade and migration practice plans both upgrades together.