Міграція сайту з іншого CMS на 1С-Бітрікс

Міграція сайту з іншої CMS на 1С-Бітрікс

Перенести сайт з WordPress, OpenCart або MODx на Бітрікс — це не просто скопіювати файли. Структури даних кардинально різні: те, що у WordPress зберігається в wp_posts + wp_postmeta, у Бітрікс розбито по b_iblock_element, b_iblock_element_property і b_iblock_element_prop_m. Міграція — це ETL-проєкт (Extract, Transform, Load) із серйозною аналітичною фазою.

Аудит вихідної CMS

Перший крок — інвентаризація того, що потрібно перенести:

Контент:

• Статичні сторінки (кількість, структура URL)
• Новини, статті, блог (обсяг, теги, категорії)
• Галереї та медіафайли

Каталог (для магазинів):

• Кількість товарів і торгових пропозицій (SKU)
• Структура атрибутів і характеристик
• Ціни та залишки
• Зображення товарів

Користувачі та замовлення:

• База покупців (email, хешовані паролі)
• Історія замовлень
• Бонусні бали та знижки

SEO:

• Поточні URL та їхня структура
• Meta title/description для всіх сторінок
• Sitemap і robots.txt

Типові маппінги даних

WordPress → Бітрікс (контент):

OpenCart → Бітрікс (каталог):

Скрипт міграції: підхід

Міграція реалізується через PHP-скрипти, що працюють з API Бітрікс. Пряме записування в таблиці БД — лише для масових даних із наступною перебудовою індексів.

Приклад міграції товару через API:

// Читання товару з джерела (OpenCart DB)
$ocProduct = $sourceDb->query("SELECT * FROM oc_product WHERE product_id = ?", [$productId])->fetch();
$ocDesc = $sourceDb->query("SELECT * FROM oc_product_description WHERE product_id = ? AND language_id = 2", [$productId])->fetch();
$ocImages = $sourceDb->query("SELECT * FROM oc_product_image WHERE product_id = ? ORDER BY sort_order", [$productId])->fetchAll();

// Створення елемента в Бітрікс
$el = new CIBlockElement();
$elementId = $el->Add([
    'IBLOCK_ID'         => CATALOG_IBLOCK_ID,
    'NAME'              => $ocDesc['name'],
    'CODE'              => \Bitrix\Main\Text\StringHelper::translit($ocDesc['name']),
    'DETAIL_TEXT'       => $ocDesc['description'],
    'PREVIEW_TEXT'      => $ocDesc['meta_description'],
    'ACTIVE'            => $ocProduct['status'] ? 'Y' : 'N',
    'IBLOCK_SECTION_ID' => getCategoryMapping($ocProduct['manufacturer_id']),
    'PROPERTY_VALUES'   => [
        'ARTICLE'  => $ocProduct['model'],
        'WEIGHT'   => $ocProduct['weight'],
        'BRAND_ID' => getBrandMapping($ocProduct['manufacturer_id']),
    ],
]);

// Завантаження головного зображення
if ($ocProduct['image']) {
    migrateImage($elementId, $sourceImgPath . $ocProduct['image'], 'DETAIL_PICTURE');
}

// Завантаження галереї
foreach ($ocImages as $img) {
    migrateImageToGallery($elementId, $sourceImgPath . $img['image']);
}

// Встановлення ціни
CCatalogProduct::Add(['ID' => $elementId, 'QUANTITY' => $ocProduct['quantity']]);
CPrice::SetBasePrice($elementId, $ocProduct['price'], 'UAH');

Збереження SEO та URL-структури

Це найбільш комерційно чутлива частина. Втрата позицій у пошуку при зміні CMS — реальний ризик.

Стратегія збереження URL:

1. Формуємо маппінг старих URL → нових URL у Бітрікс
2. Налаштовуємо редиректи 301 через .htaccess або nginx
3. У Бітрікс встановлюємо символьні коди (CODE) елементів і розділів максимально близько до старих URL

# .htaccess — редиректи старих URL WordPress
RewriteRule ^blog/(.+)/$  /news/$1/  [R=301,L]
RewriteRule ^product/(.+)/$  /catalog/item/$1/  [R=301,L]

4. Meta title і description переносяться у властивості інфоблоку або через модуль SEO-фільтрів Бітрікс

Карта редиректів — обов'язковий артефакт проєкту, експортується в CSV для перевірки.

Перенесення користувачів

Паролі з WordPress (bcrypt) не можна перенести напряму — алгоритм хешування в Бітрікс інший. Варіанти:

• Примусове скидання — користувачі отримують листа з проханням встановити новий пароль
• Тимчасовий логін за email — при першому вході після міграції запитується лише email, потім встановлення нового пароля
• Гібридний хеш — при вході перевіряти пароль спочатку за старим алгоритмом, при успіху перехешувати у формат Бітрікс

Третій варіант потребує кастомного обробника авторизації, але зберігає UX — користувачі не помічають міграції.

Тестування та приймання

Після міграції — звірення даних:

# Псевдокод звірення
source_count = source_db.query("SELECT COUNT(*) FROM oc_product WHERE status=1")
bitrix_count = bitrix_db.query("SELECT COUNT(*) FROM b_iblock_element WHERE IBLOCK_ID=? AND ACTIVE='Y'", [CATALOG_IBLOCK_ID])
assert source_count == bitrix_count, f"Product count mismatch: {source_count} vs {bitrix_count}"

Перевіряється: кількість товарів, розділів, користувачів, замовлень. Вибірково — контент 20–30 випадкових елементів.

Терміни виконання

Міграція з іншої CMS — це повноцінний проєкт розробки, а не просто «експорт-імпорт». Якість результату залежить від глибини аудиту на старті.