Hey, Victor, good article. I guess that if you do your rewrite with essentially the same knowledge and skill base with which you wrote the original you would be doomed. But is that necessary?
I think the questions should be "Can you continue to be competitive with what you have?" and "What will it cost for you to fix it if you don't?". Of course, you don't really know how to build better, the questions are mute.
My experience is mostly in commercial software vendors. So, my perspective is colored by that. I do know that the idea of a rewrite is terrifying and hard to sell in such companies---even when the boat is sinking. But I also know it can be done successfully, because I've done it.
If effective refactoring is built into your software development cycle, rewrites can be avoided. But few companies have the intellectual and technical discipline to do that. So ultimately, it becomes rewrite, replace, or die. Pay me now or pay me (more) later.
The first time I got a total rewrite approved (took 2 years to get approval and 1 year to get the new products out the door), we successfully rewrote 6 mainframe batch applications as 6 mainframe CICS applications. GE, our parent company measured a four-fold improvement in productivity using the new architecture and tools we implemented. We introduced an integrated data dictionary, source code management (then a new thing), a domain-specific 4GL, program templates, and an online screen painter to get the batch COBOL development staff into the new world of online applications.
