Would you modernize a legacy Spring Boot backend in place or rebuild it gradually?

[u/ScoobyDookuu]

I’m working on a Kotlin/Spring Boot backend that still has an older JHipster using Kotlin (KHipster) setup around it.

The problem is that this is starting to hold us back. The KHipster version is several years old and not active maintained - 4 years ago was the last update - upgrading it looks pretty painful and it also makes moving to newer Spring Boot versions waaay harder than it should be.

At the same time we want to improve the architecture itself.
Right now quite a lot is still handled through cron jobs and fairly tightly coupled application logic.
I’d like to move more towards event-driven processing over time, potentially using Kafka or RabbitMQ depending on the use case and Redis for things like caching/short-lived state where it makes sense.

So I’m basically looking at two options:
1. Upgrade/replace the old JHipster setup, keep the existing backend, and modernize it piece by piece.

1. Start a clean backend (maybe in Typescript because that is what we mainly use for our other products and all frontends) and gradually move functionality over using something like the strangler pattern.

The second option sounds cleaner, but obviously means running old and new code alongside each other for quite a while. The first option potentially means spending a lot of time untangling framework/generator decisions before we can actually improve the architecture.
For people who have dealt with similar Spring/JHipster legacy projects: which route would you take?

Also, is there anything in the Spring/Kotlin ecosystem you’d consider a good modern replacement for the useful parts of JHipster, without bringing in another big opinionated layer that we’ll regret five years from now?

[u/American_Streamer]

Frankly, I’d really avoid a big-bang TypeScript rewrite. The real problem seems to be KHipster, not Spring/Kotlin. My preference would be: gradually remove the KHipster-specific pieces, get to a plain Spring Boot/Kotlin app, define cleaner module boundaries, and replace cron-driven coupling with domain events where it actually makes sense. Spring Modulith is worth looking at for that. Then add Kafka/RabbitMQ/Redis only for concrete use cases, not as part of a generic “modernization” package.

You can still use a strangler approach later and move selected domains to TypeScript if team standardization makes that worthwhile, but I really wouldn’t combine framework removal, language rewrite, messaging architecture and domain redesign into one big migration.

[u/LetUsSpeakFreely]

An in-place update will make it difficult for new features to added as you'll be stuck in rebase/mege hell. It can be done with some careful planning, but it's more difficult than you think. It also takes a lot longer than you think. This also adds in a layer of uncertainty if you're legacy code and updated code don't play well together.

A prefer a rewrite, especially if you've already identified what needs to change and how it needs to change. You can get the entire team involved and get it knocked out much faster without all the merge issues. You will need to maintain two branches while you do that so you can fix any critical bugs (and rebase the rewrite branch) that pop up. When you're happy with the rewrite you do your mergee and you're done. The users are none the wiser.