Унаследованная система – это не просто старый код. Это бизнес-логика, которую десять лет накапливали бухгалтеры, диспетчеры и инспекторы, и которую никто полностью не помнит. Она работает на Delphi, Visual Basic 6 или клиент-серверной связке с Oracle, держит критичные процессы и каждый месяц требует всё больше денег на поддержку. Заменить её одним проектом «с нуля» – соблазнительно и почти всегда провально: переписывание затягивается на годы, а старая система продолжает жить параллельно и расходиться с новой. Разумная альтернатива – поэтапный переход, при котором система модернизируется по частям, оставаясь в работе.

Почему «большой взрыв» не работает

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

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

Strangler-паттерн и слой развязки

Базовый приём поэтапной миграции legacy-систем – «удушение» (strangler). Перед старой системой ставится фасад-маршрутизатор: он направляет запросы либо в legacy-код, либо в уже переписанный модуль. По мере готовности новых частей трафик постепенно перетекает на них, а старые куски отмирают. Система всё время остаётся целой, а команда движется небольшими управляемыми шагами.

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

Инфраструктура и соответствие требованиям

Переход – удобный момент пересмотреть инфраструктуру. Часть нагрузки переезжает в изолированное облачное окружение, где новые модули обкатываются без риска для рабочего контура; как это устроено технически, мы показывали на примере приватного облака Amazon VPC. Но облако ставит вопрос о данных. С января 2007 года действует закон №152-ФЗ «О персональных данных», и при любом переносе нужно понимать, где физически лежат ПДн и как они защищены, – мы писали об этом отдельно в разборе защиты персональных данных. Учитывайте требования заранее: перепроектировать защиту по факту запуска дороже и рискованнее.

Вывод

Модернизация унаследованной системы – это не одномоментная замена, а управляемая последовательность переносов. Начните с инвентаризации функционала и выделения доменов, поставьте фасад-маршрутизатор, развяжите данные и переносите модули по одному, контролируя каждый шаг на реальной нагрузке. Так бизнес и госсектор получают современную систему без простоев и без ставки «всё или ничего».