Перенос заказов в Bitrix: импорт JSON с маппингом

Для корректного переноса данных заказов с старого сайта на новый Bitrix, где изменились инфоблоки и добавлены свойства, начните с миграции данных пользователей по email — это ключевой маппинг, чтобы избежать дублей и сохранить привязки. Экспортированный JSON трансформируйте скриптом: создайте таблицу соответствий старых/новых ID, обновите свойства заказов (статусы, суммы, позиции, оплату) и импортируйте поэтапно через CIBlockElement::Add или модули вроде protobyte.dump. Тестируйте на копии базы, чтобы не сломать продакшн.

Содержание

• Подготовка к миграции данных в Bitrix
• Маппинг пользователей по email и ID
• Трансформация JSON перед импортом
• Алгоритм импорта заказов в новые инфоблоки
• Готовые модули и инструменты для битрикс импорт
• Тестирование миграции и откат изменений
• Типичные проблемы при переносе баз данных
• Источники
• Заключение

Подготовка к миграции данных в Bitrix

Сначала разберитесь, почему простой дамп базы не сработает. На новом сайте инфоблоки заказов (обычно sale_order или кастомный) перестроены: добавлены свойства вроде новых полей оплаты или доставки, изменились ID разделов. Ваш JSON-экспорт — отличная база, но без доработки он развалит связи.

Почему email? Потому что это уникальный идентификатор, который редко меняется. Пользователи из старого сайта импортируются первыми: проверяем, есть ли такой email на новом — если да, фиксируем новый ID; если нет — создаем. Потом заказы подставляем под эти ID.

Из официальной документации Bitrix ясно: при импорте ID элементов меняются, поэтому маппинг по внешним кодам (XML_ID) или email обязателен. Для заказов еще важны позиции корзины (sale_basket) и свойства (sale_order_props).

Шаг 1: Сделайте полную копию новой БД. Шаг 2: Загрузите JSON в отдельную таблицу (через phpMyAdmin или скрипт). Шаг 3: Создайте временную таблицу маппинга:

CREATE TABLE temp_user_mapping (
 old_id INT,
 old_email VARCHAR(255),
 new_id INT
);

Это основа. Без нее заказы привяжутся к несуществующим пользователям — и привет, orphaned records.

Маппинг пользователей по email и ID

Вот где зарыта собака. Ваш скрипт экспортировал пользователей и заказы, но ID сломались. Рекомендую алгоритм из форума разработчиков Bitrix: сначала импортируем пользователей, потом маппим заказы.

Пошагово:

1. Импорт пользователей из JSON. Парсим массив users. Для каждого:

• Ищем по email: $user = CUser::GetList([], ['=EMAIL' => $old_email]);
• Если найден — запоминаем new_id.
• Если нет — CUser::Add($user_data) с хэшированием пароля (сохраните старые хэши!).
• Записываем в temp_user_mapping: old_id => new_id.

2. Проверка дублей. Перед добавлением: if (CUser::GetList([], ['=EMAIL' => $email])->Fetch()) { skip; } — никаких дублей.

3. Для заказов: В JSON заказов заменяем user_id на new_id из маппинга.

Псевдокод на PHP (Bitrix-style):

$mapping = []; // загружаем из temp_user_mapping
foreach ($orders as $order) {
 if (isset($mapping[$order['USER_ID']])) {
 $order['USER_ID'] = $mapping[$order['USER_ID']];
 } else {
 // Создать гостя или пропустить
 $order['USER_ID'] = 0;
 }
 // Трансформировать свойства...
}

Это сохранит статусы, даты, суммы. А что с позициями? Их тоже маппьте по товарам: используйте XML_ID товаров, чтобы ссылки не сломались.

В Habr Q&A такой подход хвалят: сначала пользователи, потом UPDATE заказов по новому USER_ID.

Но подумайте: а если email изменился? Добавьте fallback по LOGIN или телефону.

Трансформация JSON перед импортом

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

Примерный алгоритм трансформации:

1. Парсинг: $data = json_decode(file_get_contents('export.json'), true);

2. Маппинг свойств. Старые свойства → новые. Создайте конфиг:

$propertyMap = [
 'old_status' => 'PROPERTY_NEW_STATUS',
 'old_delivery' => 'PROPERTY_DELIVERY_TYPE',
 // Новые свойства — дефолтные значения
 'PROPERTY_NEW_FIELD' => 'default_value'
];

3. Обработка позиций и связей. Для sale_basket: мапьте PRODUCT_ID по XML_ID (импортируйте товары заранее!).

4. Генерация XML_ID для заказов: $order['external_id'] = 'ORDER_' . $old_id; — чтобы избежать дублей при повторном импорте.

Полный псевдокод:

function transformOrder($oldOrder, $mapping) {
 $newOrder = [
 'IBLOCK_ID' => NEW_ORDER_IBLOCK_ID,
 'NAME' => 'Заказ #' . $oldOrder['ID'],
 'DATE_CREATE' => $oldOrder['DATE_INSERT'],
 'PROPERTY_VALUES' => [],
 'USER_ID' => $mapping[$oldOrder['USER_ID']] ?? 0
 ];
 
 // Маппинг свойств
 foreach ($propertyMap as $old => $new) {
 $newOrder['PROPERTY_VALUES'][$new] = $oldOrder[$old] ?? '';
 }
 
 // Позиции: отдельный массив для basket
 $newOrder['BASKET'] = transformBasket($oldOrder['basket']);
 
 return $newOrder;
}

Сохраните как новый JSON. Из protobyte блога: для новых свойств — ручная правка JSON перед загрузкой в модуль.

А если заказов тысячи? Делайте батчами по 100-500, чтобы не упасть под лимит памяти.

Алгоритм импорта заказов в новые инфоблоки

Теперь импорт. Не используйте встроенный CSV-мастер — он для товаров, для заказов нужен API.

Основной способ: CIBlockElement::Add с SetPropertyValuesEx.

foreach ($transformedOrders as $order) {
 $el = new CIBlockElement;
 $id = $el->Add($order);
 if ($id) {
 // Свойства
 CIBlockElement::SetPropertyValuesEx($id, $iblockId, $order['PROPERTY_VALUES']);
 // Корзина: отдельно через CSaleBasket::Add
 }
}

Для sale_order — используйте CSaleOrder::Add, но если кастом инфоблок — то элементы.

Из документации по импорту: настройте маппинг полей в мастере, но для JSON — скрипт.

Порядок: товары → пользователи → заказы → свойства → корзина.

Суммы пересчитайте, если цены изменились.

Готовые модули и инструменты для битрикс импорт

Не хотите скриптить? Берите готовое.

1. protobyte.dump — топ для переноса баз данных. Экспорт архива с заказами/пользователями, импорт с маппингом по email. Для новых свойств — доработайте JSON вручную. Цена ~5000р, но окупается.

2. Встроенный импорт: Магазин > Настройки > Импорт CSV/XML. Но для заказов — кастом.

3. Bitrix24 импорт — если мигрируете в B24, CSV с реквизитами по email.

4. Flyps или 1C-Exchange — для полной синхронизации.

Установите модуль, протестируйте на dev-сервере. Почему protobyte? Он маппит пароли, избежит дублей.

Тестирование миграции и откат изменений

Тестируйте на копии!

1. Стадия 1: Импорт 10 заказов, проверка связей: SELECT o.ID, u.EMAIL FROM b_sale_order o JOIN b_user u ON o.USER_ID = u.ID;

2. Стадия 2: Полный импорт на staging, сравните суммы/статусы.

3. Откат: Бэкап перед импортом + транзакции: BeginTransaction(); ... Commit();

Мониторьте логи: Bitrix\Main\Diag\StackTrace.

Проблемы? Роллбэк по XML_ID: удалите все с префиксом ‘TEST_’.

В Habr: всегда на копии БД.

Типичные проблемы при переносе баз данных

Вот подводные камни:

• Ссылки на товары: Старые PRODUCT_ID не существуют. Решение: маппинг по XML_ID.
• Новые свойства: Обязательные — заполните дефолтами, иначе Add() упадет.
• Цены/валюты: Если изменились курсы — пересчитайте.
• Даты/временные зоны: Формат ‘YYYY-MM-DD HH:MM:SS’.
• Гостевые заказы: USER_ID=0 — проверьте.
• Дубли по XML_ID: Удалите перед импортом.

Из форума: не дампьте таблицы напрямую — различия в схемах убьют.

А если JSON большой? Разбейте на чанки.

Источники

1. Официальная документация Bitrix: Импорт данных
2. Экспорт и импорт каталога
3. Форум: Перенос заказов
4. Habr Q&A: Перенос заказов
5. Protobyte: Перенос пользователей и заказов
6. Bitrix24: Импорт CRM
7. Marketplace: protobyte.dump

Заключение

Миграция данных заказов в Bitrix с измененными инфоблоками — это не хаос, если следовать маппингу по email, трансформации JSON и поэтапному импорту битрикс. Используйте protobyte.dump для скорости или скрипт для точности — главное, тестируйте на копии и фиксируйте XML_ID. В итоге связи заказ-пользователь сохранятся, дублей не будет, а бизнес не встанет. Если JSON-файлы большие, начните с 100 записей — и вперед, без риска.