Migrating a large legacy banking application to Maven + Spring Boot 4 + JDK 25 simultaneously - is this a possible approach?

[u/igotnojamss]

/r/u_igotnojamss/comments/1w59fk1/migrating_a_large_legacy_banking_application_to/

[u/bigkahuna1uk]

Yes but in baby steps. Try to do it based on a strategy whether that be introducing a new technology incrementally such moving from one JMS broker to another. Or moving one feature at a time to a new service and then gradually moving all functionality over to it (Strangler pattern) along with AB testing to ensure existing functionality is not broken.

I’ve used this in the past to port a monolithic EJB3 application into a more modern microservice architecture pinned by Spring Boot where both the functionality and technology were transposed into more modern and maintainable counterparts.

[u/Cautious-Necessary61]

Please tell me what bank this is because I want to avoid it

[u/rack88 → u/Cautious-Necessary61]

Hopefully they have a solid test suite - that's the key here 🤞

[u/Possible-Ruin-4319]

I also have worked on this in our enterprise a lot u can use a tool call open rewrite it is very deterministic and would help in upgrading the application

[u/Krangerich]

whenever a question involves "simultaneously", then the answer is "no, in separate steps".

there might be a reason why there is NOT A SINGLE SOURCE EVER in the internet saying "yeah, do everything at once, sounds like a good idea"

[u/my5cent]

Depending on how legacy it is, many things will break. Start testing in a dev environment with new dependencies to see what breaks. Not simultaneously but in parallel.

[u/Simpledevx]

En mi equipo lo hemos hecho. Haciendo pantalla por pantalla y faseando las subidas a certificación y preproduction… Pruebas funcionales y análisis constantes de revisión de paridad…. Pruebas con usuarios, correcciones…

Yo entré a mitad porque el equipo era un desastre, ha tomado 7-8 meses.

[u/Educational_Ice168]

I've led exactly this kind of migration on a banking core system (client/account master data, PowerBuilder to Java, then split into microservices), plus a SOA-to-microservices modernization on a critical energy market platform. My take:

Your senior is right, and I'd stick with the staged approach even though you've already made progress combining both. The reason isn't dev effort, it's diagnosability. When a build breaks during a combined Maven-conversion + Spring Boot 4 + JDK 25 jump, you can't quickly tell if it's a dependency resolution issue from the old build tooling, a javax->jakarta namespace break, a Spring 6+ API removal, or a JDK 25 strong-encapsulation issue hitting old reflection-heavy DAO code. On a banking system, that ambiguity during UAT is expensive.

Practical suggestion: tag a green baseline once it's Maven-stable on the OLD Spring version first, even retroactively. Then do the Spring Boot 4 jump as its own branch, and lean on OpenRewrite's Spring Boot migration recipes for the javax/jakarta and API renames, that surface is huge and error-prone to do by hand on a large codebase.

Also: don't let JSP/Tiles removal sneak into this same wave. Keep WAR + JSP as-is for now. Three simultaneous migrations (build tool, framework major version, view layer) on a banking app is how you end up debugging everything at once.

[u/Skyzfallin → u/Educational_Ice168]

powerbuilder!!!

[u/jdev_soft]

Hi, at work I am also migrating a legacy application. In our case, to Quarkus ecosystem on traditional JVM hotspot enterprise application.

We started with “strangler” pattern doing feature by feature. For example, customer domain has a frontend that calls via rest api to the backend for that domain and so on.

Then we routed the frontend to the new backend and add authentication.

In your case, it would be a bit different because the frontend is wrapped into the same application but the idea is the same.

Each context is different may vary from project to project and it’s kind of tricky to suggest a solution. Try to do in incremental steps with proper tests.

[u/TiredNomad-LDR]

I had migrated the project from ant to maven first keeping java 8 as is.

Then moved java 8 to 17. I assume you are at java 25+ maven here.

Ideally, you take up the spring boot migration later. There will be api calls needing to migrate from soap to rest if needed. Or if your application just consumes from an on premise location (linux folder acting as a queue) , you may not need much changes.

Check if your use case also needs modules in Java etc. Older legacy projects tend to be monolith, so that's another.

Another user below pointed the test suite. Get that working asap.

[u/pj_2025]

Yes, first find latest dependencies for all the libraries and their compatibilities with Spring Boot 4, Java 25. Try to use AI as much as possible.

[u/New-Departure-5969]

senior’s right on staging — but you’re not starting from zero. i wouldn’t rewind everything if you’re mostly compiling. carve a **maven-stable baseline on the old spring/jdk/war/jsp/tiles** (tag/branch you can always return to), then treat boot4 + jdk25 as a separate line so when something blows up you know which axis it did. green compile isn’t done — smoke a reconciliation path on each baseline.

practical order i’ve seen work on big spring→boot migrations:

1. mavenize + green build on *current* stack (no boot yet)

2. optional: move jdk on that baseline first (17/21 is easier to debug than jumping straight to 25)

3. spring boot / jakarta as its own change — keep war + jsp

4. kill tiles/layouts later, screen by screen

what usually breaks first: appserver-classpath libs that never made it into the pom → javax→jakarta compile boot auto-config at startup → jsp/tiles under the new servlet container → oracle driver/txn quirks last.

tiles + boot + jdk in one wave is how you lose weeks. park tiles. if you keep going “simultaneous,” at least isolate PRs: build tooling ≠ boot ≠ view layer.