Подготовка: 3 условия для старта
Прежде чем идти в проект, проверьте три условия. Без них миграция превратится в «переписать всё» и съест 9 месяцев.
- Backend стабилен. Если 1С‑обмен падает раз в неделю и никто не может найти причину — сначала чините это, потом мигрируйте. Headless поверх хаоса = хаос с красивым UI.
- SEO baseline зафиксирован. Выгрузите позиции по ТОП‑1000 запросов и Core Web Vitals до старта. Иначе через 3 мес вы не сможете доказать, что миграция не уронила трафик.
- Есть product owner со стороны клиента. Не CTO, не CMO — конкретный человек, который принимает решения по scope и сроку релиза.
Этап 1. Catalog Probe (3 дня)
Загружаете CSV/XML каталога на демо‑стенд Frontbox. Через 3 дня получаете ссылку на живой preview магазина на Next.js с вашими товарами, ценами и фото.
Deliverable: preview‑домен, скриншоты, замер LCP/TTFB/INP, список несоответствий в каталоге (дубли SKU, битые изображения, пропущенные атрибуты).
Зачем: в 30% случаев discovery заканчивается тут — команда понимает, что сначала надо чистить данные, а не мигрировать.
Этап 2. Discovery и SEO‑audit (3–5 дней)
- Аудит URL‑структуры: все /catalog/, /product/, /info/.
- Сбор Core Web Vitals текущего сайта с Яндекс.Метрики и Search Console.
- Карта интеграций: 1С, ЮKassa, СДЭК, маркетплейсы, BI, ESP.
- Анализ кастомных компонентов Битрикса — что переиспользуем, что выкидываем.
- Backlog из 20–30 user stories с приоритетами P0 / P1 / P2.
Этап 3. Pilot на одной категории (2–4 недели)
Выбираем одну категорию — обычно среднюю по трафику, чтобы A/B был показательный. На ней разворачиваем полный scope: PDP, листинг, корзина, чекаут, оплата, доставка.
Этап 4. Интеграционный слой (3–6 недель параллельно)
Пока команда работает над pilot, мы строим data‑layer для full replatform:
- 1С‑обмен: webhook из Битрикса → очередь в Frontbox → индексация в Elasticsearch.
- Платежи: абстрактный PaymentGateway, под него — ЮKassa, Tinkoff, СБП, Kaspi, Stripe.
- Доставка: единый shippingProvider с адаптерами СДЭК, Boxberry, Почта, DPD.
- Маркетплейсы: feed‑генераторы для WB, Ozon, Kaspi, Яндекс Маркет.
- Мониторинг: Sentry, Grafana, Telegram‑алерты на сбой sync или падение SLA.
Этап 5. A/B‑cutover (4–8 недель)
Начинаем с 5% мобильного трафика на Frontbox. Каждые 3–5 дней наращиваем: 5% → 15% → 30% → 50% → 80% → 100%. На каждом шаге — сверка метрик по:
- Conversion Rate (mobile и desktop отдельно).
- Bounce на PDP и listing.
- Core Web Vitals (LCP / INP / CLS) в реальных пользовательских сессиях.
- Количество ошибок в чекауте и оплате.
- Позиции по ТОП‑100 SEO‑запросам.
Этап 6. Full replatform (1–2 недели)
Все страницы Frontbox, старый Битрикс‑фронт выключен. На этом этапе делаем финальный 301‑map на всё, что изменилось, и пингуем Яндекс + Google новый sitemap.
Этап 7. Нагрузочные тесты и Чёрная Пятница
Перед пиком (BFCM, новогодние распродажи, 11.11) гоняем k6‑сценарии на 3–5× обычной нагрузки. Edge‑кэш, Elasticsearch, API Битрикса проверяем отдельно.
Этап 8. Handoff и SLA
- Исходники Frontbox (open‑core) в вашем Git.
- Документация: архитектура, API, runbook по инцидентам.
- CI/CD пайплайны у вас в GitHub / GitLab.
- Опция retainer: 20–40 ч/мес, SLA 99.9% с денежным штрафом.
Rollback‑процедура
На каждом этапе cutover откат — одна команда в CI. Старый Битрикс‑фронт работает параллельно все 6 недель. Если Frontbox ведёт себя хуже в метрике — возвращаем 100% трафика за 15 минут.
Финальный чек‑лист
- ☐ Catalog Probe готов, метрики замерены.
- ☐ SEO baseline зафиксирован (позиции + CWV).
- ☐ Pilot‑категория прошла A/B, метрики не хуже.
- ☐ Интеграционный слой покрыт e2e‑тестами.
- ☐ 301‑map сгенерирован и залит в sitemap.
- ☐ Нагрузочные тесты на 3×.
- ☐ Rollback‑процедура прогнана на staging.
- ☐ Handoff‑пакет собран и передан.
- ☐ SLA подписан, penalties активированы.
Частые вопросы
Подходит ли этот playbook, если у нас нестандартная конфигурация Битрикса?
В большинстве случаев да. Playbook построен на API‑интеграции, а не на замене Битрикса. Если у вас есть REST API каталога — даже кастомный — Catalog Probe отработает на нём. Если API нет совсем, начинаем с Phase 2 (Discovery), чтобы понять объём работ по выгрузке данных.
Можно ли начать с Phase 3 (Pilot), пропустив Catalog Probe?
Технически можно. Но Probe стоит 3 дня и показывает реальные метрики скорости до любых вложений. В 30% случаев после Probe становится ясно, что данные надо чистить сначала. Пропуск этого шага обычно обходится дороже на этапе Pilot.
Что делать, если SEO‑позиции упали после запуска Pilot?
Посмотрите на три вещи: корректно ли настроены canonical‑теги на Pilot‑категории, нет ли дублирования URL на старом и новом фронте, правильно ли передан hreflang. Просадка на одной категории обычно не бьёт по общему трафику. Если падение больше 15% за неделю — откатывайте через CI и разбирайтесь с картой URL.
Сколько времени занимает весь процесс от Probe до финального cutover?
Минимум — 2 месяца для магазина до 5 000 SKU с типовыми интеграциями (ЮKassa, СДЭК, 1С). Обычно — 3–4 месяца. Главный удлинитель — нестандартные интеграции (ERP, кастомный 1С‑обмен) и смена команды на стороне клиента в середине проекта.
Нужна ли отдельная команда для Phase 4 (интеграционный слой)?
Не отдельная, но параллельная. Пока один инженер работает над Pilot‑UI, второй строит data‑layer. Если работаете в одиночку — последовательный подход увеличивает сроки примерно на 3 недели.
Что происходит с заказами во время A/B cutover?
Заказы, оформленные на Frontbox‑фронте, сразу попадают в Битрикс‑бэкенд через тот же API. Разделения баз данных нет — источник правды один. Ни один заказ не теряется при откате. Это ключевое преимущество перед big bang.
Когда оправдан переход сразу на Full replatform без постепенного A/B?
Только для маленьких магазинов: до 500 SKU, одна категория, минимум интеграций, нет зависимости от SEO‑трафика. В остальных случаях A/B cutover снижает риск на порядок. Резкое переключение 100% трафика на новый фронт без A/B — это по сути тот же big bang, только с готовым кодом.
Как убедиться, что нагрузочные тесты отражают реальный пик?
Возьмите данные Яндекс.Метрики за прошлый BFCM или пиковый день. Смотрите на пиковый RPS в 15‑минутных интервалах, а не среднесуточный. Умножьте на 3×. Тестируйте edge‑кэш, Elasticsearch и API Битрикса отдельно — у каждого своё узкое место.