Кейс-разбор: как обновлять legacy без остановки бизнеса

Исходная ситуация

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

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

• Карта бизнес-процессов и зависимостей
• Критичные интеграции и владельцы данных
• Сценарии, которые нельзя прерывать
• Точки контроля качества и отката

Цель миграции — не переписать всё заново, а вернуть компании способность безопасно менять продукт.

Как выбрали первый контур

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

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

Поэтапное переключение

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

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

• Параллельное чтение или теневой режим
• Наблюдение за ошибками и расхождениями
• Постепенное включение пользователей
• Проверенный откат и вывод старого модуля

Что получает бизнес

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

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