Перед rewrite 1С-Битрикс я сначала считаю риск, а не бюджет

Когда ко мне приходят с фразой «хотим переписать 1С-Битрикс на Next.js», я не начинаю с цены.

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

Если на этом этапе сразу назвать бюджет, получится красивая, но бесполезная цифра. Она не покажет, где риск простоя, что будет с SEO, какие интеграции нельзя трогать и почему checkout лучше оставить в старом контуре хотя бы на первом этапе.

Поэтому нормальный первый шаг для сложного Bitrix-проекта — не коммерческое предложение. Нормальный первый шаг — короткий risk audit.

Что я проверяю в первую очередь

Первый слой — деньги и операционный контур. Где каталог, корзина, цены, остатки, скидки, оплата, доставка, 1C-обмен, CRM, личный кабинет. Не в смысле «перечислить модули», а в смысле понять, какие части реально нельзя останавливать.

Второй слой — скорость изменений. Что команда не может выпускать сейчас: новые категории, SEO-страницы, промо, фильтры, поиск, контентные блоки, A/B-гипотезы. Это важно, потому что headless редко нужен ради самого headless. Он нужен, когда старый контур мешает выпускать изменения без боли.

Третий слой — данные. Какие поля товара живут в Bitrix, какие приходят из 1C, какие считаются на лету, какие руками правит контент-команда. На словах «каталог» выглядит одним объектом. На практике это десятки источников правды.

Четвертый слой — SEO-поверхность. URL, canonical, фильтры, пагинация, хлебные крошки, микроразметка, sitemap, редиректы, индексируемые посадочные страницы. Если это не снять до проекта, rewrite легко превращается в «мы ускорили сайт и потеряли органику».

Пятый слой — наблюдаемость. Логи, метрики, slow queries, ошибки API, скорость индексации, cache hit rate. Без этого нельзя честно сказать, что именно тормозит: Bitrix, SQL, шаблоны, внешний API, поиск или CDN.

Почему нельзя обещать fixed price до этой карты

Для продуктовых форматов fixed price возможен: понятный scope, повторяемый стек, известные ограничения.

Для кастомного rewrite или headless-перехода фиксированная цена до discovery почти всегда означает, что кто-то спрятал риск. Его потом все равно оплатят: scope creep, конфликтами, плохими компромиссами или остановкой проекта на середине.

Мне ближе другой формат:

1. Собрать предварительные требования и бизнес-контекст.
2. Разложить функциональность на базовую, optional и client-specific.
3. Зафиксировать API-контракт и зоны, которые не трогаем в первой итерации.
4. Выбрать маленький pilot-scope, где можно измерить скорость, качество и workflow.
5. После этого оценивать большой проект уже не по ощущениям, а по карте фактов.

Такой подход скучнее, чем «сделаем всё за N недель». Зато он защищает деньги клиента и репутацию команды.

Как выглядит хороший pilot

Плохой pilot — «давайте перепишем половину сайта, а потом посмотрим».

Хороший pilot выбирает один участок, где есть бизнес-смысл и технический риск:

• каталоговая категория с тяжелыми фильтрами;
• поиск с Elasticsearch и понятной метрикой качества выдачи;
• отдельная SEO-посадочная страница поверх существующего каталога;
• read-only личный кабинет без вмешательства в оплату;
• новая витрина на Next.js, которая читает данные через ограниченный Bitrix API.

Важно, чтобы pilot не требовал верить презентации. У него должны быть критерии: URL работает, данные корректны, скорость лучше, SEO-мета не потеряна, rollback понятен, команда видит Git Flow и staging.

Если pilot успешен, дальше уже можно обсуждать roadmap. Если нет — это тоже хороший результат. Значит, риск нашли дешево.

Где тут WGP

Я веду WebGoodPeople именно вокруг таких задач: Bitrix-backed e-commerce, Next.js, Elasticsearch, аккуратная модернизация без остановки продаж.

Но я не считаю, что каждому проекту нужен большой rewrite. Иногда достаточно вынести поиск. Иногда нужен audit API. Иногда лучше сначала починить мониторинг и slow queries. Иногда клиенту честнее сказать: «не трогайте checkout в первом этапе».

Если вы смотрите на старый Bitrix-магазин и не понимаете, это rewrite, оптимизация или headless-переход, я бы начал не с бюджета, а с короткой карты риска.

Практический следующий шаг — отправить ссылку на сайт и описать, что сейчас болит: скорость, релизы, поиск, SEO, интеграции или подрядчик. На стороне WGP это превращается в компактный scope: что проверяем, что не трогаем, где возможен pilot и какие критерии решения будут честными.

Связанное чтение: как модернизировать 1С-Битрикс без переписывания, что остаётся в Bitrix при headless-переходе, первые 15 минут аудита проблемного проекта.