Модернизация legacy-систем

Берём legacy-проекты, от которых отказывается 90% подрядчиков: монолиты на устаревших стеках, БД без миграций, бизнес-логика в хранимых процедурах, отсутствующая документация. Наша специализация — миграция без потери данных и без downtime.

Под услугой ниже есть калькулятор для предварительной оценки бюджета и срока.

Что входит

Аудит legacy-кода с картой компонентов, оценкой трудоёмкости и приоритизацией модулей по бизнес-критичности.
Воспроизводимый миграционный pipeline (extract → transform → insert → verify) на изолированном окружении. У нас 211 SQL миграций в production.
Insert-only versioning через valid_from — единая модель для всех бизнес-сущностей. Старые версии неприкосновенны.
Public_id backfill — миграция с bigint URL на короткие 7-символьные varchar(7) UNIQUE без downtime, через триггеры BEFORE INSERT.
Drift-fix процедуры — еженедельная сверка legacy ↔ новая БД с автоматическим выравниванием. 312k платёжных записей скорректированы за один сеанс.
Bridge через mTLS + HMAC + Idempotency для постепенной миграции — новый фронт работает поверх остаточной legacy-системы.

Когда нужно

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

Как мы работаем

Аудит (2-3 недели). Карта компонентов, схема БД с цифрами, перечень внешних интеграций, риск-карта.
Миграционный pipeline на staging (1-1.5 месяца). Воспроизводимый ETL + верификация. Параллельно: новая БД, новый фронт под выбранный модуль.
Поэтапный rollout. Один модуль → smoke → следующий. Старая система продолжает работать.
Bridge и постепенный вывод legacy. Через mTLS+HMAC новый фронт ходит в legacy за остатками. Постепенно legacy усыхает до нуля.

Технологии

SvelteKit 2 / Svelte 5 (новый фронт), Supabase PG 17 (новая БД), Hatchet (workflows), Gotenberg (PDF), shared-pay (платежи), insert-only valid_from versioning, public_id backfill, mTLS + HMAC bridge. Legacy-стек: PHP 5.4-8.x, MariaDB, MODX, classic jQuery — не пугаемся.

Подробности — в кейсах Круизный флот и Прогулочный флот.

Опишите задачу — обсудим как закрыть её целиком.

Часто задаваемые вопросы

Берёте ли вы проекты на PHP 5/Perl/COBOL?

Да. Наш текущий миграционный pipeline вырос из перевода PHP 5.4 + MariaDB монолита (8+ лет техдолга) на SvelteKit + Supabase PostgreSQL 17. Старый стек — это нормально, главное чтобы был доступ к коду и БД.

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

Верификация через сравнение SQL-выборок legacy ↔ новая БД на каждом этапе + drift-fix скрипт. Опыт: 17 620 единиц данных мигрировано (10 578 круизов + 7 042 прогулок) с побитовой верификацией. 312k платёжных записей скорректированы за один сеанс.

Можно ли мигрировать без downtime?

Да. Используем insert-only versioning через `valid_from` (старые версии неприкосновенны), public_id backfill через триггеры BEFORE INSERT, ALTER TABLE с `CREATE INDEX CONCURRENTLY`. У нас 211 SQL миграций в production без блокировок.

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

Полная замена стека — 6-18 месяцев параллельной работы старой и новой системы. Мы делаем поэтапно: новый функционал сразу на новом стеке, legacy постепенно выводится. Бюджет от 2-3 млн ₽ за этап.

Можно ли оставить часть logic в legacy?

Да, через bridge: новый фронт делает запросы к остаточной legacy-системе по mTLS + HMAC + Idempotency. Так мы соединили новый ПФ-фронтенд с PHP-системой бронирования заказчика.

Кейсы