Большая подробная интересная статья про истории переписывания с нуля нескольких продуктов “Lessons from 6 software rewrite stories”: https://medium.com/@herbcaudill/lessons-from-6-software-rewrite-stories-635e4c8f7c22

Есть распространненное мнение, что подход “а давайте все к чертям перепишем с нуля и после этого ЗАЖИВЕМ” ошибочен и приводит к фейлам. В статье на разных примерах показывается когда это так и когда это (иногда) не так.

Переписывание всего к чертям с нуля проблемно по следующим причинам:

• Это очень сложно для успешного сформировавшегося продукта. Переписать с нуля с сохранением существующей функциональности это как правило сложнее, чем просто создать. Надо сохранить все особенности, обходные пути, баг-фиксы, которые появились за годы и про которые уже все забыли. Поэтому такие проекты очень долгие, вязкие, выматывающие.
• Пока переписываешь продукт, ты его не улучшаешь. После такого большого проекта ты оказываешься с потраченным временем и — почти — тем же самым продуктом. Пользователь видит, что ты долгое время его не развивал и в конце концов показал то же самое, если не хуже (новые баги, а часть вещей решили не переимлементировать для скорости).
• Убеждение, что если все переписать, то это волшебным способом решит все проблемы у продукта очень часто ошибочно.

При этом я видел и успешные кейсы. Например вот недавно мы в Эквиде завершили большой проект, переписали с нуля критически-важную часть продукта. Это заняло где-то 4 человеко-года. Для нас хорошо сработали две штуки:

• Разбили проект на части и релизили отдельно. Каждая часть занимала где-то 3-4 календарных месяца от начала работа до релиза. Это позволило иметь темп, видеть постоянный прогресс и не вязнуть.
• Мы не только поменяли технологию этой штуки, но и перепридумали дизайн с учетом опыта за прошедшие года. Так как дизайн там важен, то пользователи сразу видели ценность после выпуска каждой части проекта, не было “внутри все поменялось, а пользователь разницы не видит”.