А потом бизнесу понадобится что-нибудь совсем обычное. Например, новый сценарий в корзине, несколько вариантов цены для разных клиентов или очередная интеграция.
И тут выясняется, что сделать это не так просто.
Разработчику сначала нужно разобраться со старыми доработками, проверить, что они не заденут обмен с 1С, а после изменения — протестировать ещё несколько связанных участков. Обновление CMS откладывается по той же причине. Даже ускорение одной страницы иногда требует разбираться с кодом, который писался несколько лет назад.
В какой-то момент возникает вполне логичный вопрос:
«Может, уже проще сделать новый сайт?»
Иногда да. Но сам по себе этот вопрос ещё ничего не говорит о состоянии проекта.
Новый сайт может решить системную проблему. А может оказаться дорогой заменой нескольких старых модулей, которые вполне можно было привести в порядок.
Поэтому начинать стоит не с выбора между старым и новым сайтом. Сначала нужно понять, что именно мешает текущему проекту развиваться.
«Старый» сайт — это не диагноз
Возраст проекта обычно переоценивают.
Интернет-магазину может быть пять или семь лет, но если его архитектура понятна, интеграции работают, обновления проходят нормально, а новые задачи не превращаются в отдельные проекты — менять всё целиком необязательно.
Обратная ситуация тоже вполне реальна. Новый сайт может выглядеть современно, но иметь слабую архитектуру, неудачные интеграции и проблемы с производительностью.
Поэтому при оценке проекта мы обычно разделяем несколько вещей.
Интерфейс и UX. Пользователю трудно найти товар, неудобно оформлять заказ, мобильная версия выглядит устаревшей. Это повод для редизайна, но не обязательно для переписывания backend.
Функциональность. Появились новые правила заказа, личный кабинет, разные цены, новая CRM или ещё одна внешняя система. Здесь сначала нужно проверить, ограничивает ли вас сама платформа или конкретная реализация.
Технический долг. Старый код становится всё дороже менять. Разработчик тратит время не на новую функцию, а на то, чтобы понять, почему предыдущая работает именно так.
Архитектура. Бизнес вырос, а система осталась прежней. Был небольшой каталог — стало несколько десятков тысяч товаров. Один склад превратился в несколько. К 1С добавились CRM, доставка, оплата и другие сервисы.
Производительность и стабильность. Сайт медленно работает, отдельные операции выполняются слишком долго, после очередной доработки появляются новые проблемы.
Если проблема находится в одном месте, её обычно можно решить отдельно. Если же изменения постоянно затрагивают друг друга, пора смотреть на архитектуру целиком.
Сначала понять, что можно сохранить
«Сделать новый сайт» — не единственный способ избавиться от старых проблем.
Можно оставить серверную часть и переделать интерфейс. Заменить конкретный модуль. Перестроить обмен с 1С. Вынести тяжёлую операцию в отдельный сервис. Обновить окружение и постепенно убрать старые зависимости.
Поэтому перед началом работ полезно составить простой список:
- что работает нормально;
- что работает, но уже мешает развитию;
- что нужно заменить;
- что в существующей архитектуре реализовать без постоянных обходных решений уже не получается.
Последний пункт особенно важен. Технически новую функцию почти всегда можно «прикрутить». Но если для этого приходится добавлять несколько исключений, дублировать данные и связывать между собой ещё пять модулей, вопрос уже не в возможности разработки, а в цене такого решения.
Поэтому перед серьёзной модернизацией имеет смысл провести технический аудит. Причём его результатом должен быть не отчёт на несколько десятков страниц, а понятный план: что оставить, что переделать, что заменить и где действительно нужен новый код.
Когда старый проект можно спокойно развивать
У рабочего сайта есть довольно простой тест. Если разработчик может разобраться в проекте, оценить задачу и примерно предсказать, что произойдёт после изменения, с системой всё ещё можно работать.
Архитектура понятна
Неважно, сколько лет проекту. Важно, можно ли объяснить, где находится бизнес-логика, как связаны модули и откуда берутся данные.
Старый код сам по себе не проблема. Намного хуже код, который работает, но никто уже не понимает почему.
Проблемы можно локализовать
Если нужно переделать фильтр, исправить страницу заказа или добавить несколько полей в личный кабинет и при этом не приходится переписывать половину системы, это хороший признак.
Простой ориентир выглядит так:
изменили один участок → проверили связанные сценарии → выпустили изменение.
Если же любая небольшая задача начинается с изучения самописных модулей, старого обмена с 1С и нескольких поколений доработок, проблема уже носит системный характер.
Платформа и окружение не стали ограничением
Сам факт, что магазин работает на Битрикс несколько лет, не означает необходимости менять CMS.
Сначала стоит проверить сам проект и его окружение. Например, с 1 февраля 2026 года для продуктов 1С-Битрикс требуется PHP 8.2 или выше, а рекомендуемой является PHP 8.4 и выше. Если старый сайт работает на более ранней версии, это повод оценить совместимость модулей и доработок с новым окружением, а не автоматически объявлять проект устаревшим.
Та же логика работает с базой данных, сторонними модулями и интеграциями.
Поддержка не съедает всё развитие
Ошибки будут всегда. Вопрос в другом: сколько времени команда тратит на их исправление.
Если разработчики могут планировать новые задачи, обновлять систему и выпускать изменения без постоянного страха что-нибудь сломать, текущий проект, скорее всего, имеет смысл сохранять.
Когда доработки начинают обходиться слишком дорого
Обычно сайт не становится плохим в один конкретный день. Сначала одна небольшая задача занимает вместо пяти часов десять. Потом добавляется дополнительное тестирование. Через некоторое время даже обновление PHP превращается в отдельный проект.
Есть несколько характерных признаков:
- простая задача затрагивает несколько несвязанных модулей;
- обновления откладываются из-за страха сломать старые доработки;
- одни и те же ошибки появляются снова после исправлений;
- обмен с 1С или CRM работает только благодаря набору исключений и ручных действий;
- новые функции становятся дорогими именно из-за устройства старого проекта;
- на поддержку уходит всё больше времени, а на развитие — всё меньше.
Последний пункт обычно заметнее всего бизнесу. Если команда большую часть времени поддерживает то, что уже есть, а новые задачи постоянно откладываются, стоит посчитать стоимость не только следующей доработки, но и всей дальнейшей эксплуатации.
При этом решение всё равно может оказаться промежуточным: иногда достаточно заменить один проблемный модуль или закрыть конкретный технический долг.
Необязательно переписывать всё сразу
Полный rewrite работающего интернет-магазина — это отдельный проект с миграцией данных и бизнес-процессов.
Нужно перенести товары, пользователей и заказы, сохранить URL и поисковый трафик, заново подключить 1С, CRM, оплату и доставку. А главное — сделать всё это без остановки бизнеса или хотя бы с минимальным простоем.
Поэтому во многих случаях удобнее двигаться частями:
аудит → целевая архитектура → проблемные участки → замена компонентов → перенос функциональности → отключение старых механизмов.
Допустим, каталог на Битрикс начал заметно тормозить. Прежде чем менять CMS, имеет смысл посмотреть, что именно происходит. Причиной могут быть тяжёлые запросы к базе, отсутствие нужных индексов, неправильное кеширование, слишком сложная фильтрация или синхронные операции, которые давно пора выполнять через очередь.
После такой проверки может выясниться, что проблема решается оптимизацией. Или заменой одного модуля. Или переработкой конкретного участка архитектуры.
То же самое относится к 1С. Если обмен стал слишком тяжёлым, не обязательно переносить весь магазин на другую платформу. Иногда достаточно разделить обмен на отдельные операции, добавить очередь и повторную обработку ошибок, чтобы синхронизация больше не влияла на пользовательские запросы.
Но есть важное условие: модернизация должна идти к понятной целевой архитектуре. Иначе вместо одного старого проекта через несколько лет получится тот же проект, только с ещё большим количеством временных решений.
Сколько на самом деле стоит старый сайт
Сравнивать стоимость одной доработки с ценой нового сайта почти бессмысленно.
У существующего проекта есть расходы, которые не видны в смете: поддержка, тестирование, исправление технического долга, риски при обновлениях и время разработчиков на разбор старого кода.
Поэтому полезно смотреть хотя бы на несколько лет вперёд.
Условно стоимость решения можно представить так:
первоначальные работы + стоимость владения + риски + будущие изменения.
Причём риски для интернет-магазина вполне материальны. Это простой, потерянные заказы, проблемы с SEO, ошибки в обмене с учётной системой или невозможность быстро запустить важную функцию.
Если сайт планируют активно развивать следующие три-пять лет, стоимость будущих изменений иногда оказывается важнее цены самого запуска.
Если подрядчик предлагает новый сайт
Фраза «этот проект уже проще переписать» сама по себе ничего не доказывает.
Перед согласованием нового проекта стоит попросить показать конкретные причины:
- какие ограничения текущей архитектуры нельзя устранить;
- какие части проекта можно сохранить;
- что выгоднее заменить отдельно;
- как будут перенесены данные и заказы;
- что произойдёт с URL и SEO;
- как будут перенесены интеграции с 1С, CRM, оплатой и доставкой;
- можно ли разделить миграцию на этапы.
Это помогает отделить действительно необходимый rewrite от ситуации, когда подрядчику просто удобнее начать с чистого листа.
Но бывает и обратное. Если аудит показывает, что бизнес-логика размазана по проекту, изменения вызывают цепную реакцию, старые компоненты нельзя нормально изолировать, а стоимость поддержки постоянно растёт, полный rewrite может оказаться более понятным и предсказуемым решением.
Что выбрать: доработку, модернизацию или новый сайт
На практике выбор обычно сводится к трём вариантам.
- Дорабатывать, если сайт в целом понятен и проблемы находятся в отдельных местах.
- Модернизировать, если часть архитектуры уже мешает развитию, но основу проекта можно сохранить.
- Переписывать, если ограничения затрагивают всю систему и исправлять их по частям становится дороже, чем построить новую архитектуру.
И здесь не стоит искать универсальный срок жизни сайта. Пять лет — не повод для rewrite. Десять лет — тоже не приговор.
Гораздо полезнее посмотреть на то, сколько сегодня стоит сделать следующее изменение.
Если новая функция становится дорогой из-за архитектуры, обновление окружения каждый раз превращается в риск, а поддержка вытесняет развитие — это уже повод серьёзно заняться проектом.
Если же сайт стабильно работает, изменения предсказуемы, а бизнес получает нужные функции за разумные деньги, менять его целиком только ради нового интерфейса смысла нет.
Поэтому начинать лучше не с вопроса «какой сайт нам сделать», а с другого:
что в текущем проекте действительно мешает бизнесу — и дешевле ли это исправить, чем заменить?
Ответ обычно находится после технического аудита. И чем раньше его сделать, тем меньше вероятность потратить бюджет на переписывание того, что вполне можно было сохранить.
