Миграция интернет-магазина на Битрикс: сравнение вариантов

Переезд интернет-магазина на 1С-Битрикс редко сводится к копированию файлов и базы. Если перенести только каталог, можно потерять URL, историю заказов, остатки, поисковый трафик и обмен с 1С. Ниже — три рабочих сценария миграции, их цена и критерии выбора. Материал ориентирован на 1С-Битрикс: Управление сайтом 24.x; перед началом проекта сверяйте процедуру с документацией вашей редакции и текущего релиза.

Сначала зафиксируйте, что именно переезжает

Миграция — это перенос сайта, данных и рабочих процессов на новую площадку или в новую конфигурацию. У магазина данные связаны между собой: товар может иметь торговые предложения, заказ — пользователя и способ доставки, а URL — SEO-настройки и переадресации.

До выбора подхода составьте инвентаризацию. В неё должны попасть:

• каталог товаров, разделы, свойства, торговые предложения, изображения и документы;
• остатки, цены, типы цен, скидки, купоны и правила доступности товара;
• пользователи, группы, адреса, история заказов и статусы оплат;
• URL карточек и разделов, метатеги, файлы robots.txt и sitemap.xml;
• обмен с 1С, CRM, платёжными системами, службами доставки, маркетплейсами и аналитикой;
• локальные доработки: компоненты, обработчики событий, агенты, cron-задачи и шаблон;
• серверные настройки, сертификат, домены, почта, резервное копирование и мониторинг.

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

Самый дешёвый способ миграции — не тот, где меньше часов разработки. Это тот, где после переключения не приходится вручную восстанавливать заказы, URL и интеграции.

Три сценария миграции

Перенос текущей системы

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

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

Главная ловушка — копия быстро становится «живой» системой. Если на тестовом сервере оставить отправку писем, обмен с 1С или платёжный шлюз, покупатель может получить дубликат уведомления, а склад — повторную выгрузку заказа. До проверки интеграций используйте тестовые контуры и блокируйте боевые фоновые задания.

Чистая сборка

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

Это не «быстрый импорт товаров». Нужно заранее определить соответствия: какой старый раздел станет новым, куда попадёт свойство товара, как связать SKU с торговым предложением, какие статусы заказа сохранять и каким будет новый URL. Для пользователей важнее всего корректно перенести идентификаторы или выполнить продуманное сопоставление учётных записей. Иначе один человек получит два профиля и потеряет историю заказов.

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

Поэтапная миграция

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

Ключевой вопрос — где находится источник истины¹. Если остатки меняются в 1С, новый и старый сайт должны получать данные из одного источника. Если заказы некоторое время принимают обе системы, нужен механизм, который не создаёт конфликтов номеров, оплат и резервов.

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

Что проверить в данных Битрикс

Каталог и торговые предложения

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

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

Заказы, пользователи и оплаты

История заказов важна не только для отчётности. Она нужна менеджерам, поддержке и покупателю в личном кабинете. При переносе проверьте владельца заказа, состав, цену на момент покупки, скидку, доставку, оплату, статус и внешний идентификатор в CRM или 1С.

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

URL и SEO

Если адреса меняются, составьте карту старый URL — новый URL. Для каждого важного адреса проверьте ответ сервера, отсутствие цепочки переадресаций, канонический адрес и попадание страницы в sitemap.xml. Не ограничивайтесь главной страницей: коммерческий трафик часто приходит на карточки товаров и разделы, которые не видны в меню.

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

План работ без привязки к конкретному инструменту

1. Зафиксируйте целевую конфигурацию. Запишите релиз Битрикс, редакцию, версию PHP, базу данных, веб-сервер, домен и требуемые расширения. Проверка: у команды есть один документ, по которому можно собрать чистую тестовую среду.
2. Сделайте резервную копию и тестовый перенос. Копия должна восстанавливаться на отдельном сервере, а не просто лежать архивом. Проверка: из резервной копии открывается сайт, админка и тестовый заказ.
3. Соберите карту данных. Сопоставьте разделы, свойства, торговые предложения, пользователей, статусы и внешние идентификаторы. Проверка: для контрольного набора объектов понятно, куда попадёт каждое поле.
4. Подготовьте тестовые интеграции. Отдельно проверьте 1С, оплату, доставку, CRM, почту и фоновые задания. Проверка: тестовый заказ проходит путь от оформления до подтверждения без боевого платежа и повторной отправки.
5. Проведите репетицию запуска. Засеките продолжительность копирования данных, финальной синхронизации и переключения DNS или веб-сервера. Проверка: команда знает время простоя и последовательность отката.
6. Переключите магазин и наблюдайте. После запуска проверьте оформление заказа, оплату, остатки, письма, личный кабинет, поиск и ключевые URL. Проверка: контрольный заказ виден в админке и во всех системах, которые должны его получить.

Типичные ошибки и что с ними делать

• Дубли товаров. Обычно причина в импорте без устойчивого внешнего идентификатора. Остановите повторную загрузку, сопоставьте записи и только после этого запускайте обновление цен и остатков.
• Пропали варианты товара. Проверьте связь товара с торговыми предложениями, свойства предложений и правила импорта. Нельзя исправлять проблему массовым созданием новых товаров до выяснения причины.
• Заказы не ушли в 1С или CRM. Сверьте очередь обмена, статусы и внешний идентификатор заказа. Повторную отправку выполняйте после проверки, что принимающая система не создаст дубль.
• После запуска страницы отдают 404. Сравните карту URL, правила веб-сервера и настройки ЧПУ. Сначала восстановите самые посещаемые адреса и карточки, затем обработайте длинный хвост.
• Письма не доходят. Проверьте отправителя, DNS-записи домена, настройки почтового сервера и журнал отправки. Не пытайтесь диагностировать доставку только по интерфейсу заказа.

Когда какой вариант выбирать

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

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

Что делать после выбора

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

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

¹ Источник истины — система, чьи данные считаются правильными при конфликте. Например, остаток может быть главным в 1С, а описание товара — в Битрикс.