Переписывать Bitrix или нет: discovery перед оценкой

Когда ко мне приходят с вопросом «сколько стоит переписать Bitrix на нормальный стек», я почти никогда не отвечаю цифрой в первом сообщении.

Не потому что хочется усложнить продажу. Просто честная оценка rewrite-проекта начинается не с цены, а с карты рисков: что уже приносит деньги, что ломается, какие интеграции нельзя остановить и где команда на самом деле теряет скорость.

Rewrite звучит проще, чем работает

Снаружи задача часто выглядит понятной: есть старый Bitrix, нужен современный фронт, нормальный поиск, быстрый checkout и удобные релизы. Значит, надо переписать.

Внутри почти всегда оказывается другое: каталог живёт по своим правилам, 1C отдаёт данные не так, как написано в документации, SEO держится на исторических URL, менеджеры привыкли к конкретным сценариям в админке, а часть бизнес-логики вообще спрятана в обработчиках событий.

Если в этот момент назвать фиксированную цену, вы продаёте не проект, а иллюзию контроля.

Что я выясняю до оценки

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

Второй слой — данные. Каталог, цены, остатки, фильтры, свойства, SEO-мета, редиректы, личный кабинет, заказы, роли, права, обмены с 1C, CRM, платёжками и доставками. Здесь быстро становится видно, что часть задач базовая, а часть клиент-специфичная.

Третий слой — процесс. Как сейчас выкатываются изменения, где staging, кто принимает релиз, есть ли rollback, как команда понимает, что после деплоя всё работает. В headless-проекте это так же важно, как Next.js или Elasticsearch.

Scope должен быть коротким, но функциональным

Я не люблю документы на 100 страниц, которые никто не читает. Хороший discovery-результат для rewrite или headless-проекта — это компактная структура функциональных требований.

В ней должно быть видно:

базовый scope, без которого запуск не имеет смысла;
optional-блоки, которые можно вынести во вторую очередь;
интеграции и владельцы данных;
acceptance criteria для ключевых сценариев;
риски, которые надо проверить pilot-ом, а не обещанием на словах.

Такой документ помогает owner, CTO и подрядчику говорить об одном и том же проекте. Не «сделайте современно», а «вот первая версия, вот что проверяем, вот что не трогаем до доказательств».

Pilot часто честнее большого контракта

Если главный риск в каталоге, поиске или скорости, я предпочитаю начинать с ограниченного work slice. Например: одна категория, один сценарий поиска, один API-адаптер, одна зона Core Web Vitals.

Это не демо ради демо. Это способ проверить workflow: как команда получает доступы, как пишет код, как проходит review, как ведёт staging, как фиксирует метрики до и после, как объясняет ограничения.

После такого pilot-а разговор о большом проекте становится спокойнее. Видно не только «сколько стоит», но и как именно команда работает.

Когда fixed price уместен, а когда нет

Фиксированная цена уместна для продуктовых форматов, где scope заранее собран и повторяем: например, packaged Frontbox subscription или white-label формат с понятными границами.

Для кастомного rewrite, интеграций, B2B-порталов и нестандартных e-commerce сценариев fixed price до discovery почти всегда вреден. Он заставляет либо прятать риски в запас, либо спорить о каждом изменении после старта.

Мне ближе другой формат: сначала короткая диагностика, затем базовый scope и optional-блоки, затем оценка по этапам или work slice. Так клиент видит бюджетный коридор и понимает, за что платит.

Где здесь моя роль

Моя сильная сторона не в том, чтобы сразу сказать «переписываем всё». Я слишком много раз видел, как старый PHP-код продолжает приносить деньги, пока новый стек ещё только учится повторять базовые сценарии.

Я полезен там, где надо отделить инженерный рефакторинг от бизнес-риска: что оставить в Bitrix, что вынести в Next.js, где нужен Elasticsearch, где достаточно API-адаптера, а где проблему вообще решает процесс релиза.

Если вы смотрите на legacy Bitrix и думаете о rewrite, начинать лучше не с большого контракта. Начните с карты рисков и одного проверяемого участка.

Для коммерческого проекта это можно оформить через WGP: запросить технический audit / Catalog Probe. Для личного разговора — напишите мне в Telegram или LinkedIn.

→ Смежная статья: Фронт деплоится за 3 минуты, бэк — за 40: как мы это решали в headless-проекте