Непрерывное устаревание

Здесь всё просто: нужно смотреть, что сейчас новое и правильное из технологий, и внедрять то, что было новым хотя бы пару лет назад. Ну или не внедрять, но осознанно — понимая, что дальше произойдёт с вашим кодом.

Частный случай устаревания — когда какой-то компонент перестаёт поддерживаться, и поддержку фактически оказывает команда разработки. Это даже веселее, чем просто работа на старой технологии.

Заканчивается это либо тем, что система умирает от старости и больше становится не нужна, либо рефакторингом, больше похожим на переписывание с нуля.

Симптомы

В проекте технологии, которые уже сняты с поддержки или вот-вот будут.
Вендор не отвечает, а «чинить» приходится своими силами.
Новые сотрудники не могут работать: документации нет, комьюнити нет.
Каждая плановая модернизация превращается в переписывание.

Пример

«Плохой» вариант: сервис на компоненте, который давно в EOL, с «заплатками» от команды:

# используется компонент xmllib (удалён из Python 3)
# команда поддерживает внутренний форк своими силами
from vendor_xmllib import parse   # внутренний форк

«Хороший» вариант: осознанный выбор поддерживаемого инструмента:

from xml.etree import ElementTree as ET   # встроенный, поддерживаемый

Как исправить

Завести реестр используемых технологий с датами окончания поддержки.
При выборе новой технологии смотреть не на «новизну», а на поддержку и перспективу.
Планировать миграции заранее, а не в момент, когда поддержка закончилась.
Если миграция неизбежна и выглядит как переписывание — сделать это осознанно, с характризационными тестами.