Унаследованные системы держат на себе расчёты с контрагентами, бухгалтерию, документооборот ведомств. Они работают годами, и именно поэтому их боятся трогать. Но платформы устаревают: вендор снимает СУБД с поддержки, серверы на Windows Server 2003 уходят в зону риска, разработчиков под Delphi или Visual FoxPro на рынке всё меньше. Откладывать миграцию – значит копить технический долг, который однажды придётся гасить в авральном режиме. Разберём, как переносить такие приложения без остановки бизнеса.

Сначала инвентаризация, потом стратегия

Прежде чем что-то переносить, опишите систему как она есть. Соберите перечень модулей, интеграций, форматов данных, регламентных задач и недокументированных обходных решений, которые администраторы держат в голове. В госсекторе добавьте требования ФЗ-152 о персональных данных и отраслевые регламенты – они диктуют, где данные могут физически храниться.

Дальше выбирайте стратегию под каждый компонент:

  • Rehosting («подъём как есть») – перенос на новую инфраструктуру без правки кода. Быстро, дёшево, но техдолг остаётся.
  • Replatforming – смена СУБД или сервера приложений с минимальными изменениями логики.
  • Рефакторинг – переписывание узлов, которые тормозят развитие.
  • Замена – отказ от собственной разработки в пользу готового решения, если оно закрывает 80% требований.

Не пытайтесь применить одну стратегию ко всей системе. Платёжный модуль переписывают, а архивный справочник достаточно перенести как есть.

Данные, безопасность и инфраструктура

Главный риск миграции – данные. За 15–20 лет в БД накапливаются дубли, осиротевшие записи, поля с «костылями». Перед переносом проведите профилирование и очистку, заведите карту соответствия старых и новых схем. Миграцию данных всегда прогоняйте на копии и сверяйте контрольные суммы до и после.

Решите вопрос размещения. Не обязательно переносить всё в один контур: чувствительные данные оставьте на собственных мощностях, а вычислительно тяжёлые задачи вынесите наружу. Как выстроить такое разделение, мы разбирали в материале о гибридной облачной стратегии. Если в новой архитектуре появляется аналитика на больших объёмах, под неё имеет смысл заложить отдельный слой – например, на базе продуктивного кластера Hadoop.

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

Переключение без простоя

Большой взрыв – переезд за одни выходные – допустим только для малых систем. Для критичных сервисов используйте параллельную работу: новая и старая система какое-то время крутятся одновременно, данные синхронизируются, а часть нагрузки переводится постепенно. Так вы откатитесь назад при сбое, не потеряв ни одной транзакции.

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

Вывод

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