Rewrite на Next.js без саморазрушения: что проверить до первой строки кода

У founder или CTO обычно есть понятное желание: старый Bitrix/PHP-фронт мешает, команда устала от легаси, маркетинг хочет быстрые страницы, разработчики хотят Next.js. В этот момент легко назвать проект "rewrite" и сразу открыть новый репозиторий.

Я бы не начинал с репозитория. Я бы сначала нашел, где именно система зарабатывает деньги и где rewrite может их случайно остановить.

Rewrite почти всегда продается как техническое решение

На практике это бизнес-риск с технической оболочкой.

Если переписать только UI, но не понять каталог, фильтры, SEO-страницы, корзину, интеграции с 1C/ERP/CRM и контентные процессы, новый стек не спасет. Он просто перенесет хаос в более современный интерфейс.

Next.js хорош, когда он становится управляемым слоем поверх понятных контрактов. Плохой вариант — когда он становится красивой витриной, которая в первый же месяц начинает зависеть от десятков неописанных исключений старой системы.

Пять вещей, которые я проверяю до оценки

1. Какие страницы реально приносят трафик, заявки или заказы.
2. Какие данные нельзя потерять: URL, фильтры, товарные свойства, статусы, цены, остатки, роли.
3. Какие интеграции должны работать в день запуска, а какие можно вынести во второй этап.
4. Где нужен zero-downtime rollout, а где допустим короткий controlled switch.
5. Как будет измеряться успех: скорость, конверсия, lead time изменений, стабильность, SEO-индексация.

После этого можно разделить scope на базовый слой и optional/client-specific слой. Только тогда разговор про стоимость становится честным. Для кастомного rewrite фиксированная цена до discovery почти всегда означает, что кто-то уже прячет риск в договор, маржу или будущие доплаты.

Малый pilot лучше большого обещания

Хороший первый шаг — не "переписать сайт", а взять ограниченный slice:

• один типовой каталог или раздел;
• одну критичную пользовательскую цепочку;
• один API-контракт между старой системой и новым фронтом;
• один набор метрик до/после;
• staging/prod-checklist и понятный rollback.

Так видно, как команда работает с данными, Git Flow, ревью, тестами, инфраструктурой и edge cases. Это честнее, чем обещать магическую скорость без доступа к реальной системе.

Где AI помогает, а где нет

AI-assisted development ускоряет рутину: компоненты, тестовые сценарии, адаптеры, документацию, первичную миграцию шаблонов. Но AI не решает, какие бизнес-правила нельзя ломать, какие URL нельзя потерять и где старый checkout держится на трех неочевидных условиях.

Эту часть должен держать senior engineer с owner mindset. Иначе rewrite превращается в быстрый набор кода, который потом долго чинят в production.

Мой короткий вывод

Если вы смотрите на Bitrix/PHP legacy и думаете про Next.js, не начинайте с вопроса "сколько стоит переписать". Начните с вопроса "какой маленький slice покажет риск, скорость и качество команды".

Когда нужен внешний взгляд, я обычно предлагаю компактный risk-audit или pilot: разобрать текущий контур, выделить базовый scope, отделить optional, проверить один живой путь и только потом считать полноценный проект. Для e-commerce rewrite это экономит больше денег, чем самая оптимистичная оценка на старте.

Если задача уже ближе к студийному формату, у WGP есть понятный вход через pilot / test slice — без обещаний фиксированной цены до discovery, зато с проверкой workflow на реальном куске системы.