Модернизация legacy-систем: стратегии, стоимость и безопасный план миграции

Модернизация legacy-систем — это обновление софта, который всё ещё обслуживает бизнес, но стал трудным в изменении, дорогим в содержании или рискованным. Это может быть приложение на PHP 5 без тестов, старая CRM с самописными плагинами, десктопная программа, работающая с общей базой данных, или монолит, в котором разбирается один человек. Цель — не новые технологии ради технологий, а система, которую бизнес снова может безопасно менять.

Мы принимаем на поддержку и модернизируем рабочие системы клиентов — от биллинговых платформ до мультиязычной e-commerce. Ниже — подход, который мы используем сами: маленькие обратимые шаги, каждый из которых окупается.

Признаки того, что пора модернизировать

Возраст сам по себе не причина. Десятилетняя система, которая стабильна, безопасна и недорога в изменениях, может оставаться как есть. Инвестиции оправдывают такие сигналы:

• Каждое изменение — долгое и страшное. Небольшая фича занимает недели, релизы выкатывают ночью, а после каждого деплоя ломается что-то несвязанное.
• Неподдерживаемая среда или фреймворк. PHP 7.x или старше, фреймворк без поддержки, старая версия базы данных или ОС без обновлений безопасности. Этот случай подробно разобран в нашем гайде по переходу на PHP 8.
• Зависимость от одного человека. Только один разработчик, часто внешний, знает, как работают деплой, cron-задачи и интеграции.
• Интеграции заблокированы. Нельзя подключить новый платёжный сервис, CRM или ИИ, потому что у системы нет нормального API.
• Расходы растут. Хостинг на избыточных серверах, дорогие лицензии, ручная работа в обход недостающих функций и повторяющиеся инциденты.
• Дыры в безопасности и комплаенсе. Пароли в открытом виде, устаревшие библиотеки с известными уязвимостями, нет журнала действий, данные хранятся не там, где должны.

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

Модель 6R: стратегии модернизации

6R — простой способ выбрать стратегию. Главное — выбирать её для каждого компонента отдельно, а не для всей системы сразу.

• Retain (оставить). Компонент не трогаем, только мониторим. Подходит для стабильных частей, которые редко меняются, например старого модуля отчётов.
• Rehost (перенести как есть). Переносим приложение на новую инфраструктуру без изменения кода, например со старого физического сервера в Docker на современном VPS или в облаке. Быстро и недорого: убирает риск железа, но не проблемы кода.
• Replatform (сменить платформу). Небольшие изменения, чтобы работать на лучшей платформе: поддерживаемая версия PHP, управляемая база данных, очередь вместо циклов в cron. Часто лучшее соотношение цены и результата.
• Refactor (рефакторинг). Улучшаем внутреннюю структуру без изменения поведения: добавляем тесты, выделяем сервисы, удаляем мёртвый код, постепенно вводим слой фреймворка.
• Rearchitect (перепроектировать). Меняем архитектуру части системы, например выносим биллинг в отдельный сервис с API или заменяем общую базу данных на события.
• Rebuild или replace (переписать или заменить). Пишем компонент заново или заменяем его SaaS-продуктом. Оправдано, когда бизнес-логика простая и понятная или готовый продукт её покрывает. Рискованно для сложной недокументированной логики.

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

Сначала аудит и карта рисков

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

• Инвентаризация. Серверы, домены, репозитории, cron-задачи, очереди, внешние сервисы, доступы и владелец каждого аккаунта.
• Карта архитектуры. Основные модули, базы данных, интеграции и потоки данных, включая недокументированные, найденные в коде и логах.
• Карта рисков. Каждый риск с вероятностью, влиянием на бизнес и способом исправления: нет бэкапов, нет тестов платёжной логики, секреты в репозитории, неподдерживаемая среда.
• Быстрые победы. Исправления на несколько дней, которые снимают самые большие риски: проверенные бэкапы, мониторинг, секреты вне кода, воспроизводимый деплой.
• Дорожная карта. Порядок шагов модернизации с оценками, зависимостями и тем, что каждый шаг даёт бизнесу.

Если вы принимаете систему от другого разработчика, совместите аудит с шагами из нашего гайда по передаче legacy-проекта на PHP: сначала доступы и бэкапы, потом изменения в коде.

Пошаговый план миграции

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

# nginx: new code serves /billing and /api/v2, everything else stays on the legacy app
location /billing/ { proxy_pass http://new_app; }
location /api/v2/  { proxy_pass http://new_app; }
location /         { proxy_pass http://legacy_app; }

1. Стабилизация. Бэкапы с проверенным восстановлением, мониторинг доступности и ошибок, централизованные логи, секреты вне кода. Пока этого нет, ничего другого не начинаем.
2. Воспроизводимость. Упаковываем приложение в Docker или другую повторяемую среду, поднимаем staging с обезличенными данными и деплой, который откатывается за минуты.
3. Страховочная сетка. Пишем характеризационные тесты для критичных сценариев: вход, оформление заказа, выставление счетов, отчёты, от которых зависят финансы. Они фиксируют, что система делает сегодня, включая баги.
4. Обновление платформы. Поддерживаемые версии языка и фреймворка, актуальные библиотеки, современная версия БД. Где можно — автоматические инструменты, а всё, что ловят тесты, исправляем.
5. Перенос болезненных частей. Выбираем модуль с самой высокой стоимостью изменений или самым большим риском, строим замену, направляем на неё часть трафика, сравниваем результаты и переключаем полностью.
6. Аккуратная миграция данных. Планируем изменения схемы так, чтобы старый и новый код работали одновременно, мигрируем порциями, сверяем количества и суммы и сохраняем путь отката, пока старый код не удалён.
7. Удаление старого кода. Выводим из эксплуатации всё, что больше не используется. Модернизация, которая ничего не удаляет, просто добавляет вторую систему на поддержку.

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

Стоимость, сроки и окупаемость

Цифры зависят от размера, качества кода и количества неизвестных, но эти диапазоны для небольшой опытной европейской команды полезны как ориентир:

• Архитектурный анализ или аудит: €200–3k, 1–2 недели. Письменный отчёт с рисками, приоритетами и дорожной картой.
• Стабилизация: €3k–15k, 2–6 недель. Бэкапы, мониторинг, Docker, воспроизводимый деплой, секреты, самые срочные исправления безопасности.
• Обновление платформы: €5k–40k, 1–3 месяца. Например, переход с PHP 5 или 7 на PHP 8 с обновлением фреймворка и тестами критичных сценариев.
• Поэтапная модернизация: €15k–150k, 3–12 месяцев. Перепроектирование ключевых модулей, новые API, миграция данных и вывод старых частей из эксплуатации.
• Полное переписывание: часто в 1,5–3 раза дороже первой оценки. Скрытые бизнес-правила, миграцию данных и параллельную поддержку старой системы обычно недооценивают.

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

Типичные ошибки

• Переписывание «большим взрывом». Старую систему замораживают на год, пока строят новую. Бизнес продолжает меняться, и новая система устаревает уже к запуску.
• Изменения без тестов. Без характеризационных тестов никто не знает, изменил ли рефакторинг поведение.
• Игнорирование данных. Код можно переписать за недели, а годы несогласованных данных чистить и мигрировать гораздо дольше.
• Решения от технологии. Микросервисы или новый фреймворк выбирают потому, что это модно, а не потому, что это решает измеренную проблему.
• Нет ответственного со стороны бизнеса. Кто-то должен расставлять приоритеты и подтверждать, что перенесённые функции работают как надо.

Чем мы можем помочь

Мы модернизируем рабочие PHP- и веб-системы по шагам: аудит, Docker и безопасный деплой, обновление PHP и фреймворков, новые API и интеграции — без остановки бизнеса. Хороший первый шаг — архитектурный анализ (€200): письменный разбор вашей системы с рисками, приоритетами и оценкой каждого шага модернизации. Если хотите сначала обсудить ситуацию, запишитесь на консультацию (€50/час). Смотрите также нашу услугу по интеграциям и кейс биллинга PebbleHost.