Перенос интернет-магазина на другую CMS: как не потерять заказы и клиентов

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

Если эти процессы не согласовать, после запуска можно обнаружить, что:

• часть заказов осталась в старой системе,
• некоторые товары показывают неправильное наличие,
• а постоянные покупатели не могут войти в личный кабинет.

Для владельца магазина главный вопрос заключается в том, как перейти на другую платформу, сохранив возможность обслуживать покупателей.

Разберём, где возникают наиболее опасные сбои и что должно быть предусмотрено в проекте миграции.

Почему перенос каталога ещё не означает перенос магазина

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

Компания решает сменить CMS, потому что существующая платформа ограничивает развитие каталога.

Разработчик переносит товары, изображения и категории.

На новой версии всё выглядит правильно:

• карточки открываются,
• поиск работает,
• покупатель может добавить товар в корзину.

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

Технически каталог перенесён. Для бизнеса часть его полезных возможностей утрачена.

Подобные сложности возникают из-за того, что разные CMS используют разные модели хранения данных. Одна система хранит комплектации как варианты товара, другая — как самостоятельные позиции. Скидки могут рассчитываться по правилам, которые новая платформа не поддерживает без доработки.

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

Куда исчезают заказы во время переключения

Одна из наиболее опасных ситуаций возникает между копированием базы данных и запуском нового сайта.

Допустим, в понедельник разработчики выгрузили заказы и клиентов из старой CMS. Во вторник завершили проверку новой версии, а в среду переключили магазин.

Но всё это время старый сайт продолжал работать. Покупатели оформляли новые заказы, оплачивали покупки, менеджеры меняли статусы, а склад корректировал остатки.

Если данные перенесли только в понедельник, всё, что произошло позднее, может отсутствовать в новой системе.

В результате заказ действительно существует, покупатель получил подтверждение и, возможно, даже оплатил покупку. Но сотрудники, работающие уже в новой CMS, его не видят.

Это не означает, что любая миграция требует остановить продажи.

Возможны разные способы организации переключения:

• временно ограничить оформление новых заказов,
• синхронизировать изменения,
• или перенести накопившиеся операции непосредственно перед запуском.

Выбор зависит от архитектуры магазина и того, насколько тесно сайт связан с CRM, учётной системой и платёжными сервисами.

Главная опасность миграции действующего интернет-магазина — расхождение данных между старой и новой системами. Новый сайт может работать исправно, но не содержать заказы, оплаты и изменения остатков, произошедшие непосредственно перед запуском.

Что происходит с уже оформленными заказами

История заказов — это рабочая информация, которая может понадобиться спустя месяцы после покупки.

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

Однако перенос истории сложнее обычного копирования записей.

В разных системах могут отличаться статусы заказов, идентификаторы товаров, способы хранения скидок, платежей и доставки. Например, в старой CMS предусмотрен статус «Ожидает комплектации», а в новой такого статуса нет.

Если просто заменить его на «В обработке», магазин может потерять важную информацию для сотрудников склада.

Кроме того, стоимость исторического заказа должна оставаться той, которая действовала в момент покупки. Если после миграции система пересчитывает старые заказы по актуальному прайс-листу, возникают расхождения с документами и платежами.

Не всегда требуется переносить всю историю непосредственно в новую CMS. В зависимости от задач бизнеса иногда разумнее оставить старые заказы в доступном архиве или учётной системе. Но это решение должно быть осознанным.

Особенно внимательно следует относиться к частично оплаченным заказам, возвратам, предзаказам и товарам, которые ещё не отгружены. По ним операции могут продолжаться после переключения платформы.

Личные кабинеты и постоянные покупатели

После смены CMS магазин может столкнуться с ситуацией, когда существующие клиенты больше не могут авторизоваться.

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

Возможным решением становится восстановление пароля, совместимый механизм проверки или иной безопасный способ переноса авторизации.

Владелец магазина должен заранее понимать, потребуется ли покупателям повторно входить в систему, сохранятся ли их адреса доставки, избранные товары, персональные цены и история покупок.

Для B2B-магазинов ситуация ещё сложнее. Личный кабинет может содержать несколько сотрудников одной организации, разные права доступа, договорные цены, лимиты и условия оплаты.

Если после переноса эти правила перестают работать, магазин фактически меняет условия обслуживания клиентов, даже если никто не планировал этого делать.

Поэтому перенос покупателей оценивают отдельно от переноса товаров. Сохранение списка клиентов ещё не означает сохранения их возможностей.

Что может пойти не так с оплатой и доставкой

Платёжный модуль, подключённый к новой CMS, может выглядеть и работать иначе, чем на прежнем сайте.

Особое внимание требуется платежам, которые проходят в несколько этапов. Например, покупатель оформил заказ до миграции, а подтверждение платежа от банка поступило уже после переключения.

Если уведомление отправляется в старую систему, новая CMS может не получить сведения об успешной оплате.

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

С доставкой возможны другие расхождения. Новая CMS может иначе рассчитывать стоимость, обрабатывать адреса, передавать габариты или формировать отправления в службе доставки.

Особенно неприятны ошибки, которые не мешают покупателю завершить оформление. Заказ принимается, но сотрудники обнаруживают неправильную стоимость доставки или неполные сведения о получателе только при обработке.

Проверка оплаты и доставки должна охватывать реальные сценарии работы магазина, включая отмены и нестандартные состояния заказов.

Интеграции с CRM и 1С могут потребовать переработки

При смене CMS зачастую сохраняется тот же набор внешних систем: CRM, 1С, складской учёт, платёжный сервис и доставка.

Это не означает, что прежние интеграции автоматически продолжат работать.

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

Например, учётная система отправляет остатки по артикулу, а новая CMS ожидает идентификатор варианта товара. Если сопоставление сделано неправильно, информация может обновляться не у той позиции.

В другом случае сайт отправляет заказ в CRM, но не передаёт выбранную комплектацию или комментарий покупателя.

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

В сложных проектах интеграции становятся одной из самых значимых частей бюджета миграции. Особенно если прежний обмен был реализован индивидуально и не имеет полноценной документации.

Нужно ли останавливать магазин на время переноса

Полностью исключить любые риски при переключении нельзя, но не всякая миграция требует длительного простоя.

Если магазин небольшой и принимает ограниченное число заказов, иногда достаточно согласованного короткого периода, в течение которого новые покупки временно недоступны.

Для магазина с постоянным потоком заказов такая остановка может оказаться дорогой. Тогда рассматривают варианты синхронизации изменений, контролируемого переключения и обработки операций, начатых в прежней системе.

Сложность зависит от количества одновременно работающих систем и от того, где хранятся основные данные.

Если CRM или ERP является главным источником информации о заказах и товарах, перенос может быть организован иначе, чем в магазине, где все операции и история существуют только в базе старой CMS.

Но и здесь нельзя заранее обещать переход без единой потерянной минуты. Надёжный сценарий определяется после изучения действующей архитектуры.

Какие данные нельзя проверять выборочно

Приёмка перенесённого интернет-магазина не должна ограничиваться открытием главной страницы, просмотром нескольких карточек товаров и одним тестовым заказом.

Для бизнеса принципиально важно проверить соответствие данных и восстановление ключевых операций.

Особенно важны неочевидные сценарии: заказ с несколькими вариантами товара, частичная оплата, покупка по персональной цене, возврат, отсутствие товара на складе.

Именно такие случаи помогают обнаружить ошибки, которые не проявляются при обычном оформлении простого заказа.

Магазин готов к запуску тогда, когда подтверждена работа его основных торговых процессов. Совпадение количества товаров и внешнего вида страниц недостаточно для приёмки миграции.

А что с поисковыми позициями?

Переход на другую CMS может затронуть URL товаров и категорий, структуру каталога, метаданные и индексацию. Поэтому SEO необходимо учитывать при планировании проекта.

Но это отдельная большая задача, которую мы уже подробно рассмотрели в статье «Редизайн сайта без потери SEO». Описанные там принципы сохранения поисковой видимости применимы и к миграции интернет-магазина.

Здесь же главный риск другой: даже магазин, сохранивший органический трафик, может терять деньги из-за неправильно перенесённых заказов, цен и интеграций.

Как оценить результат переноса

Успешная миграция означает, что компания получила новую платформу и сохранила возможность обслуживать покупателей.

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

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

Дальнейшую стабильность можно обеспечивать в рамках технической поддержки сайта, если она включает обслуживание соответствующих компонентов и интеграций.

Смена CMS оправданна, когда новая платформа решает конкретные ограничения прежней системы. Но оценивать проект необходимо по тому, насколько сохранилась работа магазина: от доступности каталога до корректного завершения оплаченного заказа.

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