Технологии меняются ежедневно - стоит ли бизнесу пытаться поспевать?

Если честно, нет. Если только сам бизнес не диктует эту необходимость в изменениях.

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

Вместо того, чтобы тратить время на переход на новые технологии или на обновления и повторное тестирование после каждого минорного релиза 250 ваших зависимостей, это время можно было бы потратить на разработку и доставку новых функций для конечных пользователей. По правде говоря, никому нет дела до того, что у вас последняя версия Angular, если у вас нет функций, которые есть у конкурентов.

Хорошо, скажете вы, но что будет через 3 года, когда обновиться придётся, а вы отстанете на 10 мажорных версий и будете утопать в “легаси”-коде?

Во-первых, гордитесь тем, чего достигли. Тот факт, что вы правильно расставили приоритеты по ресурсам, означает, что теперь именно бизнес диктует изменения и требует апгрейда. Без такой расстановки приоритетов ваш бизнес мог бы вообще не взлететь, и вы бы по-прежнему работали вслепую, перескакивая с одной версии Angular на другую, при том что вашим софтом никто не пользуется.

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

Если работает - не трогай

Каждое изменение, которое вы вносите, добавляет риск, поэтому после каждого обновления придётся заново тестировать ваш софт. Можно, конечно, выпустить и наблюдать, где загорится; до определённой степени это тоже работает и сильно зависит от ситуации. Это допустимо для собственного продукта - если что-то случится и вы потеряете деньги, это ваша вина и ваши деньги. Но что произойдёт, если вы внесёте такое изменение для клиента, считая, что делаете доброе дело, при том что клиент об этом не просил, а вы не удосужились его предупредить, и в результате внесёте баг, из-за которого клиент потеряет деньги? Вот именно. Вы рискнули ради того, что клиент не может оценить, и оно взорвалось у вас в руках.

Обоснование изменений

Изменения можно оправдать. Просто убедитесь, что не врёте сами себе (или своему клиенту, если работаете на кого-то) ради новой игрушки. Игрушки приходят и уходят: ломаются, выбрасываются, потом покупаются новые. Думайте в терминах инструментов, продуктивности, производительности, безопасности. “Снизим риск” - слишком обтекаемо. Подкрепите такое решение реальными аргументами и цифрами.