Повний гід з міграції інтернет-магазину з Magento на 1С-Бітрікс
Власник магазину на Magento 1 стикається з необхідністю міграції через завершення підтримки та потребу інтеграції з 1С. Magento (особливо версія 1.x) використовує EAV-модель (Entity–Attribute–Value), де атрибути товарів розкидані по десятках таблиць. Це ускладнює підтримку та сповільнює запити при каталозі >10 000 товарів. Бітрікс з інфоблоками v2.0 та ORM дає більш плоску та швидку структуру, особливо в поєднанні з тегованим кешуванням. За 8 років ми виконали понад 30 проектів з міграції з Magento на Бітрікс і гарантуємо цілісність даних на кожному етапі.
Чому Magento не завжди найкращий вибір?
Інтеграція з 1С через CommerceML у Бітрікс реалізована «з коробки», а для Magento потрібен сторонній модуль або костильна синхронізація. Це знижує вартість володіння після міграції. Крім того, у Magento 1.x EAV-модель призводить до того, що для отримання повних даних про товар потрібен JOIN через 5–6 таблиць. У Бітрікс дані зберігаються в одній таблиці інфоблоку, що прискорює вибірки.
Які проблеми вирішуємо при міграції
EAV-модель та продуктивність
При каталозі >10 000 товарів Magento починає гальмувати на типових запитах. В одному з проектів (інтернет-магазин одягу, 12 000 товарів з варіаціями) час генерації сторінки каталогу сягав 8 секунд. Після міграції на Бітрікс з тегованим кешем сторінки стали відкриватися за 1-2 секунди — це у 4–8 разів швидше. Такий приріст продуктивності критично впливає на конверсію та позиції в пошуку.
Конфігуровані товари
У Magento конфігурований товар — це батько з дочірніми простими товарами, пов'язаними через catalog_product_super_link. У Бітрікс така ієрархія транслюється в інфоблок каталогу (батько) та торгові пропозиції (дочірні). Атрибути-варіації (розмір, колір) стають властивостями SKU. Ми зберігаємо всі зв'язки та ціни для кожної варіації.
Замовлення та клієнти
Клієнтська база Magento (таблиця customer_entity) маппляться на користувачів Бітрікс. Замовлення мігрують через CSaleOrder::Add() з відтворенням складу та статусів. Історія замовлень в особистому кабінеті відновлюється — це критично для B2B-клієнтів. В одному з проектів ми перенесли 50 000 замовлень за 3 дні без втрат.
Як ми переносимо дані без втрат
Експорт товарів з Magento
Штатний експорт Magento через CSV не включає медіа-файли та ціноутворення для різних груп покупців. Для повного експорту надійніше SQL:
-- Отримати товари з назвою та ціною (Magento 1)
SELECT
p.entity_id,
pv.value AS name,
pt.value AS description,
pd.value AS price,
p.sku,
p.type_id
FROM catalog_product_entity p
JOIN catalog_product_entity_varchar pv
ON p.entity_id = pv.entity_id AND pv.attribute_id = 71 AND pv.store_id = 0
LEFT JOIN catalog_product_entity_text pt
ON p.entity_id = pt.entity_id AND pt.attribute_id = 72 AND pt.store_id = 0
LEFT JOIN catalog_product_entity_decimal pd
ON p.entity_id = pd.entity_id AND pd.attribute_id = 75 AND pd.store_id = 0
WHERE p.status = 1;
Значення attribute_id потрібно уточнити для конкретної інсталяції Magento через таблицю eav_attribute.
Перенесення категорій та дерева розділів
Категорії Magento зберігаються в catalog_category_entity (EAV). Ієрархія задається полем path (наприклад, 1/2/5/12). У Бітрікс ми відтворюємо розділи інфоблоку з відповідною вкладеністю, зберігаючи метадані та налаштування відображення.
Ціни та групи покупців
Magento підтримує tier pricing (ціни за обсягом) та customer group pricing. У Бітрікс це реалізується через типи цін (b_catalog_price_type) та правила знижок. Ми маппимо групи покупців Magento на групи користувачів Бітрікс і налаштовуємо відповідні типи цін.
Процес роботи
- Аудит вихідної бази Magento: структура каталогу, атрибути, товари, замовлення, клієнти.
- Написання скриптів міграції на PHP з урахуванням EAV-моделі.
- Перенесення товарів з атрибутами, зображеннями, зв'язками.
- Перенесення замовлень, клієнтів, адрес та історії.
- Налаштування цін та груп покупців.
- Розробка нового шаблону на Бітрікс (дизайн Magento не переноситься).
- Тестування всіх функцій: каталог, кошик, оформлення, особистий кабінет.
- Навчання адміністраторів роботі в Бітрікс.
- 30-денна підтримка після запуску.
Що входить у вартість міграції?
- Повний аудит вихідної бази Magento: структура каталогу, атрибути, товари, замовлення, клієнти.
- Написання та виконання скриптів міграції з гарантією цілісності даних.
- Перенесення всіх товарів (з атрибутами, зображеннями, зв'язками), категорій, замовлень, клієнтів та цін.
- Налаштування типів цін, груп покупців та правил знижок.
- Розробка нового шаблону на Bitrix Framework з урахуванням фірмового стилю.
- Тестування всіх функцій та виправлення помилок.
- Навчання адміністраторів роботі в Бітрікс (до 4 годин).
- 30-денна підтримка після запуску.
- Документація за результатами міграції.
Вартість міграції для типового магазину (до 5 000 товарів) стартує від 150 000 грн. Точна сума залежить від складності каталогу, кількості атрибутів та необхідності нестандартних доопрацювань.
Орієнтовні терміни
| Тип проекту |
Товарів |
Термін |
| Простий магазин, стандартні атрибути |
до 3 000 |
6–10 тижнів |
| Середній магазин з варіаціями |
3 000–20 000 |
3–5 місяців |
| Великий B2B-магазин, багатосклад, tier pricing |
20 000+ |
5–8 місяців |
Паралельно з перенесенням даних розробляється шаблон сайту на Бітрікс.
Наш досвід та гарантії
Ми — сертифіковані спеціалісти Бітрікс з досвідом міграції понад 30 проектів. Гарантуємо, що всі дані (товари, замовлення, клієнти, ціни) будуть перенесені без втрат. Після запуску надаємо документацію та 30-денну підтримку. Зв'яжіться з нами для оцінки вашого проекту — підберемо оптимальний план міграції. Отримайте консультацію по вашому проекту, щоб дізнатися точні терміни та вартість.
Міграція сайтів на 1С-Бітрікс
Переїзд на нову CMS — завжди стрес для сайту. Якщо проігнорувати URL-структуру, через два тижні трафік падає на 50–80 %. WordPress генерує /product/item-name/, OpenCart — /index.php?route=product/product&product_id=123, а Бітрікс за замовчуванням хоче /catalog/section/element/. Без карти 301-редиректів пошуковики фіксують масові 404. Ми починаємо будь-яку міграцію зі сканування старого сайту через Screaming Frog і складаємо повну карту редиректів ще до першого рядка коду. Як сказано в документації 1С-Бітрікс: коректна міграція вимагає повного маппінгу URL.
За 7 років ми перенесли понад 50 проєктів — від лендінгів до каталогів на 300 000 товарів. Середній термін — 2–8 тижнів. Оцінку проєкту робимо безкоштовно за 1 день — зв'яжіться для попереднього розрахунку.
Які CMS ми переносимо на Бітрікс?
За роки роботи дані мігрували з десятків систем.
Блоги та корпоративні сайти: WordPress / WooCommerce → 1С-Бітрікс. Таблиці wp_posts, wp_postmeta, wp_wc_product_meta_lookup маппяться в інфоблоки та highload-блоки. Варіації товарів (WooCommerce Variable Product) стають торговими пропозиціями (b_catalog_product).
Інтернет-магазини: OpenCart / ocStore → 1С-Бітрікс. Структура oc_product, oc_product_description, oc_product_to_category переїжджає в ієрархію інфоблоків. Мультимовність OpenCart перетворюється на мовні версії властивостей. Joomla / VirtueMart, MODX Revolution (TV-змінні → властивості інфоблоків), Drupal, PrestaShop — аналогічно.
SaaS-платформи: Tilda, InSales, Shopify, Wix, Squarespace. Бізнес переріс конструктор — потрібні 1С-інтеграції та управління залишками.
Самописні двигуни: реверсимо БД і відновлюємо бізнес-логіку за вихідним кодом.
Що переноситься?
Контент: сторінки, статті, новини → інформаційні інфоблоки. Каталог: категорії → розділи, товари → елементи з прив'язкою до b_catalog_product, властивості → властивості інфоблоку або highload-довідники. Зображення, відгуки, FAQ.
E-commerce: товари з варіаціями (торгові пропозиції), ціни в b_catalog_price (мультивалютні через b_catalog_currency), залишки по складах b_catalog_store_product, знижки (b_sale_discount), історія замовлень (b_sale_order + b_sale_basket).
Користувачі: клієнтська база — b_user + UF-поля. Паролі в кожній CMS хешуються по-своєму: WordPress — phpass, OpenCart — SHA1+salt, Drupal — SHA512. Ми пишемо кастомний CUser::LoginByHash з fallback на старий алгоритм — клієнт вводить пароль один раз, система перехешує в bcrypt Бітрікса.
SEO-дані: мета-теги, alt-теги, URL-структура. Головне завдання — зберегти всі URL або проставити 301-редиректи.
Медіа: зображення, документи, відео — зі збереженням шляхів та оптимізацією через CFile::MakeFileArray().
Як відбувається міграція?
| Етап |
Тривалість |
Що робимо |
| Аудит |
1–3 дні |
Скануємо Screaming Frog: всі URL, статус-коди, мета-теги. Аналізуємо структуру БД, кастомні доробки, інтеграції. Складаємо карту перенесення. |
| Проектування архітектури |
2–5 днів |
Маппінг: типи контенту → інфоблоки, поля → властивості, довідники → highload-блоки. Архітектура має бути зручною для адміністрування в Бітрікс. |
| Скрипти міграції |
3–10 днів |
PHP-скрипти читають зі старої БД (або API), трансформують і пишуть через API Бітрікса (CIBlockElement::Add, \Bitrix\Sale\Order::create). Запускаємо повторно при тестуванні. |
| Staging |
1–2 дні |
Повне перенесення на тестовий сервер. Перевіряємо цілісність: кількість товарів, властивості, URL, фільтри. |
| Дизайн / шаблони |
1–4 тижні |
Редизайн або адаптація верстки під шаблонізатор Бітрікса (template.php, result_modifier.php). |
| 301-редиректи |
1–2 дні |
Повна карта в .htaccess або nginx.conf. Кожен проіндексований URL → відповідна сторінка нового сайту. |
| Фінальна міграція |
1 день |
Дельта-імпорт свіжих даних, перемикання DNS, моніторинг. |
| Постміграційний контроль |
2–4 тижні |
Моніторимо Google Search Console та Яндекс.Вебмастер: індексація, позиції, crawl errors. |
Як зберегти SEO-позиції?
Втрата органічного трафіку — головний страх, і він обґрунтований. Ось як ми його уникаємо.
Маппінг URL 1:1 — де можливо, через CUrlRewriter та ЧПУ-налаштування інфоблоку зберігаємо точну структуру. Де не можна — 301. Автогенерація карти редиректів: парсимо експорт Screaming Frog, зіставляємо з slugs нових елементів, генеруємо конфіг nginx. Кожен редирект перевіряється curl -I після перемикання.
Перенесення мета-тегів: title, description, h1 переносяться як є у властивості ELEMENT_META_TITLE, ELEMENT_META_DESCRIPTION. Canonical: rel="canonical" через SEO-компонент Бітрікс. Дуби відсікаємо: www/без www, http/https, параметри сортування. Sitemap: нова sitemap.xml через модуль seo Бітрікса, подача в Search Console та Вебмастер одразу після перемикання.
Порівняння швидкості: Бітрікс у 3 рази швидше обробляє каталог із 100 000 товарів, ніж OpenCart, завдяки тегованому кешуванню та оптимізації запитів до b_catalog_product.
Що входить у роботу (deliverables)
| Що отримує клієнт |
Опис |
| Документація |
Карта редиректів, опис маппінгу, схема БД |
| Доступи |
Адміністративна панель, FTP/SSH, API-ключі |
| Навчання |
Відеоуроки або консультація з роботи з Бітрікс |
| Підтримка |
2 тижні постміграційного моніторингу та фіксу багів |
| Гарантія |
Повернення до старого сайту протягом 48 годин при форс-мажорі |
Міграція інтеграцій
Зовнішні інтеграції — окремий пласт. Ми перепідключаємо:
- Платіжні системи —
sale.paysystem зі збереженням історії транзакцій.
- Доставка — налаштування
sale.delivery.handler (СДЕК, Укрпошта).
- CRM — прив'язка до Бітрікс24 або збереження поточної через REST API.
- 1С — налаштування обміну через CommerceML. Часто це головна причина міграції на Бітрікс.
- Email-маркетинг — перенесення підписників, шаблонів, вебхуків.
- Аналітика — e-commerce tracking під нову структуру dataLayer.
Типові помилки при міграції
Кожна з цих помилок призводила до втрати позицій і клієнтів.
Втрата URL без редиректів — найруйнівніший промах. /product/123 замість /catalog/item-name.html — без 301 це масові 404 та обвал трафіку. Ми генеруємо карту автоматично і перевіряємо кожен редирект після перемикання.
Дублювання контенту: один товар доступний з www і без, по HTTP і HTTPS, з GET-параметрами фільтрації — п'ять URL замість одного. SEO-вага розмивається. Налаштовуємо canonical, 301 для варіацій, robots.txt з Disallow для параметрів.
Биті зображення: абсолютні URL в контенті (src="https://old-site.ru/img/photo.jpg"), втрата якості при перетисканні. Замінюємо на відносні шляхи, переносимо зі збереженням структури, перевіряємо HTTP 200 для кожного файлу.
Втрата мета-тегів і мікророзмітки: title, description, Schema.org можуть не перенестися або перенестися криво. Робимо повний маппінг і перевірку на staging.
Відвалені форми та інтеграції: змінилися ID, API-ключі, вебхуки. Складаємо реєстр усіх інтеграцій до початку і перевіряємо кожну після.
Мобільна версія: старий m.site.ru → адаптивний Бітрікс. Без редиректу мобільних URL — 404 для мобільних користувачів. Враховуємо в карті редиректів.
Перед міграцією обов'язково: 1) повне сканування Screaming Frog / Sitebulb; 2) експорт SEO (title, description, h1, canonical, hreflang); 3) фіксація позицій за ключовими запитами; 4) бекап файлів і БД з перевіркою відновлення; 5) реєстр усіх інтеграцій; 6) карта редиректів для кожної проіндексованої сторінки; 7) тестова міграція на staging з повною перевіркою; 8) коректна мобільна версія та редиректи з m.site.ru; 9) нова sitemap.xml готова до подачі; 10) план відкату: DNS збережені, конфіг задокументовано, доступ до старого хостингу є.
Терміни та економія
| Тип проєкту |
Терміни |
Коментар |
| Інформаційний сайт (до 500 стор.) |
2–4 тижні |
Контент + дизайн + редиректи |
| Інтернет-магазин (до 10 000 товарів) |
4–8 тижнів |
Каталог + замовлення + інтеграції |
| Великий магазин (100 000+ товарів) |
2–4 місяці |
Кастомні скрипти + навантажувальне тестування |
Економія: після міграції ви перестаєте платити за ліцензію старої CMS та підтримку застарілого коду. Типова економія на рік — значна сума за рахунок відмови від плагінів та хостингу з низькою продуктивністю. Додайте сюди вартість ліцензії 1С-Бітрікс (редакція «Бізнес») — вона повністю окупається в перший місяць.
Отримайте консультацію з міграції: заповніть форму на сайті, і ми підготуємо пропозицію за 1 день. Оцінимо ваш проєкт безкоштовно — напишіть нам для розрахунку.
