The Myth of the "One-Shot Migration": Why Big Rewrites Fail and What to Do Instead
Author: WebGoodPeople
Миграция с монолита на современный стек в голове большинства CTO выглядит так: команда уходит в «большой переписывание» на 12–18 месяцев, в конце — большой релиз, и всё работает на новом. В реальности эта модель проваливается в 40–60% случаев. Не потому что команды плохие — потому что сама модель плохая.
Альтернатива — strangler fig pattern: постепенное заворачивание старой системы новой, без «большого релиза». Эта статья — про то, почему big-bang провалочен, как устроен strangler fig, и как выглядит реальный план миграции, разбитый на полугодовые этапы, каждый из которых приносит выгоду сам по себе.
Почему big-bang проваливается
Три основных причины, которые мы видим регулярно:
1. Requirements drift
Команда начинает писать, опираясь на текущее состояние бизнеса. За 12–18 месяцев бизнес меняется. К моменту запуска нового сайта команда обнаруживает, что переписала то, что уже неактуально.
Пример: команда переписывала каталог в 2023 году. Когда закончили в 2024, выяснилось, что половина категорий слита, правила ценообразования изменились, и SEO-структура требует переработки. Переписывание переписывания.
2. Скрытая сложность монолита
Монолит содержит 100–200 edge-кейсов, которые никто не задокументировал. Промокоды с правилами, сегментные скидки, исключения для партнёрских аккаунтов, legacy-клиенты с особыми ценами. Всё это работает в текущем коде, но никто не знает как.
Команда переписывает «основное», а при запуске выясняется, что отвалилось 50 сценариев, про которые никто не знал. Следующие полгода уходят на «дореализацию того, что уже работало».
3. Big-bang = high-risk decision для бизнеса
Даже когда технически всё готово, решение переключить 100% трафика на новое за одну ночь — это решение, которое CFO/CEO не готов брать. Оно откладывается. Команда ждёт. Новый сайт стареет ещё не запущенным.
Strangler Fig: идея
Name comes from a tree pattern: a strangler fig grows around the host tree, eventually replacing it, without ever cutting the host. In software: new system grows around the old, handling more and more, until the old is redundant. The old is never "cut" — it simply becomes vestigial.
Применительно к e-com:
Начало: монолитный Битрикс обрабатывает всё.
Месяц 3: Next.js-фронт обслуживает страницы каталога. Битрикс обслуживает всё остальное.
Месяц 6: Next.js обслуживает каталог + карточку + корзину. Битрикс — admin + checkout + billing.
Месяц 9: Next.js обслуживает публичную часть полностью. Битрикс — только admin + workflow.
Месяц 12+: Битрикс можно заменить на любой более удобный admin (или оставить — уже не важно).
Ключевое: на каждом месяце Битрикс работает, Next.js работает, пользователи не видят разницы. Новый функционал добавляется на Next.js. Старый постепенно мигрирует. Никаких «больших релизов».
6-этапный план миграции strangler fig
Этап 1. API-слой и первая страница (месяц 1–2)
- Поставить API между Битрикс и клиентами
- Перенести одну страницу на Next.js — обычно категорийку как самую денежную
- Canary → 5% → 50% → 100% этой страницы за 2 недели
Выгода этапа: на этой одной странице TTFB падает с 900мс до 300мс. Конверсия растёт на 3–5%. Это уже окупает первые 2 месяца работы.
Этап 2. Product detail page (месяц 3)
- Добавить карточку товара на Next.js
- Интеграция с корзиной (пока корзина — ещё на Битриксе, через iframe или fetch)
- Canary → 100% за 1 неделю
Выгода: TTFB карточки падает. Time to interactive падает. Конверсия от карточки до «добавить в корзину» растёт.
Этап 3. Поиск и фильтры (месяц 4)
- Подключить Elasticsearch к Next.js напрямую
- Заменить старый поиск/фильтры на новый
- A/B тест через interleaving, чтобы измерить разницу
Выгода: Zero-rate с 22% до 2%. Конверсия через поиск +30–60%.
Этап 4. Корзина и checkout (месяц 5–6)
Самый рискованный этап. Здесь пользователи реально вводят платёжные данные.
- Новую корзину параллельно со старой
- Canary 1% → 5% → 20% с двойной аналитикой
- Сверяем финансовые метрики (успешность платежа, потерянные заказы) в реальном времени
- Ramp-up медленнее обычного: 2 недели на каждый шаг
Выгода: Чекаут быстрее → completion rate выше. По нашим данным +10–20% к completion после миграции.
Этап 5. Personal account и history (месяц 7–8)
- Личный кабинет, история заказов, избранное — на Next.js
- Интеграция с Битрикс как с хранилищем истории
Выгода: страницы кабинета быстрее → вовлечённость вернувшихся пользователей растёт.
Этап 6. Admin или оставить (месяц 9+)
Тут развилка. Два варианта:
Вариант A: оставить Битрикс как admin. Менеджеры продолжают работать в привычной админке. Фронт на Next.js читает данные через API. Никто не переучивается. Миграция закончена — публично сайт на Next.js, внутри админка Битрикс.
Вариант B: заменить админку на headless CMS (Strapi, Sanity, Directus, Payload). Требует переучивания менеджеров. Делается только если есть сильный бизнес-кейс (текущая админка реально тормозит процессы).
80% наших клиентов выбирают Вариант A. Битрикс — хорошая админка, просто плохой фронт.
Почему этот подход работает
Выгода на каждом этапе. Не ждём 18 месяцев — первые результаты через 2 месяца. ROI непрерывный.
Риск ограничен scope этапа. Если этап 4 провалился — это проблема одного этапа, не всего проекта. Остальные работают.
Requirements не drift-ят. Каждый этап короткий, требования не успевают поменяться.
Возможность остановиться. После любого этапа можно сказать «нам достаточно» и не делать следующие. У вас всё ещё есть улучшенный сайт.
Менеджеры адаптируются постепенно. Процессы в админке не ломаются одномоментно.
Когда big-bang всё-таки оправдан
Редкие случаи, когда staged decomposition невозможен:
- Смена стека БД. Переезд с MSSQL на PostgreSQL одномоментный по необходимости. Но это data migration, не frontend миграция — другая задача.
- Полная смена бизнес-модели. Если вы переходите с retail на marketplace — логика другая, переписывать надо много. Но и это можно делать параллельно с текущим сайтом.
- Принудительный EOL. Если Битрикс 16 снимается с поддержки и надо на Битрикс 18 за 3 месяца — это вынужденная миграция. Но тоже редко требует полного рерайта.
В 90% случаев strangler fig — правильный выбор.
Что делать прямо сейчас
Если у вас в планах «переписать всё» — задайте три вопроса:
- Можно ли начать с одной страницы? Обычно да.
- Приносит ли эта одна страница выгоду сама по себе? Если категорийка — почти всегда да.
- Можно ли обеспечить сосуществование старого и нового через API-слой? Почти всегда да.
Три «да» = вам подходит strangler fig. Можно не делать big-bang.
Если не уверены — 48-часовой аудит отвечает именно на эти вопросы. Возвращаем конкретный план первого этапа с оценкой часов, рисков и ожидаемой выгоды.