В большинстве компаний работает хотя бы одна система, построенная более десятилетия назад. Эти системы обычно ещё выполняют свою работу — но замедляют найм (никто не хочет учить COBOL), отрезают вас от современных интеграций и превращают мелкие изменения в трёхмесячные проекты. Модернизация легаси — это дисциплина переноса таких систем вперёд так, чтобы сохранить то, что работает, заменить то, что мешает, и сохранить бизнес работающим каждый день перехода. Ниже — как мы делаем это без рискованного переписывания и без многолетней заморозки продуктовой работы.
Модернизируйте по частям, а не одной большой переделкой
Классическая ошибка — полное переписывание: новая команда тратит 18 месяцев на пересборку старой системы в современном стеке, бизнес продолжает меняться, переписывание никогда не догоняет, и в итоге проект отменяют. Вместо этого мы используем шаблон strangler-fig: ставим старую систему за современный API-шлюз, строим новые функции как независимые микросервисы рядом и постепенно заменяем старые. Бизнес видит непрерывное улучшение с первой недели, а страшного дня переключения никогда не наступает.
Что мы модернизируем чаще всего
Типичные проекты модернизации включают: оборачивание древнего ERP или биллинга чистым REST/GraphQL API, чтобы современные фронтенды и ИИ-агенты могли с ним общаться; замена интеграций на плоских файлах или FTP конвейерами на событиях; миграция локальных баз данных в управляемый Postgres с репликацией без простоя; перестройка устаревших настольных приложений как progressive web apps, работающих в телефоне и браузере; внедрение нормального CI/CD, тестового покрытия и наблюдаемости в кодбазе, у которой их не было.
Как мы снижаем риски миграции
До того как трогать старую систему, мы поднимаем три вещи: полную read-реплику, чтобы тестировать на реальных данных, не касаясь продакшена; среду теневой записи, где новый код пишет одновременно в старую и новую систему и мы сравниваем вывод; и набор регрессионных тестов, фиксирующих текущее поведение со всеми его странностями. Только потом начинаем переключать трафик. Каждый релиз под флагами и обратим за минуты, а не дни.
Модернизация легаси — частые вопросы
- Переписать с нуля или модернизировать постепенно?
- Почти всегда: модернизировать постепенно. У полных переписываний больших легаси-систем плохая репутация — они длятся дольше, стоят больше и часто отменяются. Подход strangler-fig даёт то же конечное состояние с гораздо меньшим риском и с приходом ценности каждый спринт, а не в конце многолетнего проекта.
- Сможете ли вы держать нашу систему в работе во время модернизации?
- Да, в этом и весь смысл нашего подхода. Мы помещаем старую систему за шлюз, строим новые возможности рядом как независимые сервисы и постепенно перенаправляем трафик. Бизнес ни на секунду не отключается. В регулируемых отраслях мы также параллельно гоняем старую и новую системы с непрерывным сравнением.
- Что делать, если у старой системы нет документации?
- Это нормальный случай. Мы начинаем с обратной разработки: захватываем трафик, читаем схему БД и пишем характеризационные тесты, фиксирующие текущее поведение со всеми багами. Только после понимания существующего поведения пишем современную замену и оставляем характеризационные тесты работать с новой реализацией.
- Какой реалистичный срок модернизации?
- Небольшой ограниченный модуль обычно выходит за 6–10 недель. Полная модернизация ключевой бизнес-системы обычно занимает 6–18 месяцев в зависимости от объёма, но даёт ценность непрерывно с первого месяца, а не в конце.
Если вы взвешиваете большое переписывание против жизни со старой системой, почти всегда есть третий вариант, который стоит рассмотреть первым: оберните старое, постройте современные возможности вокруг и снимайте его кусками. Мы готовы провести бесплатный архитектурный обзор и честно сказать, кандидат ли ваша система на модернизацию или ей действительно нужно полное переписывание.