Миграция сайта с Magento на 1С-Битрикс: полный перенос данных

Миграция сайта с Magento на Битрикс: где теряются данные

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

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

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

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

Что перестаёт ломаться после переноса каталога и заказов

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

Сохранение истории заказов — вторая точка отказа. Заказ хранит не только статус и сумму, но и состав с привязкой к конкретному предложению на момент покупки. Если связь не восстановить, в личном кабинете клиент видит пустые строки, а повторный заказ по истории не собирается. Мы переносим заказы со статусами и позициями, а для снятых с продажи товаров сохраняем архивные записи — история остаётся читаемой.

Выгрузка заказов в учётную систему перестаёт быть ручной. Обмен идёт по расписанию через сопоставление номенклатуры по внешним ключам: заказы уходят в учёт, статусы и остатки возвращаются обратно, повторная отправка не создаёт дублей. На стороне 1С-Битрикс это делается штатными средствами обмена, без самописных посредников, которые отваливаются при первом же обновлении.

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

Способы переноса каталога и заказов: сравнение подходов

Каталог и заказы переносятся с разной ценой ошибки. Товары, свойства и привязку к разделам можно пересобрать повторно, а историю заказов — нет: статусы оплат, состав корзины и связь с покупателем восстанавливаются только из выгрузки. Поэтому способ выбирают по двум осям — допустимое время простоя продаж и объём доработок, накопившихся на стороне Magento.

Четыре рабочих сценария

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

Порядок работ: от аудита структуры до передачи доступов

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

1. Инвентаризация данных. Выгружаем каталог, заказы, клиентов, контент и файлы, сверяем количество записей по каждому типу: расхождение даже в паре позиций сигналит о потерях на выгрузке.
2. Проектирование схемы связей. Описываем, какая сущность приёмника соответствует исходной, как переносятся множественные привязки, торговые предложения и старые адреса. Схема переноса данных согласуется до работ — правка на этом этапе дешевле переделки после запуска.
3. Настройка переноса и обмена с учётной системой. Сопоставляем ключи товаров и контрагентов, задаём периодичность и правила приоритета, чтобы остатки и заказы не задваивались при синхронизации.
4. Контрольная сверка после переноса. Сравниваем не только объёмы, но и контрольные суммы по позициям, привязку изображений, корректность адресов и редиректов со старых страниц.
5. Прогон сценариев на закрытом контуре. Проходим поиск, фильтры, оформление заказа и личный кабинет, фиксируем отклонения до открытия публичного доступа.
6. Передача доступов и документации. Отдаём карту соответствий, регламенты обмена, инструкции по выгрузке и список учётных записей с разграничением ролей — поддержка дальше работает без нас.

Что заказчик получает после завершения переноса

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

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

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

Кейс: перенос магазина с сохранением позиций в поиске

Магазин на Magento с 4 300 позициями и 620 разделами каталога жил с ночной выгрузкой остатков и частью страниц-дублей. Владелец хотел кейс переноса магазина без потери накопленной поисковой истории — за годы работы каталог собрал позиции по 2 800 запросам.

Что сделали

Работу разбили на четыре прохода: схема разделов и карта адресов, затем перенос ассортимента, следом атрибуты и цены, последними — заказы и история клиентов. Старые адреса вместе с параметрами фильтров завели в таблицу соответствий на 3 400 правил и сверили её с выгрузкой из системы аналитики. Сроки переноса каталога — три недели, ещё неделя ушла на сверку и правку 118 расхождений по характеристикам. Старый контур до подтверждения сверки работал в режиме чтения, чтобы откат занял часы.

Результат в цифрах

Страниц с ошибками разметки стало 1,4% против 18% до переезда, дубли закрыты. Обработка заказа в админке сократилась с 40 до 9 секунд, обновление остатков идёт каждые 15 минут вместо ночного прогона. Переезд без просадки трафика подтвердился: 94% адресов сохранили позиции в топ-10, к исходным показателям магазин вернулся за две недели после переключения. Ассортимент перенесён полностью — сверка по штрихкодам не выявила потерь ни по одной позиции.

Что делать, если часть каталога уже перенесена на Битрикс

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

Сначала фиксируется ключ сопоставления. Название и адрес страницы для этого не годятся — их меняют при редизайне и чистке текстов. Устойчивый признак — артикул вместе с внешним кодом записи из старого движка; его сохраняют отдельным свойством карточки, даже если оно нигде не выводится на сайте. Тогда доперенос данных идёт в режиме обновления по ключу: существующие позиции наполняются, новые добавляются, дубликаты не возникают.

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

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

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

Частые технические сомнения перед стартом переноса

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

Как переносятся данные покупателей и их заказы?

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

Можно ли переносить каталог по частям?

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

Как быть с характеристиками и торговыми предложениями?

Разбираем структуру свойств заранее: что станет характеристикой товара, а что — отдельным предложением с собственной ценой и остатком. Множественные значения, единицы измерения и фильтры переносим вместе с данными, иначе умный фильтр на новом сайте начнёт показывать пустые результаты. Отдельно сверяем связки «товар — предложение», потому что именно на них чаще всего расходятся каталоги.

Как будет идти обмен с учётной системой после переноса?

На 1С-Битрикс обмен настраиваем штатными средствами: определяем, что становится источником истины по ценам, остаткам и заказам, ставим расписание выгрузок и журналируем расхождения. Тестовый прогон обмена делаем до открытия сайта — на нём видно, какие группы товаров выпадают и как ведёт себя учётная система под нагрузкой.

Обсудим задачу переноса вашего магазина

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

От заказчика для оценки обычно достаточно такого набора:

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

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