Заменяем legacy за 1–3 месяца

Как понять, что систему пора заменить

Обычно бизнес приходит к нам не с «плохим кодом», а с ощущением, что IT перестал успевать за бизнесом. Симптомы почти всегда одни и те же:

• Любая правка в приложении требует доработок в двух-трёх смежных системах.
• Интеграции с лояльностью, платежами и доставкой держатся на точечных доработках — каждое новое подключение ломает существующие.
• Документация фрагментарна и держится на экспертизе одного-двух разработчиков; их отсутствие останавливает работу.
• Каждый крупный релиз готовится неделями и требует отдельного окна согласований.
• Стоимость поддержки растёт быстрее, чем ценность, которую система приносит бизнесу.
• Встроить AI-агентов в такой продукт невозможно: слишком много неявных зависимостей, дублирования и исторических соглашений.
• Time-to-market больше не соответствует скорости изменений на рынке.

Что именно мы заменяем

Пользователи не заметят пересборки

Замена legacy для клиента и внешних систем должна выглядеть как «ничего не произошло». Приложение продолжает работать по тем же API, интеграции ходят по тем же контрактам, клиенты не обновляют приложение, партнёры не переписывают коннекторы.

• API like-for-like. Воспроизводим критичные mobile и web API один в один. Где есть OpenAPI — кодогенерацией. Где нет — покрываем сотнями API-тестов, сверяющих поведение старой и новой системы.
• Интеграции — до байта, где этого требует контракт. Лояльность, платёжки, доставка, склад — внешние системы не должны заметить, что legacy заменён.
• Данные — с доказательством. Сверяем row_count, key_completeness и value_exact по каждой сущности. Приводим к канонической форме (рубли ↔ копейки, timezone, кодировки), где старые системы жили в разных.
• Клиентский опыт. Те же сценарии, те же экраны, тот же tone of voice. Пересборка не должна учить пользователя новому.

Что вы получаете

Как мы переносим данные

Миграция — самое опасное место в замене legacy. Здесь ломаются проекты, теряется история, останавливаются продажи. Мы относимся к миграции как к отдельной инженерной дисциплине, а не как к «допишем ETL за неделю до релиза».

Manifest миграции. До первой строки кода описываем все источники (Postgres / MySQL / MSSQL / Oracle / SQLite / Mongo) и все решения по каждой сущности:

• direct — переносим один в один;
• renamed / merged / split — переносим со структурными правками;
• aggregate — сворачиваем в аналитические агрегаты;
• folded_into_jsonb — уходит в поле JSON;
• derived — вычисляется из других данных;
• omitted / deferred — осознанно не переносим сейчас;
• verified — требует отдельной сверки.

Каждое решение зафиксировано и обосновано — на приёмке нечему быть сюрпризом.

Reconcile-проверки. После запуска ETL автоматически проверяем:

• row_count — совпадение количества строк по каждой сущности;
• key_completeness — все ключи из старой системы нашли своё место в новой;
• value_exact — критичные значения совпадают до последнего разряда.

Canonical coercion. Приводим значения к единой канонической форме: рубли и копейки, timezone, кодировки, форматы дат — там, где старые системы жили в разных.

Один запуск. ETL — не долгий процесс, синхронизирующий системы месяцами. Мы запускаем его один раз, когда переключаем контур. До этого новая система заполняется тестовыми снапшотами и прогонами.

Как проходит замена

Наши флагманские проекты

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