I am sure there are good reasons to rewrite software but I have seen so many projects attempt some major rewrite that ultimately fail to deliver on the promised value, take a lot longer than expected, and end up with a whole bunch of new problems that the old system didn't have.
[1]https://news.ycombinator.com/item?id=36642796#36646055
[2] https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/
Absolutely. There are many excellent reasons to rewrite software.
Having a -reason- to do it is not the issue. The issue is whether you can -afford- to do it.
It will cost money (lots of money), it'll cost time (make your best guess, multiply by 5), and it'll cost you your best developers (since you'll need a new team, and the old ones will see the writing on the wall) and by extension it'll cost you the experience your current team have earned over the years.
If you can afford all this, then you at least have a decision to make. If you can't -afford- it then the reasons for doing it are meaningless.
[I'm obviously talking about significant systems here, not a Notepad clone.]
Today it’s more common to refactor some component into a service out of a monolith. Then maybe some later time rewrite that. And so on.
Whereas when this was written a “rewrite” would be the equivalent of rewriting the entire monolith.
Nowadays when people say “rewrite” they mean something closer to what this post called a refactor. Still risky but not the same as completely throwing away what’s in prod and investing N years on some promised future that doesn’t manifest.