Как перенести интернет-магазин на новую 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 шага, которые можно сделать на этой неделе:
- Выпишите все интеграции магазина и отметьте, кто отвечает за каждую.
- Прогоните три тестовых заказа на копии нового сайта и сравните, что дошло до CRM, а что нет.
- Составьте карту редиректов для страниц, у которых изменится адрес.


