Міграція сайту з Magento на Бітрікс: де втрачаються дані
Перенесення сайту з Magento на Бітрікс — не копіювання бази та файлів, а перезбирання зв’язків між сутностями.
У Magento товар, його варіанти та значення властивостей — різні таблиці, пов’язані за ідентифікаторами; у Бітрікс та сама структура збирається з елементів інфоблоку, торгових пропозицій і властивостей.
Поки відповідність не описана на рівні схеми, перенесення інтернет-магазину проходить формально успішно й розсипається вже на живому трафіку.
Першою зникає адреса. Каталог Magento віддає зрозумілі людині шляхи, фільтри та пагінацію окремими сторінками, бренд-лендінги живуть в інших розділах.
Без карти переходів, побудованої до перемикання, картка отримує нову адресу, а стара віддає помилку — це і є некоректні адреси сторінок після перенесення: з індексу випадають категорії, зовнішні посилання та оголошення ведуть у нікуди.
Далі — помилки перенесення каталогу. Характеристики на кшталт кольору чи розміру переїжджають текстом без прив’язки до довідників: фільтри перестають будуватися, порівняння показує порожні поля.
Множинні прив’язки товару до розділів згортаються до однієї, і частина посадкових сторінок зникає. Окремо розходяться залишки по складах та історія замовлень: позиції посилаються на неіснуючі товари, покупець бачить замовлення без складу.
Втрата даних під час міграції майже завжди означає, що перенесення почали з товарів, а не з моделі даних. Розбираємо, як це закривається: спочатку схема відповідності, потім каталог, замовлення та адреси, і лише після звірки — перемикання домену.
Що перестає ламатися після перенесення каталогу та замовлень
Перенесення каталогу товарів ламається не на обсязі, а на зв’язках.
Товар, його торгові пропозиції та значення характеристик — три набори даних, пов’язаних за ідентифікаторами; під час прямого переливання «в лоб» пропозиції втрачають прив’язку до батьківського товару, а фільтри в каталозі починають показувати порожні значення.
Тому порядок жорсткий: спочатку довідники характеристик, потім товари, далі торгові пропозиції — з перевіркою цілісності на кожному кроці.
Збереження історії замовлень — друга точка відмови. Замовлення зберігає не лише статус і суму, а й склад із прив’язкою до конкретної пропозиції на момент покупки.
Якщо зв’язок не відновити, в особистому кабінеті клієнт бачить порожні рядки, а повторне замовлення за історією не збирається. Ми переносимо замовлення зі статусами та позиціями, а для знятих з продажу товарів зберігаємо архівні записи — історія залишається читабельною.
Вивантаження замовлень в облікову систему перестає бути ручним. Обмін іде за розкладом через зіставлення номенклатури за зовнішніми ключами: замовлення вирушають в облік, статуси та залишки повертаються назад, повторне надсилання не створює дублів.
На боці 1С-Бітрікс це робиться штатними засобами обміну, без саморобних посередників, які відвалюються вже при першому оновленні.
Підсумок перевіряється на прийманні: частка позицій із повними характеристиками, кількість замовлень, що втратили зв’язок зі складом, обсяг ручних правок у перші тижні. Ці показники — критерій того, що перенесення каталогу та замовлень доведено до кінця, а не «в основному».
Способи перенесення каталогу та замовлень: порівняння підходів
Каталог і замовлення переносяться з різною ціною помилки. Товари, властивості та прив’язку до розділів можна перезібрати повторно, а історію замовлень — ні: статуси оплат, склад кошика та зв’язок із покупцем відновлюються лише з вивантаження.
Тому спосіб обирають за двома осями — допустимий час простою продажів та обсяг доопрацювань, накопичених на боці Magento.
Чотири робочі сценарії
| Спосіб | Коли підходить | Обмеження |
|---|---|---|
| Повне вивантаження бази із зупинкою | Каталог на кілька тисяч позицій, вікно простою узгоджене з бізнесом | Сайт закритий на весь час перенесення, замовлення з вікна губляться, повторний запуск починається з нуля |
| Поетапне перенесення за розділами | Великий каталог, потрібна перевірка кожного розділу перед викладкою | Довше за календарем, потрібно ловити правки, які продовжують вносити в старий каталог |
| Паралельна робота двох сайтів | Зупиняти продажі не можна, є обмін залишками з 1С | Два джерела правди щодо залишків і цін — потрібні правила зіставлення, дорожче в підтримці |
| Ручне складання каталогу заново | Каталог невеликий і засмічений, потрібна ревізія асортименту | Замовлення та покупці все одно переносяться вивантаженням, накопичені описи й перелінковка не зберігаються |
На практиці частіше беруть комбінацію: каталог їде за розділами з проміжною звіркою, замовлення та покупці — одним вивантаженням у коротке вікно, а трафік перемикається постійними перенаправленнями зі старих адрес. Розбираємо, з яких етапів це складається.
Порядок робіт: від аудиту структури до передачі доступів
Перенесення влаштоване як послідовність, де кожен наступний крок спирається на артефакт попереднього: якщо пропустити один, розбіжності у зв’язках спливають уже після запуску, коли каталог і замовлення починають жити окремо.
Починаємо з аудиту структури сайту — збираємо карту розділів, типів сторінок, атрибутів товарів і властивостей користувачів, окремо фіксуємо нестандартні доопрацювання. Паралельно знімаємо зріз реальних звернень до бази, щоб рахувати навантаження за фактом, а не за описом.
- Інвентаризація даних. Вивантажуємо каталог, замовлення, клієнтів, контент і файли, звіряємо кількість записів за кожним типом: розбіжність навіть у парі позицій сигналізує про втрати на вивантаженні.
- Проєктування схеми зв’язків. Описуємо, яка сутність приймача відповідає вихідній, як переносяться множинні прив’язки, торгові пропозиції та старі адреси. Схема перенесення даних узгоджується до робіт — правка на цьому етапі дешевша за переробку після запуску.
- Налаштування перенесення та обміну з обліковою системою. Зіставляємо ключі товарів і контрагентів, задаємо періодичність і правила пріоритету, щоб залишки та замовлення не дублювалися під час синхронізації.
- Контрольна звірка після перенесення. Порівнюємо не лише обсяги, а й контрольні суми за позиціями, прив’язку зображень, коректність адрес і редиректів зі старих сторінок.
- Прогін сценаріїв на закритому контурі. Проходимо пошук, фільтри, оформлення замовлення та особистий кабінет, фіксуємо відхилення до відкриття публічного доступу.
- Передача доступів і документації. Віддаємо карту відповідностей, регламенти обміну, інструкції з вивантаження та список облікових записів із розмежуванням ролей — підтримка далі працює без нас.
Що замовник отримує після завершення перенесення
Перенесення — це не лише дані, що переїхали в нову систему.
Після приймання у вашої команди залишається комплект, за яким сайт можна розвивати й обслуговувати власними силами: карта зв’язків каталогу, правила переадресації, налаштований обмін з обліковим контуром і регламенти роботи.
- Карта зв’язків каталогу — відповідність розділів, товарів, властивостей і медіа між старою та новою структурою: видно, звідки прийшла кожна позиція і що з нею сталося під час перенесення.
- Правила переадресації — таблиця старих і нових адрес із постійними переадресаціями, включно зі сторінками категорій і карток, щоб пошуковий трафік не просів після зміни платформи.
- Схема інтеграції з обліковою системою — які довідники, ціни, залишки та статуси замовлень синхронізуються, у який бік і з якою періодичністю, де дивитися журнал обміну в разі розбіжності.
- Права доступу адміністраторів — ролі з розмежуванням за розділами панелі керування: хто править каталог, хто ціни, хто замовлення, у кого доступ до налаштувань і вивантажень.
- Регламент резервного копіювання — що копіюється, як часто, скільки зберігається і в якому порядку виконується відновлення з перевіркою на тестовому контурі.
- Інструкція для контент-менеджера — покрокові сценарії: додати товар, розкласти зображення, опублікувати сторінку, оновити банер, не зламавши шаблон.
- Документація по сайту — склад модулів, ключові налаштування, точки інтеграції та журнал змін, щоб доопрацювання не починалися з вивчення чужого коду.
Передаємо пакет не «папкою на диску», а з прийманням: інженер проходить за кожним пунктом разом із вашою командою, показує налаштування в інтерфейсі та відповідає на запитання.
Через місяць після запуску звіряємо журнали обміну та індексацію — розбіжності розбираємо в межах гарантійних робіт.
Кейс: перенесення магазину зі збереженням позицій у пошуку
Магазин на Magento з 4 300 позиціями та 620 розділами каталогу жив із нічним вивантаженням залишків і частиною сторінок-дублів. Власник хотів кейс перенесення магазину без втрати накопиченої пошукової історії — за роки роботи каталог зібрав позиції за 2 800 запитами.
Що зробили
Роботу розбили на чотири проходи: схема розділів і карта адрес, потім перенесення асортименту, далі атрибути та ціни, останніми — замовлення й історія клієнтів.
Старі адреси разом із параметрами фільтрів завели в таблицю відповідностей на 3 400 правил і звірили її з вивантаженням із системи аналітики. Строки перенесення каталогу — три тижні, ще тиждень пішов на звірку та правку 118 розбіжностей за характеристиками. Старий контур до підтвердження звірки працював у режимі читання, щоб відкат зайняв години.
Результат у цифрах
Сторінок із помилками розмітки стало 1,4% проти 18% до переїзду, дублі закрито. Обробка замовлення в адмінці скоротилася з 40 до 9 секунд, оновлення залишків відбувається кожні 15 хвилин замість нічного прогону.
Переїзд без просідання трафіку підтвердився: 94% адрес зберегли позиції в топ-10, до вихідних показників магазин повернувся за два тижні після перемикання. Асортимент перенесено повністю — звірка за штрихкодами не виявила втрат за жодною позицією.
Що робити, якщо частину каталогу вже перенесено на Бітрікс
Якщо каталог переносили частинами або частину сторінок зверстали заново, дані в двох системах розходяться: один товар існує і в старій базі, і в новому каталозі, але з різними цінами, описами та адресою сторінки.
Повторне вивантаження в таких випадках не оновлює позицію, а створює другу картку — так з’являються дублі товарів у каталозі, втрачені адреси та ручна правка, обсяг якої зростає з кожним новим запуском.
Частково перенесений каталог небезпечний саме цим: він виглядає готовим, поки не почнеш його доповнювати.
Спочатку фіксується ключ зіставлення. Назва й адреса сторінки для цього не годяться — їх змінюють під час редизайну та чищення текстів.
Стійка ознака — артикул разом із зовнішнім кодом запису зі старого рушія; його зберігають окремою властивістю картки, навіть якщо вона ніде не виводиться на сайті.
Тоді доперенесення даних іде в режимі оновлення за ключем: наявні позиції наповнюються, нові додаються, дублікати не виникають.
Далі починається робота зі спадщиною старого рушія. Частину позицій там уже знято з продажу, частина адрес веде на видалені розділи, накопичено відгуки та зовнішні посилання.
Під це будується карта відповідностей: старий адресний рядок — новий, знятий товар — сторінка батьківського розділу або перенаправлення. Без карти перехідний період залишає биті посилання та просілий трафік за брендовими запитами.
Поки обидва магазини живі, синхронізація двох сайтів робиться односторонньою та за дельтою. Ціни, залишки та статуси наявності вивантажуються зі старої системи в нову за розкладом, а зміни редакторів ідуть лише в новий каталог.
Двосторонній обмін у цій ситуації майже завжди дає конфлікти версій і затирає ручну роботу контент-редакторів.
Перед вимкненням джерела роблять звірку: кількість позицій за розділами, вибіркове порівняння цін і властивостей, звіт за записами без пари. Обмін має бути повторюваним — другий запуск не змінює нічого, якщо дані не змінювалися.
Після звірки точка входу залишається одна: стара адреса йде в перенаправлення, а каталог живе в одному місці.
Часті технічні сумніви перед стартом перенесення
Сумніви перед перенесенням зазвичай стосуються не самого переїзду, а того, що ламається після ввімкнення нового сайту: адреси, вхід покупців, обмін з обліковою системою.
Нижче — інженерні відповіді на запитання, які найчастіше піднімають на етапі оцінки: що переносимо автоматично, де потрібна ручна звірка і як влаштовано відкат на старий майданчик, поки новий контур не підтвердив стабільність.
Що буде з адресами сторінок після перенесення?
Збираємо карту відповідності «стара адреса → нова» за всіма розділами, товарами та статтями, а не лише за верхнім рівнем.
На новому контурі налаштовуємо постійні перенаправлення, карту сайту та контроль помилок у журналі: перші тижні відстежуємо, які адреси ще запитують із зовнішніх джерел, і дописуємо правила. Так накопичений трафік переїжджає разом із каталогом, а не губиться на битих посиланнях.
Як переносяться дані покупців та їхні замовлення?
Профілі, адреси доставки, історію замовлень і прив’язку до знижкових груп переносимо повністю.
Паролі зберігаються в необоротному вигляді й перенесенню між платформами не підлягають — надсилаємо покупцям лист про зміну пароля, а на час переходу залишаємо м’який сценарій відновлення доступу. Замовлення та статуси зберігаємо з вихідними датами, щоб звітність не роз’їхалася.
Чи можна переносити каталог частинами?
Так, і на великих каталогах це надійніше. Розбиваємо перенесення за розділами або брендами, кожен блок проганяємо окремо: властивості, ціни, залишки, зображення. Поки частина ще в роботі, старий сайт продовжує обслуговувати покупців, а перемикання йде за готовими блоками. Так помилка в одному розділі не блокує запуск усього проєкту.
Як бути з характеристиками та торговими пропозиціями?
Розбираємо структуру властивостей заздалегідь: що стане характеристикою товару, а що — окремою пропозицією з власною ціною та залишком.
Множинні значення, одиниці виміру та фільтри переносимо разом із даними, інакше розумний фільтр на новому сайті почне показувати порожні результати. Окремо звіряємо зв’язки «товар — пропозиція», бо саме на них найчастіше розходяться каталоги.
Як буде йти обмін з обліковою системою після перенесення?
На 1С-Бітрікс обмін налаштовуємо штатними засобами: визначаємо, що стає джерелом істини щодо цін, залишків і замовлень, ставимо розклад вивантажень і журналюємо розбіжності.
Тестовий прогін обміну робимо до відкриття сайту — на ньому видно, які групи товарів випадають і як поводиться облікова система під навантаженням.
Обговоримо задачу перенесення вашого магазину
Щоб обговорити задачу перенесення предметно, нам потрібен доступ до реальної картини магазину, а не до переказу.
Копія бази, вивантаження каталогу та список розширень говорять про обсяг роботи точніше за будь-який опис: одразу видно, де логіка тримається на нестандартних доопрацюваннях, а де все вирішується штатними засобами.
Від замовника для оцінки зазвичай достатньо такого набору:
- Доступи до панелі керування та свіжа копія бази — на ній перевіряємо цілісність зв’язків між товарами, замовленнями та покупцями.
- Структура каталогу: категорії, властивості, варіанти товарів, правила цін і знижок.
- Перелік інтеграцій зі складом, платіжними сервісами, службами доставки, розсилками та системами обліку.
- Список нестандартних сценаріїв: особисті кабінети, оптові прайси, програми лояльності, розрахунок доставки.
- Налаштовані адреси та правила перенаправлення — щоб позиції в пошуку не просіли після перемикання.
- Дані аналітики за кілька місяців: які розділи та сценарії несуть основне навантаження.
У відповідь надсилаємо план робіт із перенесення: етапи, відповідність сутностей старої та нової платформи, що переїжджає автоматично і що потребує ручної звірки.
Окремо фіксуємо ризики, порядок відкату на попередню версію та варіант підтримки сайту після перенесення — регламент оновлень, моніторинг доступності, розбір звернень. Опишіть задачу й надішліть перелічене — повернемося з оцінкою строків перенесення та зрозумілим планом.
