Как перенести интернет-магазин на новую CMS и не потерять заказы в CRM

Как перенести интернет-магазин на новую CMS и не потерять заказы в CRM

Переезд на новую CMS редко срывается из-за вёрстки. Бизнес теряет заказы на стыке сайта и CRM: отваливаются выгрузки товаров, путаются статусы, менеджер узнаёт о покупке из письма на общую почту. Ниже — порядок работ для микро- и малого бизнеса Беларуси: что зафиксировать до старта, какие данные переносить первыми и как проверить, что после переключения домена заказы по-прежнему попадают в CRM, а не в чей-то личный чат.

Почему заказы теряются не на вёрстке, а на стыке с CRM

Сайт и CRM связаны набором договорённостей, которые редко кто-то документирует: API-ключ, вебхук на создание заказа, справочник статусов, правила сопоставления товаров по артикулу. Пока магазин работает на старой CMS, эти связки живут годами и никого не беспокоят. При переезде их переносят последними, «когда всё заработает». В этот момент и появляется разрыв.

Типичная картина: корзина на новом движке собирает заказ, но вебхук смотрит на старый адрес и молча отдаёт ошибку. Клиент видит «Спасибо за заказ», менеджер не видит ничего. Или статус «Оплачен» в CRM перестаёт соответствовать статусу «Ожидает оплаты» на сайте, и заказы зависают в середине воронки.

Поэтому первое, что стоит сделать, — выписать все точки, где сайт обменивается данными с внешними системами: CRM, склад, 1С, платежи, доставка, маркетплейсы. Дальше по каждой точке зафиксировать, что именно передаётся: товары, остатки, цены, заказы, статусы, клиенты.

Что зафиксировать до переключения домена: чек-лист

  • Полный список интеграций с указанием, кто отвечает за каждую и по какому протоколу она работает.
  • Карта статусов заказа: как они называются на сайте, как в CRM, какие переходы автоматические, а какие ставит менеджер.
  • Схема сопоставления товаров: по артикулу, по ID или по названию. Если по названию — это слабое место, которое лучше закрыть до переезда.
  • Правила распределения заказов между менеджерами и сценарии воронки: автозадачи, напоминания, триггерные письма.
  • Источники трафика и разметка ссылок: UTM-метки, подменные номера для коллтрекинга, цели в аналитике.
  • Тестовый доступ к обеим системам и тестовый товар, на котором безопасно прогонять заказы.

Этот список становится техзаданием. Без него подрядчик переносит то, что видит на экране, и пропускает то, что работает в фоне.

Три сценария переезда и их риски для заказов

Сценарий Когда подходит Главный риск Что сделать заранее
Полный переезд за одну ночь Небольшой каталог, простая логика заказов, низкий сезон Ошибку замечают только утром, часть заказов уходит в никуда Прогнать 10–15 тестовых заказов на копии, держать старый сайт в резерве на неделю
Поэтапный перенос: товары → заказы → трафик Магазин с интеграциями и историей заказов Дольше по времени, часть данных живёт в двух системах Назначить дату, когда отключается каждая старая связка
Параллельная работа на тестовом поддомене Есть трафик из поиска и реклама, которую нельзя останавливать Расползание данных и путаница с остатками Разделить потоки заказов и чётко решить, какой сайт главный

Для интернет-магазина с маркетплейсами и офлайном поэтапный вариант обычно спокойнее: сначала переносят каталог, потом включают приём заказов, и только затем переводят трафик. Если вы ещё выбираете платформу, посмотрите разбор о том, как выбрать CMS для интернет-магазина в Беларуси в 2026 году — часть критериев там напрямую касается интеграций с учётными системами.

Как сохранить историю заказов, клиентов и воронку

История заказов — это деньги, которые уже лежат в базе. Повторные продажи строятся на ней: менеджер видит, что клиент брал полгода назад, и предлагает похожее. Если при переезде история остаётся в старой системе, а новая начинается с нуля, вы теряете повод для звонка.

Решите до старта, что происходит со старыми заказами. Вариантов два: перенести их в новую систему вместе с клиентами или оставить в архиве и подключить к нему доступ из карточки клиента. Первый вариант чище, но требует нормализации данных: один и тот же человек мог оформить заказ с трёх номеров телефона и двух почт. Без приведения контактов к единому виду вы получите дубли и размытую статистику.

Отдельно проверьте, сохраняется ли источник заказа. Если после переезда UTM-метки и данные коллтрекинга перестают доходить до CRM, вы теряете связь между рекламным бюджетом и выручкой. Разбираться в этом лучше вместе с тем, кто настраивал аналитику, — вопрос из разряда тех, что решаются до переключения, а не после.

Сценарии воронки переносят вручную. Автозадачи, напоминания о брошенной корзине, письма после доставки — всё это живёт в правилах, которые не копируются автоматически. Пройдитесь по каждому сценарию и проверьте его на тестовом заказе. Как устроена сама воронка и что в ней стоит держать включённым, разобрано в материале о том, как выбрать CRM для интернет-магазина в 2026 году.

Что проверить в поиске после переключения

Переезд на новый движок сам по себе не обязан ронять позиции, если поисковик видит технический переход внутри одного сайта. Проблемы начинаются, когда одновременно меняют CMS, структуру адресов и контент. При неаккуратной подготовке теряется 30–50% органического трафика на 2–3 месяца, а часть позиций не восстанавливается без отдельной работы по ссылкам и контенту (гайд по миграции CMS, cropas.by).

Практический вывод простой: меняйте по одному параметру за раз. Адреса страниц оставьте прежними, где это возможно. Там, где без смены URL не обойтись, готовьте карту редиректов со старых адресов на новые и проверяйте её вручную, а не скриптом «на глаз». Обновите sitemap и robots.txt, проверьте canonical и убедитесь, что тестовый поддомен закрыт от индексации.

Отдельная история — товарные фиды для маркетплейсов и рекламных систем. Они собираются по адресам страниц и артикулам. После переезда ссылки в фиде могут вести на 404, и товары просто перестанут показываться. Как это устроено, описано в гайде про подготовку товарного фида интернет-магазина — проверку стоит поставить в план на первую неделю после запуска.

Типичные ошибки при переезде

  • Отключать старую CMS раньше, чем новый сайт прожил неделю с реальными заказами.
  • Переносить историю заказов без нормализации телефонов и адресов — на выходе получаются дубли клиентов.
  • Менять структуру URL одновременно со сменой движка.
  • Не делать тестовые заказы после каждого изменения настроек интеграции.
  • Забыть о ролях и правах доступа: менеджеры видят чужие заказы или не видят своих.
  • Оставлять в резервной копии только базу товаров, без заказов и клиентов.

Сколько времени закладывать на переезд

Для каталога на несколько сотен позиций и одной CRM реально уложиться в две-три недели, если интеграции описаны заранее. Магазин с несколькими каналами продаж, 1С и маркетплейсами стоит планировать на месяц и больше. Само переключение занимает ночь, а вот проверки и правки тянутся ещё неделю-две — их лучше сразу заложить в план, а не выпрашивать у подрядчика сверхурочно.

3 шага, которые можно сделать на этой неделе:

  1. Выпишите все интеграции магазина и отметьте, кто отвечает за каждую.
  2. Прогоните три тестовых заказа на копии нового сайта и сравните, что дошло до CRM, а что нет.
  3. Составьте карту редиректов для страниц, у которых изменится адрес.