I recently had a long meeting with a client that runs dozens of applications ranging from brand new Laravel apps to early 2000s PostNuke. They've had a rough couple of months security-wise, with several of their servers being taken over in seemingly unrelated attacks using a variety of exploits. We spent two weeks putting together a full inventory of their applications and coming up with a comprehensive plan to get everything in order. The purpose of the meeting was to recommended what to update, what to abandon, and what to (gasp) rebuild.
Years of conference talks, blog posts, and books have cemented in all of our heads that rewriting is always the wrong decision. It always takes longer than expected and almost always fails to launch. But that's not true anymore.
I recently did a rewrite of an app for this client. The original took over a year for three developers to build. Version two took about 6 months from running laravel new to launching to live customers, but I only worked on it for part of a day, once a week, for those six months. The original was still running and still had a handful of paying users, but as a pre-composer PHP app, it was difficult to update and rarely maintained. The feature set had fallen out of sync with what customers expect from this type of service, and modernizing those features on the existing stack would have cost way more than the app was worth. When the client mentioned the idea of reviving it last summer, I suggested that we throw AI at it and see how far it could take it. They agreed and it worked pretty well.
Two years ago, I'd never have suggested rebuidling this app. I'd have probably recommended that they simply retire it. The subscriptions were barely covering the cost of hosting. They were early movers in the market and the app was a good investment, but the space has since become very crowded with superior products. Assuming a rewrite would require the same investment as the original, the math just didn't work. This app isn't a core piece of their business, and simply walking away from it wouldn't have moved the needle at all. It would have been the right move.
I think it's time to retire the "never rewrite" dogma in favor of a more nuanced approach. In many cases, we keep applications running because we're used to them, but they aren't really solving our problems all that well anymore. We get frustrated with how hard they are to change and daydream about what it would feel like on a fresh, modern stack. Have an honest conversation about whether, if you'd never have built the original app, you'd build it for the first time today with the tools at your disposal. If so, then weigh up modernizing versus rewriting. If not, shut it down and figure out what would be a better use of your time and resources.
For the record, we only suggested one rebuild from the remaining inventory. We recommended a handful of retirements, but we mostly recommended good old-fashioned modernizing in place. It's still the right move in most cases. Partly because the same tooling that allows us to replace an old app for a tiny fraction of its original build cost can help us take an established app and knock the dust off. So next week, we're running a few training sessions on Rector for their development team.