Remix.run Logo
analog31 6 days ago

One technique is to run the modernization project, but use maintenance of the legacy software to keep the business going. Such maintenance could be for keeping up with hardware changes, OS upgrades, new features, and so forth.

I've seen projects run in parallel like this for 10+ years.

Tostino 6 days ago | parent [-]

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.

mattmanser 6 days ago | parent [-]

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.

Tostino 6 days ago | parent [-]

That is actually part of the "extra support" we decided to pay for.

The application was originally written in Vaadin 7, Vaadin 8 had an absolute ton of breaking changes and we could not migrate in time, and then the breaking changes continued to compound as new releases happened and they migrated away from GWT, making a "big bang" rewrite not practical.

Their extended support included a tool called multi-platform runtime, which allowed the old application and new application to be run side-by-side and each section replaced one at a time. So that is essentially what we did. Still took 3+ years to do the rewrite.