Один из моих кейсов выглядит так.

Заказчик планирует перейти с инфраструктуры Microsoft на отечественные решения. У него несколько подразделений, общие корпоративные системы и сотрудники, которые постоянно взаимодействуют друг с другом.

Переключить всех за выходные невозможно. Решают двигаться поэтапно: сначала пилотная группа, затем одно подразделение, потом остальные.

Целевую архитектуру проработали. Но между первым и последним этапами компания ещё какое-то время будет жить в двух инфраструктурах. И вот это состояние тоже нужно спроектировать.

Например, сотрудников первого подразделения уже перенесли в новую службу каталогов. Часть систем, которыми они пользуются, пока остаётся в старом домене. Коллеги из других подразделений продолжают работать по прежней схеме, а общие ресурсы нужны всем.

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

С каждым следующим этапом это сочетание меняется. То, что проверили для пилотной группы, не обязательно покрывает ситуацию после переноса целого подразделения.

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

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

К сожалению, мало кто из Заказчиков уделяет планированию должное внимание и как итог потенциальный срыв сроков и бессонных ночи.