Let me tell you an anecdote: A big, old, crusty online retail company wants to bring their web shop up to par with the competitors. Due to many years of technic

Let me tell you an anecdote: A big, old, crusty online retail company wants to bring their web shop up to par with the competitors. Due to many years of technical debt, feature development speed has come to a halt and it is determined that the web shop must be rewritten to remain competitive. Over a period of months, requirements are gathered from user focus groups and all the employees who maintained the content on the previous shop. Development starts and 3 years later, still not having implemented all the requested features, the project is deemed a failure. Another 3 years later, a new consulting company is brought in to attempt to realize the project. But this time, instead of trying to replace the old shop, a completely new shop is built iteratively and independently. Domain experts in the company complain: there is no way to review products, they can no longer put text wherever they want in the shop and users have to call the hotline to unsubscribe from newsletter because there is no settings menu. Still, the new shop is already outperforming the old one, despite having far less features. It turns out that many of those features weren't needed after all. The lesson here is that writing a direct replacement system rarely succeeds because the new system will hardly be able to implement all the features in a reasonable time. Instead you should take a step back and develop a completely new system that follows actual user requirements and gets rid of all the dead code.