I just got done doing exactly that with my old SaaS I built / worked on for a decade.

Went through a roughly 3 year rewrite process while utilizing maintenance mode on the framework I had originally decided on back in 2014 and which sadly had an "upgrade path" of "you look like you could really use a full rewrite for your entire frontend" to get on the very next major version in like 2016. I'd say the main "use" for utilizing their maintenance support, was the fact that they would still fix issues with browser incompatibility, security issues, etc.

Like the fact that back in the day Chrome changed background tabs to no-longer respond to push notifications unless they are the active tab (after some delay)...it broke things in our app. But luckily we able to lean on the vendor for those types of issues, because there was very little my team could do to make a rewrite of a massive webapp any faster than it was already going.

Glad it's done, and I am out.

I've been doing this a while now, and as far as I can tell, there's always a way to run two frameworks side by side and migrate. And existing users get new stuff right away.

I've done it backend, I've done it frontend. With web apps it's always possible, it's the fundamental nature of the web and browsers.

Frontend is trivial because of how browsers work, every page could run a different framework if you were that mad.

Backend I've had two frameworks on one server for multiple migration projects. There's usually a way unless you're switching language.

But worst case scenario, say you wanted to change everything, I'd stick a load balancer in front. Route according to the end point requested. Then gradually migrate end points. You might need some craziness around authentication, but that's the sort of issue that is solvable with a week's work by a single, good, developer.

What was so complicated that stopped you doing that? Genuinely interested.