1. Для анализа кода можно прогнать его через различные инструменты аналитики и визуализации кода и архитектуры. После анализа можно исправить самые критичные ошибки, которые выявят инструменты.

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

3. Несмотря на это, взять разработчика из предыдущей команды, который находится на проекте на правах консультанта, это хорошая идея. Он может предупреждать о проблемах, когда вы будете придумывать решения, испытанные до вас и оказавшиеся неудачными по ряду причин, специфичных для проекта. Эти знания об истории развития проекта очень пригодятся.

4. Кроме числовых метрик, вам будут нужны люди, способные понять, что система становится лучше или хуже. Скорее всего, это будет кто-то из отделов техподдержки, аналитики, представители бизнеса или один из ключевых пользователей. Используйте любые возможности для закрепления текущего состояния системы, чтобы при каждом изменении делать сравнение.

5. Нужно собрать и занести в таблицу все технологии, фреймворки, ОС, СУБД и т. п., которые используются в системе. Посмотреть их версии, выделить те, которые уже не поддерживаются, и составить план по обновлению. Замена технологий – рискованные и длительные изменения, поэтому к ним нужно готовиться заранее.

6. Если в системе нет тестового сервера (staging, UAT), то желательно его развернуть в самом начале. Это может оказаться трудоёмкой задачей из-за сложности инфраструктуры проекта или больших объёмов данных, необходимых для работы системы.