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

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

Унаследованная система стоит денег каждый месяц, пока остаётся в работе: латание, простои и функции, которые на ней не построить. Миграция заменяет систему, на которой работает бизнес, пока бизнес продолжает на ней работать.

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

1. Какова измеримая стоимость текущей системы?

«Она старая и медленная» — не обоснование для миграции такого масштаба. Боль нужно оцифровать:

• Сколько инженерных часов уходит на латание системы каждый месяц?
• Во что обошлись простои за последние 12 месяцев?
• Сколько запросов на новые функции заблокировано, потому что архитектура их не тянет?

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

2. Какова стратегия миграции данных и кто за неё отвечает?

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

• Вы делаете миграцию одним переходом за выходные или поэтапно?
• Кто отвечает за очистку и сопоставление данных?
• Что происходит с активными транзакциями в окне переноса?

Если стратегия данных — второстепенная задача, отданная младшему администратору базы, миграция встанет.

3. Можете ли вы работать на старой и новой системе параллельно?

Самый рискованный подход — выключить старую систему в пятницу и включить новую в понедельник. Предсказуемые миграции используют паттерн Strangler Fig: перед унаследованной системой ставится API-шлюз, новая система строится по частям, и трафик постепенно переключается на неё, пока старое приложение продолжает обслуживать остальное. Если ваша архитектура не позволяет работать обеим системам одновременно, вы принимаете на себя лишний риск.

4. Есть ли у вас проверенный план отката?

Исходите из того, что развёртывание провалится. Если вы перешли на новую систему, а наутро она легла под продакшен-нагрузкой, каков точный порядок возврата к старой?

План отката не бывает теоретическим. Он должен быть задокументирован, а время его выполнения — посчитано. Если откат требует вручную развернуть 50 000 транзакций, у вас не план отката, а сценарий катастрофы.

5. Кто ваши внутренние спонсоры и каковы их полномочия?

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

Если среднему менеджменту позволено не переходить или требовать бесконечных доработок, чтобы новая система работала в точности как старая, проект провалится. Нужен спонсор уровня совета директоров с полномочиями обеспечить переход и отказывать в разрастании функционала.

Что делать, если ответов нет

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