Миграция легаси-системы: как обновить и ничего не сломать

Предприятия тратят от 60 до 80% ИТ-бюджета на поддержку уже работающих систем, оставляя на инновации лишь 20–40%, — по отраслевым данным. При этом исследования модернизации показывают: 68–79% проектов замены устаревших систем проваливаются или не достигают целей, а более половины программ трансформации выходят за бюджет. И это неудивительно: по оценкам аналитиков, около 70% компаний из Fortune 500 до сих пор эксплуатируют ПО старше 20 лет, и именно поддержка этого легаси поглощает до 80% ИТ-бюджета. Получается замкнутый круг: оставить всё как есть — дорого, переписать всё сразу — рискованно. Эта статья — о том, как мигрировать легаси-систему безопасно, поэтапно и без катастрофических простоев.

Содержание

Что такое легаси-система и почему её страшно трогать

Легаси-система (legacy system) — это не обязательно что-то очень старое. Это любая система, которая продолжает работать и приносить бизнесу деньги, но становится всё дороже поддерживать, развивать и масштабировать. Монолит на COBOL, написанный в 1980-х, — классический пример. Но легаси бывает и десятилетним Rails-приложением без тестов, и PHP-монолитом с нулевой документацией.

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

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

Когда действительно пора мигрировать: сигналы

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

• Неподдерживаемый или уязвимый стек. Поставщик прекратил выпуск патчей безопасности, версия языка или фреймворка достигла end-of-life.
• Дорогая поддержка и дефицит специалистов. Найти разработчика на COBOL или старый Delphi всё труднее и дороже с каждым годом.
• Нельзя добавить фичи или интеграции. Архитектура монолита физически не пускает новый функционал — любое изменение требует переписывать половину кодовой базы.
• Не выдерживает нагрузку. Система захлёбывается при росте трафика, и масштабировать её горизонтально невозможно из-за архитектурных ограничений.
• Vendor lock-in. Система намертво привязана к одному вендору, который поднимает цены или закрывает продукт.
• Риски комплаенса. Устаревшая система не соответствует требованиям регуляторов: 152-ФЗ, GDPR, отраслевые стандарты — и это создаёт юридические риски.

Если в вашей системе отмечается три и более пункта — миграция перестала быть вопросом «когда-нибудь» и стала вопросом «как именно».

Стратегии миграции: от «большого взрыва» до постепенной замены

Big Bang (полная замена за один cutover)

Самая очевидная стратегия: разработать новую систему параллельно, а затем в назначенный момент выключить старую и включить новую. На практике это называют «cutover» или переключением в «час X».

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

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

Strangler Fig — постепенное «удушение» монолита

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

Ключевое преимущество: в любой момент времени бизнес продолжает работать на работающем коде. Отдельные модули мигрируются независимо, и ошибка в одном не обрушивает всё остальное. Именно поэтому ранние результаты в первые 60–90 дней служат надёжным предиктором успеха всей программы — если первый модуль мигрирован и работает, команда понимает технику и набирает темп.

Модель 6R: как выбрать стратегию под задачу

Не все части легаси-системы нужно «переписывать». Модель 6R предлагает шесть стратегий — от самой дешёвой до самой дорогой:

Стратегия	Суть	Когда применять	Риск	Относительная стоимость
Rehost (lift-and-shift)	Перенести систему «как есть» в облако или новую инфраструктуру	Нужно снизить инфраструктурные расходы быстро, без изменения кода	Низкий	Низкая
Replatform	Небольшие изменения под новую платформу без переписывания ядра	Переход на управляемую БД или контейнеры при минимальных правках кода	Низкий–средний	Средняя
Refactor	Улучшение структуры кода без изменения поведения	Монолит работоспособен, но задыхается от технического долга	Средний	Средняя
Rearchitect	Существенное изменение архитектуры (например, монолит → микросервисы)	Нужна масштабируемость, которую текущая архитектура не даёт	Высокий	Высокая
Rebuild	Полная перепись с нуля при сохранении бизнес-логики	Код невозможно поддерживать, документация не существует	Очень высокий	Очень высокая
Replace	Заменить самописную систему готовым решением (SaaS, ERP и т.п.)	Задача стандартная, кастомизация не нужна	Средний	Зависит от лицензии

На практике проекты редко используют одну стратегию для всей системы: разные модули могут мигрировать по разным 6R-стратегиям в зависимости от их сложности и ценности для бизнеса.

Пошаговый план миграции без простоя

Шаг 1. Аудит и инвентаризация

Прежде чем что-то менять — нужно понять, что именно у вас есть. Инвентаризация включает:

• Карту всех компонентов системы и их зависимостей (граф сервисов, таблицы БД, внешние интеграции).
• Анализ бизнес-логики: что из неё задокументировано, что живёт только в головах команды.
• Точки интеграции с внешними системами: API, очереди сообщений, файловые обмены.
• Объём и структуру данных: насколько сложна будет миграция БД, есть ли устаревшие или дублирующиеся данные.

Результат аудита — «карта местности», без которой планировать маршрут невозможно. Если документация отсутствует (что типично для настоящего легаси), начните с реверс-инжиниринга: изучайте код, логи и схему БД как первичные источники.

Шаг 2. Тесты как страховка

Не начинайте менять код системы без тестовой сетки. Для легаси, где тестов нет, первый шаг — написать характеризационные тесты (characterization tests): они не проверяют, что система делает правильно, а фиксируют, что она делает сейчас. Это страховка от случайного изменения поведения в процессе миграции.

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

Шаг 3. Данные и обратная совместимость

Миграция данных — самый технически сложный и рискованный этап. Несколько ключевых принципов:

• Двойная запись (dual-write). Пока оба сервиса работают параллельно, каждая запись идёт одновременно в старую и новую базу. Это позволяет сравнить состояние и убедиться в согласованности.
• ETL-конвейер и сверка данных. Для первоначального переноса исторических данных используйте ETL с обязательной сверкой контрольных сумм и критических показателей на выходе.
• Антикоррупционный слой (anti-corruption layer). Между старой и новой системой вводится API-прослойка или фасад, который переводит модели данных и контракты. Это позволяет мигрировать части системы независимо, не ломая интеграции.
• Обратная совместимость. API новых сервисов должны поддерживать контракты, которые ожидают клиенты старой системы — на переходный период.

Шаг 4. Постепенный выкат

Когда новый модуль готов и протестирован, переключайте трафик постепенно — не всё сразу:

• Feature flags (фиче-флаги). Новый код деплоится, но включается только для части пользователей (или по условию). Отключить флаг — мгновенный откат без передеплоя.
• Canary-релиз. Небольшой процент трафика (1–5%) направляется на новый сервис. Мониторите метрики и ошибки. Если всё хорошо — постепенно увеличиваете долю.
• Blue-green деплой. Поддерживаются две идентичных среды — «синяя» (текущая) и «зелёная» (новая). Переключение трафика — мгновенное; откат — тоже мгновенный.

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

Как ничего не сломать: чек-лист рисков и отката

1. Для каждого этапа миграции — явный план отката (rollback plan). Что именно делаем, если на этапе Х пошло не так? Этот план пишется до начала этапа, не в момент аварии.
2. Резервные копии и точки восстановления. Перед любым изменением схемы БД или переключением трафика — свежий бэкап. Проверьте, что из него можно реально восстановиться (тест восстановления — не опция).
3. Мониторинг и алерты на весь переходный период. Метрики ошибок, задержки, деградация производительности должны быть видны в реальном времени. Алерт должен сработать раньше, чем позвонит клиент.
4. Заморозка несрочных фич на время миграции. Параллельные изменения в мигрируемом модуле увеличивают риск и сложность. Согласуйте с продуктовой командой «окно заморозки».
5. Коммуникация со стейкхолдерами. Все заинтересованные стороны — бизнес, поддержка, клиенты — должны знать о плановых окнах обслуживания и возможных временных ограничениях.
6. Критерий «go/no-go» перед переключением. Формализуйте: при каких показателях тестов и нагрузки команда разрешает переключение трафика, а при каких — откатывается. Не принимайте это решение интуитивно под давлением дедлайна.

Типичные ошибки при миграции легаси

Большинство проваленных миграций объясняются одними и теми же просчётами:

• Переписать всё с нуля без тестов. Новая система без характеризационных тестов воспроизводит не только полезную бизнес-логику, но и ошибки легаси — только теперь в другом месте.
• Мигрировать без документации. Если не разобрались в старой системе перед началом, новая унаследует скрытые требования в случайных местах.
• Недооценить данные. Команды часто планируют миграцию кода, но забывают про объём, качество и историю данных. ETL-конвейер для 500 ГБ с «грязными» данными — отдельный проект.
• Отсутствие плана отката. «Если что-то пойдёт не так — разберёмся» — рецепт катастрофы. Без чёткого rollback-плана команда в панике принимает хаотичные решения.
• Миграция «в один заход» под пиковую нагрузку. Cutover в пятницу вечером или в разгар сезонного спроса — классическая ошибка.
• Потеря знаний уходящей команды. Если разработчик, знающий легаси, уходит до завершения миграции — вместе с ним уходят неявные знания, которые нигде не записаны. Сессии knowledge transfer и парное программирование — обязательны.

Если вам нужна независимая экспертиза перед стартом или в процессе — наша команда проводит рефакторинг легаси-кода с предварительным техническим аудитом и составлением дорожной карты миграции.

Сколько стоит и сколько длится миграция

Честный ответ — «зависит», но конкретно от чего, давайте разберём:

• Размер и сложность системы. Монолит на 100 тысяч строк кода с тремя внешними интеграциями — это одна история. Распределённая система на 2 миллиона строк с 30 интеграциями — совершенно другая.
• Качество исходного кода и данных. Хорошо структурированный код с хотя бы частичной документацией мигрируется в разы быстрее, чем «живой» legacy-хаос без единого теста.
• Выбранная стратегия. Rehost занимает недели. Rearchitect монолита в микросервисы — месяцы или годы.

Поэтапная миграция по паттерну Strangler Fig обходится дороже в пересчёте на час работы команды, чем гипотетически идеальный Big Bang. Но это цена безопасности: бизнес работает непрерывно, первые результаты видны за 60–90 дней, а каждый этап можно остановить или скорректировать без потери всего прогресса.

Хотите понять порядок цифр для вашей задачи? Мы оцениваем проекты поддержки и модернизации ПО бесплатно на первичной консультации — с разбором текущей архитектуры и рекомендацией по стратегии.

Частые вопросы (FAQ)

Что считается легаси-системой?

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

Что безопаснее — переписать с нуля или мигрировать поэтапно?

Поэтапная миграция по паттерну Strangler Fig статистически надёжнее. Полная перепись «с нуля» требует воссоздать все неявные требования, накопленные годами, — и без рабочего прототипа рядом это крайне сложно. Большинство провальных проектов модернизации используют именно подход «написать всё заново».

Как избежать простоя во время миграции?

Используйте feature flags для постепенного включения нового кода, canary-релизы для малой доли трафика, blue-green деплой для мгновенного переключения и откат в один клик. На уровне данных — двойная запись (dual-write): пока оба сервиса работают параллельно, каждая транзакция пишется в обе базы, что исключает рассинхронизацию.

Что делать, если исходной документации нет?

Начните с реверс-инжиниринга: анализ кода, схемы БД, API-контрактов и логов в продакшене даёт полную картину. Параллельно пишите характеризационные тесты — они фиксируют текущее поведение системы и становятся «живой документацией», которая проверяется автоматически.

Сколько времени занимает миграция легаси?

Небольшая система с хорошей документацией мигрируется за 2–4 месяца. Крупный корпоративный монолит — от полугода до нескольких лет при поэтапном подходе. Хорошая новость: при Strangler Fig первые ощутимые результаты появляются уже через 60–90 дней — команда видит прогресс, а бизнес получает первые улучшения.

Как понять, что миграция прошла успешно?

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