Вопрос “когда менять CMS сайта” обычно всплывает не после умного анализа, а после третьего подряд инцидента: упал сайт при обновлении плагина, интеграция с оплатой перестала работать после апдейта банка, менеджер полчаса ищет, где в админке поменять цену. На практике я работаю и с Tilda, и с WordPress, и с кастомной разработкой на Laravel и Next.js, и вижу одну и ту же картину - бизнес меняет CMS не потому, что старая плохая сама по себе, а потому что она перестала успевать за задачами. Ниже - семь признаков, по которым я определяю, что клиенту пора переезжать, а не латать текущий движок.
Первый признак: любая правка требует трёх костылей вместо одной
Если для смены текста на баннере нужно лезть в код, а не в редактируемый блок - это тревожный звонок. У меня были проекты на Tilda, где кастомные скрипты в блоке T123 разрослись до полутысячи строк JS, потому что через них навешивали и валидацию форм, и интеграцию с CRM, и подсчёт скидок. Каждая новая доработка требовала перечитывать весь этот код, потому что документации по нему никто не вёл.
То же самое бывает на старом WordPress: сайт держится на связке из 20+ плагинов, половина из которых не обновлялась три года, а функциональность из категории “добавить поле в форму заказа” требует правки в functions.php темы, которую делали на аутсорсе пять лет назад. Если рядовая задача занимает не час, а неделю согласований “как бы не сломать”, CMS уже не подходит под масштаб бизнеса.
Второй признак: скорость сайта тормозит и продажи, и SEO
Core Web Vitals - не абстрактная метрика для галочки в Search Console, а прямой фактор конверсии. По моим замерам на клиентских проектах разница в LCP от 4 секунд до 1,5 секунд после переезда с перегруженного WordPress на статическую генерацию давала рост конверсии на 15-25%, в зависимости от ниши. Старые CMS часто не умеют нормально кэшировать динамический контент, тянут по 40-60 внешних скриптов от аналитики, чатов и виджетов, и в итоге отдают страницу за 5-7 секунд на мобильном.
Если PageSpeed стабильно показывает красную зону, а сама платформа физически не даёт подключить нормальное кэширование или CDN без переписывания половины шаблонов - это тоже сигнал, что дальше тюнинговать бессмысленно, дешевле пересобрать на технологии, которая изначально быстрее.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Третий признак: интеграции с CRM, эквайрингом и доставкой держатся на честном слове
Этот пункт я вижу чаще всего у интернет-магазинов. Классика: связка WooCommerce с эквайрингом T‑Bank настроена через плагин трёхлетней давности, который разработчик уже не поддерживает, а после очередного обновления PHP на хостинге платежи начинают падать в статус “ошибка” через раз. Или доставка через СДЭК подключена кастомным скриптом, который дергает старую версию API, а СДЭК тем временем перевёл интеграцию на новый протокол - и расчёт стоимости доставки на сайте расходится с реальным на 200-300 рублей.
Отдельная история - уведомления через Telegram-ботов на aiogram, которые кто-то когда-то прикрутил к CMS через вебхук на VPS, а теперь никто не знает, кто администрирует этот сервер. Когда критичная для бизнеса логика - оплата, доставка, уведомления менеджеру о новом заказе - держится на нескольких независимых скриптах-заглушках, которые никто системно не поддерживает, риск простоя растёт с каждым месяцем. Часть таких сценариев можно закрыть без полного переезда - например, вынести уведомления и обработку заказов в отдельный процесс через n8n, но если проблема системная и таких костылей десяток, дешевле пересобрать ядро.
Четвёртый признак: платформу перестали развивать
Я регулярно встречаю сайты на движках, у которых последний мажорный релиз вышел три-четыре года назад: самописные CMS от студий, которые закрылись, редкие зарубежные платформы без локализации, старые версии Bitrix без техподдержки. Проблема не в ностальгии по коду, а в безопасности: без патчей уязвимости накапливаются, а специалистов, готовых разбираться в мёртвой платформе, на рынке становится всё меньше и стоят они дороже, чем разработка на актуальном стеке.
Если на вакансию “доработать наш сайт на CMS X” вам последний год отвечают тишиной или ценником в разы выше рыночного - это не разработчики зажрались, это рынок сигналит, что технология умирает.
Пятый и шестой признаки: админка бесит команду, а стоимость доработок растёт быстрее выручки
Эти два признака идут рука об руку. Когда менеджеры жалуются, что в админке нельзя быстро найти нужный заказ, а SEO-специалист не может сам поправить title и description без разработчика, скорость реакции бизнеса на рынок падает. А дальше начинается воронка: каждая новая фича стоит дороже предыдущей, потому что архитектура не рассчитана на рост, и в какой-то момент сумма мелких доработок за год превышает стоимость полноценного переезда.
| Ситуация | Года доработок на старой CMS | Переезд на актуальный стек |
|---|---|---|
| Интернет-магазин, 5-10 доработок в год | 150 000-300 000 ₽/год суммарно | от 80 000 ₽ разово + предсказуемая стоимость доработок дальше |
| Сайт на Tilda с разросшимися кастомными скриптами | от 3 000 ₽ за правку, но правки конфликтуют друг с другом | от 60 000 ₽ на WordPress или от 150 000 ₽ на кастомный веб-сервис с чистой архитектурой |
| CRM-функциональность на плагинах | риск падения при каждом обновлении | от 100 000 ₽ на CRM/админ-панель на React под конкретные процессы |
Цифры по доработкам старой CMS я привожу по опыту клиентских проектов, где считал реальные затраты за год - у вас цифры могут отличаться, но сама логика “тришкин кафтан дороже нового пальто” подтверждается почти всегда, если считать честно, включая время простоя и упущенные продажи.
Седьмой признак: бизнес-процессы обогнали возможности платформы
Это самый показательный сигнал. Если отдел продаж хочет автоматическую сегментацию лидов, склад - синхронизацию остатков в реальном времени, а маркетинг - персонализированные предложения на основе истории покупок, и всё это нужно собирать через n8n или отдельные скрипты в обход CMS, потому что сама платформа не умеет работать с внешними API нормально - CMS уже не растёт вместе с бизнесом, а тормозит его.
Я в таких случаях обычно смотрю не на возраст сайта, а на то, сколько внешних сервисов и скриптов подключено в обход стандартной функциональности CMS. Если их больше пяти и каждый - точка отказа, разумнее спроектировать архитектуру заново, чем наращивать ещё один слой костылей. Подробный разбор вариантов миграции и цен под конкретную задачу - на странице услуг, там же расписаны сроки по каждому типу проекта.
Куда переезжать: сравнение вариантов
| Задача бизнеса | Куда переезжать | Стоимость |
|---|---|---|
| Лендинг, промо-сайт, быстрый запуск | Tilda | от 30 000 ₽ |
| Каталог, блог, средний интернет-магазин | WordPress | от 60 000 ₽ |
| Интернет-магазин под ключ с интеграциями | WordPress + WooCommerce или кастомная разработка | от 80 000 ₽ |
| Личный кабинет, сложная логика, высокие нагрузки | Веб-сервис/SPA на актуальном стеке | от 150 000 ₽ |
| Внутренние процессы, CRM, отчётность | CRM/админ-панель на React или API на Laravel | от 100 000 ₽ |
Выбор платформы почти всегда определяется не модой, а тем, сколько кастомной логики понадобится в ближайшие два-три года. Если бизнес растёт стабильно и без резких скачков - переезд на WordPress или Tilda с нормальной архитектурой закрывает вопрос надолго. Если процессы уникальные и завязаны на несколько внешних систем одновременно - дешевле в перспективе сразу закладывать кастомную разработку, чем через год снова упираться в ограничения коробочного решения.
Разобраться перед стартом
Консультация
от 3 000 ₽
Подробнее →Частые вопросы
Сколько по времени занимает переезд на другую CMS?
Для простого сайта на Tilda или лендинга - от 2 до 3 недель. Интернет-магазин с переносом каталога, интеграцией эквайринга и доставки через СДЭК обычно занимает от 4 до 8 недель, в зависимости от объёма товарных позиций и количества внешних сервисов. Кастомный веб-сервис с уникальной логикой может растянуться на 2-4 месяца - здесь сроки считаются индивидуально после технического аудита.
Можно ли обойтись доработкой текущей CMS вместо полного переезда?
Иногда да. Если проблема в одной-двух интеграциях или в отсутствии автоматизации, часто хватает точечного решения - например, вынести обработку заказов и уведомления в n8n или дописать конкретный скрипт для CMS вместо переезда. Но если костылей больше пяти и они конфликтуют друг с другом, доработка становится дороже переезда в перспективе года.
Что делать с SEO при смене CMS, чтобы не потерять позиции в поиске?
Главное - сохранить структуру URL или настроить корректные 301-редиректы со старых адресов на новые, перенести метатеги и микроразметку, и не менять всё одновременно с дизайном и текстами. По моей практике при аккуратном переезде просадка трафика минимальна и восстанавливается за 2-4 недели, а часто скорость загрузки новой платформы даже подтягивает позиции вверх.
Есть ли смысл переезжать, если сайт работает стабильно, просто устарел визуально?
Если технических проблем нет, а не устраивает только дизайн - можно обойтись редизайном на текущей платформе, это дешевле. Переезд оправдан, когда к визуальным вопросам добавляются реальные ограничения: медленные доработки, проблемы с интеграциями или падающая скорость загрузки. Смешивать эти два повода в один проект не стоит - сначала стоит честно оценить, что из перечисленного в статье реально мешает бизнесу расти.