“If we just rebuilt this in [new framework], everything would be better.” The team is excited. The proposal looks clean on a whiteboard. Six months, tops.

I’ve heard this pitch hundreds of times. Most rewrites take two to three times longer than estimated. When they finally ship, they often have the same fundamental problems. Because the problems weren’t in the technology. They were in the requirements, the process, or the team dynamics. A new framework doesn’t fix those.

Before you commit to a full rebuild, try something smaller. Pick the most painful page or workflow in your application. Rebuild just that one piece in the new stack. Deploy it alongside the old system. See if it’s actually better.

This takes two weeks, not six months. You learn something real.

Sometimes the new stack genuinely is better and now you have concrete evidence to justify the full rewrite. Sometimes you realize the old stack wasn’t the problem at all and you just saved yourself a year of wasted effort.

Rewrites are bets. Small bets are smarter than big ones.