Red Flags Signaling That a Rebuild Will Fail
#5 has a converse - oftentimes, the only way to get a rebuild to <i>succeed</i> is to drop features, and it's a major red flag if management insists on 100% feature parity.<p>The way to distinguish this from the #5 situation in the article is to ask if you're dropping features <i>because they're hard</i> or <i>because nobody uses them</i>.  The former is a red flag; the latter is a green flag.  Before you embark on a rebuild, you should have solid data (ideally backed up by logs) about which features your users are using, which ones they care about, which ones are "nice to haves", which ones were very necessary to get to the stage you're at now but have lost their importance in the current business environment, and which ones were outright mistakes.  And you should be able to identify at least half a dozen features in the last 3 categories that you can commit to cutting.  Otherwise it's likely that the rewrite will contain all the complexity of the original system, but without the institutional knowledge built up on how to manage that complexity.