Замена legacy-систем

Изменения ждут месяцами, поддержка дорожает или систему знают единицы — соберём её заново, сохраним API и интеграции, перенесём данные со сверкой.

Какие проблемы решает замена legacy-систем

Систему развивают много лет, и каждое изменение даётся всё труднее? Ниже — ситуации, с которыми к нам обычно приходят. Если узнаёте свою, давайте оценим, пора ли её менять.

[ 01 ]

Простая правка месяцами ждёт очереди у смежных команд

Акция готова, но доработка корзины стоит в очереди у другой команды, и запуск откладывается.

[ 02 ]

Один заказ в разных сервисах называется по-разному

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

[ 03 ]

Систему понимают один-два разработчика

Если один из них уходит в отпуск или увольняется, развитие останавливается.

[ 04 ]

Поддержка дорожает быстрее, чем растёт польза

Бюджет уходит на инфраструктуру, а на новые функции остаётся всё меньше.

[ 05 ]

Новое подключение ломает старые интеграции

Каждый новый партнёр становится рискованным проектом.

[ 06 ]

AI-агентов в систему не встроить

Из-за неявных зависимостей агент не видит, что заденет его правка, и AI не ускоряет разработку.

Какие системы мы заменяем

Берёмся за клиентские и внутренние системы разного размера.

Клиентские продукты

Приложения, сайт, личный кабинет и их бэкенд.

Внутренние системы

Бэк-офис, CRM, OMS, WMS, MES, HR-контур и админки.

Тяжёлые компоненты

Camunda, самописные движки процессов и лишние микросервисы.

1С, SAP и другие ERP остаются на месте

Строим системы над ERP и интегрируемся с ними.

Что остаётся и что меняется после замены

Снаружи система работает как раньше, а внутри её снова легко менять.

Остаётся

Всё, на что опираются процессы и продажи.

  • API и интеграции со смежными системами
  • Данные и их история
  • Привычные сценарии для сотрудников и клиентов
  • Код и права на него у вас

Меняется

То, что мешало развитию.

  • Архитектура и модель данных
  • Меньше кода, и AI-агентам проще с ним работать
  • Скорость изменений
  • Кто развивает: любая команда на Python, онбординг за один день

Кейсы: как мы пересобирали работающие продукты

Оба продукта продолжали работать, пока мы собирали им замену. Ниже по шагам: что было, что сделали и чем всё закончилось.

[ 01 ]

С коробочного ДБО на свои приложения за 12 месяцев

Банк из TOP-20 (NDA)

  • Задача: банк работал на коробочном ДБО, и каждый релиз занимал месяцы.
  • Что сделали: убрали устаревшие API и хаотичные интеграции, сохранили функции старого ДБО и собрали новые приложения.
  • Как перевели пользователей: клиентов перевели, пока банк продолжал работать.
  • Результат: за первый год активная база клиентов выросла в 15 раз.
Как банк перешёл на свои приложения
[ 02 ]

Новое приложение для миллионов пользователей за 10 месяцев

Бургер Кинг

  • Задача: бизнесу понадобилась платформа для быстрого запуска функций и A/B-тестов.
  • Что сделали: после месяца аудита собрали приложение для iOS и Android заново, из модулей: правка в одном не ломает другие.
  • Как перевели пользователей: первая версия вышла для 5% пользователей точно в срок.
  • Результат: отмен заказов меньше 1%, конверсия в оформление заказа выросла на 1,8 п.п.
Как мы пересобрали приложение Бургер Кинга

Что мы уже заменили

Ещё пять проектов разного масштаба: от сайта до OMS.

[ 01 ]

Росбанк: приложение поверх бэкенда начала нулевых

Новое приложение связали со старым бэкендом через прослойку. Клиенты не регистрировались заново.

Как мы сделали приложение для Росбанка
[ 02 ]

Бэкенд и админка CoffeeBoom

API, эквайринг, лояльность и r_keeper работают как раньше, внутри около 50 таблиц вместо 75.

[ 03 ]

Бэкенд сети ресторанов на Ruby on Rails

API и интеграции сохранили один в один, внутри заменили архитектуру и структуры данных.

[ 04 ]

Бэкенд и админка surf.ru за рабочий день

Сайт на 500+ страниц перевели со Strapi на наш фреймворк.

[ 05 ]

OMS примерно на 1 млн строк кода

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

Как новая система повторяет старую

Внутри новая система устроена иначе, поэтому совпадение со старой проверяем по трём направлениям:

Данные

Заказы, бонусы и другие данные переносим по карте, один раз, при переключении.

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

API и интеграции

Повторяем все связи, чтобы приложения и партнёры не заметили замены.

  • Повторяем API по его описанию генератором кода, без AI
  • Сохраняем очереди сообщений, вебхуки и фоновые задачи
  • Ответы совпадают с прежними там, где этого ждут партнёры
  • Старые приложения работают через прослойку с прежним API

Интерфейсы и проверка

Интерфейсы сохраняем или обновляем, а систему проверяем теми же тестами, что и старую.

  • Сохраняем привычную логику экранов для сотрудников
  • Клиентский интерфейс оставляем прежним или обновляем дизайн
  • Для каждого сценария задаём критерии приёмки
  • Проверяем сквозные сценарии с настоящими системами

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

Почему замена идёт быстро

Новую систему делаем проще старой. Чем меньше кода нужно написать и проверить, тем раньше запуск.

[ 01 ]

Одна модель данных вместо нескольких систем

Сводим лишние сервисы и базы в одну систему: в простом случае это одно приложение, которое можно разделить на сервисы. Где микросервисы оправданы бизнесом и нагрузкой, оставляем их.

[ 02 ]

Тяжёлые компоненты заменяем простыми

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

[ 03 ]

Типовой код берёт на себя фреймворк

Админка, роли и доступы готовы, AI-агент пишет только бизнес-логику.

[ 04 ]

Архитектуру контролируют линтер и инженеры

Каждое изменение агента проверяет линтер, в нём больше ста правил. Ревью и приёмку ведут инженеры.

Иногда систему не нужно менять целиком

Если код хороший или хватит небольших изменений, так и скажем и переписывать не предложим. Оценка приводит к одному из трёх выводов:

  • Систему можно развивать дальше, для этого есть диагностика и развитие продукта.
  • Отдельные тяжёлые части разумнее заменить на лёгкие.
  • Систему выгоднее заменить целиком.

Начать можно с оценки системы или с аудита кода и архитектуры.

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

Замена проходит в четыре этапа, у каждого есть результат:

[ 01 ]

Оценка за наш счёт

В договоре фиксируем, что сохраняем один в один, и критерии приёмки.

Результат Срок и фиксированная цена в договоре
[ 02 ]

Модель данных и карта переноса

По каждому виду данных решаем, что переносим и в каком виде.

Результат Карта переноса данных
[ 03 ]

Сборка и проверка совпадения

Каждый сценарий принимаем по критериям из договора.

Результат Автотесты API и сквозных сценариев
[ 04 ]

Переключение пользователей

Пользователей переводим, когда сошлась сверка данных.

Результат Работающая система
[ 01 ]

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

  • Собственный код на распространённом стеке
  • Исключительные права на код, документацию и репозиторий
  • Исходники фреймворка на неисключительных правах
  • Гарантия полгода после запуска

Дальше систему можно развивать без нас.

[ 02 ]

Что понадобится от вас

  • Встречи с сотрудниками, которые покажут процессы
  • Исходный код под NDA
  • Доступы к смежным системам
  • Тестовые стенды или аккаунты
  • Обратная связь по дизайну

NDA подписываем до того, как получим код.

Развиваем ваши продукты более 15 лет

Проводили технические аудиты существующих систем. В 2024 году стали первыми в Рейтинге Рунета в категории «Мобильное приложение „под ключ“».

Дизайн, продукт и разработка в одной команде. Выводы диагностики подтверждаем фактами. AI в производстве помогает делать изменения быстрее.

С 2011 года

Работаем на рынке разработки

80%

Клиентов работают с нами больше трёх лет

250+

Проектов за время работы

[ FAQ ]

Что спрашивают перед заменой legacy-системы

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

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

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

1С, SAP и другие ERP оставляем на месте: в них десятилетиями копилась специфика бизнеса. Строим системы над ними и подключаемся через API поверх 1С и SAP. 1С-Битрикс и imshop заменяем: переезд магазина с 1С-Битрикс, переход с imshop.

Да. Старой системы здесь нет, поэтому речь об автоматизации внутренних процессов с нуля. Начинаем со встреч с сотрудниками, чтобы понять, как устроены процессы.

Нет, если приложения сохраняем: прослойка повторяет старый API и авторизацию. Потом их стоит перевести на новый API — это задача мобильной разработки и веб-разработки.

Цену и срок фиксируем в договоре после оценки. Проекты — от 10 млн ₽, иногда меньше. Как правило, замена занимает 1–3 месяца. Подробнее в статье о фиксированной цене и T&M.

Инженеры Surf: за ними архитектура, безопасность, ревью и приёмка. Агент пишет бизнес-логику внутри нашего фреймворка, его изменения проверяют линтер и автотесты. Подробнее о нашем подходе к AI.

Исключительные права на код, документацию и репозиторий — у вас. Фреймворк передаём с исходниками на неисключительных правах, форк разрешён. Полгода действует гарантия. Дальше систему может развивать любая команда на Python. Если нужно, возьмём развитие и поддержку на себя по отдельному договору, обычно тоже по фиксированной цене.

Python, FastAPI, PostgreSQL, React и shadcn, Flutter. API по OpenAPI повторяем кодогенерацией без AI, а Kafka, цепочки HTTP-запросов и вебхуков и задачи cron — целиком. Если фронтенд сохраняем, BFF побайтно повторяет API и авторизацию.

Переносим из PostgreSQL, MySQL, MS SQL, Oracle, SQLite и MongoDB, сверяем row_count, key_completeness и value_exact. Паритет подтверждают API- и e2e-тесты в духе Playwright.

[ обратная связь ]

Расскажите о проекте и мы предложим подходящие решения

напишите нам в Telegram
добавить файл

Отправляя запрос, вы соглашаетесь с политикой конфиденциальности и даёте согласие на обработку персональных данных