Міграція сайту на 1С-Бітрікс: як змінити хостинг без проблем

Міграція сайту на 1С-Бітрікс: покроковий план

Перенесення сайту на 1С-Бітрікс — завдання, яке здається простим тільки до першого запуску. Ми не раз бачили, як після копіювання файлів і дампу сайт видає білий екран або помилки підключення до бази. Причина — невідповідність версій PHP, невірні шляхи, криві права доступу. Щоб уникнути цього, ми розробили чіткий алгоритм, який мінімізує downtime і гарантує працездатність. Дотримуючись цього плану, ви заощадите до 50 000 грн на усуненні наслідків невдалого перенесення та уникнете втрати замовлень. Наприклад, один із клієнтів втратив два дні на налагодження після того, як скопіював сайт на сервер з PHP 8.0 замість 7.4, а в коді використовувались застарілі функції. Ми допомогли за годину. Типове перенесення займає від 2 годин до 1-3 днів, що значно дешевше розробки з нуля.

Як підготувати сайт до перенесення?

До початку робіт з'ясуйте конфігурацію нового хостингу та порівняйте з поточною:

• Версія PHP (Бітрікс підтримує 7.4–8.2; деякі хостинги за замовчуванням ставлять застарілу)
• Розширення PHP: mbstring, gd, zip, curl, opcache, PDO, pdo_mysql — обов'язково
• Тип бази даних і версія: MySQL 5.7+ або MariaDB 10.3+. У деяких хостингів є обмеження на max_allowed_packet, innodb_buffer_pool_size
• Доступність cron і можливість додавати завдання
• Обмеження exec(), shell_exec() — потрібні для агентів і деяких модулів

Створення резервної копії

Штатний інструмент — модуль резервного копіювання в адміністративній панелі (Налаштування → Інструменти → Резервне копіювання). Він створює архів у /bitrix/backup/. Але він має обмеження: при великих сайтах (від 5–10 ГБ) процес завершується за таймаутом.

Для великих сайтів надійніше ручний підхід:

mysqldump -u dbuser -p --single-transaction --routines --triggers dbname > dump.sql
tar -czf site_files.tar.gz \
  --exclude='./bitrix/cache' \
  --exclude='./bitrix/managed_cache' \
  --exclude='./bitrix/backup' \
  --exclude='./bitrix/html_pages' \
  /var/www/site/

Виключення кешу обов'язкове: він займає значний об'єм і на новому сервері все одно інвалідується.

Налаштування нового сервера

Після розпакування файлів оновіть конфігурацію підключення до бази даних у файлі /bitrix/php_interface/dbconn.php:

$DBType = "mysql";
$DBHost = "localhost";
$DBLogin = "new_db_user";
$DBPassword = "new_password";
$DBName = "new_db_name";

А також /bitrix/.settings.php:

'connections' => [
    'value' => [
        'default' => [
            'className' => '\\Bitrix\\Main\\DB\\MysqlConnection',
            'host' => 'localhost',
            'database' => 'new_db_name',
            'login' => 'new_db_user',
            'password' => 'new_password',
        ],
    ],
],

Чому важливе налаштування прав доступу?

1С-Бітрікс вимагає конкретних прав. Неправильні права — причина 90% помилок при перенесенні.

Нерідко хостинги працюють через suexec, і права повинні належати користувачеві сайту. Якщо php-fpm запущено під іншим користувачем — помилки запису в кеш неминучі.

Як перевірити працездатність після перенесення?

Після запуску обов'язково пройдіться за чек-листом:

1. Перевірка роботи ядра: відкрийте /bitrix/admin/ — має завантажитись без помилок.
2. Тест пошти: форма зворотного зв'язку, сповіщення замовлень — mail() або SMTP-налаштування в Головному модулі.
3. Агенти та cron: у /bitrix/admin/agent_list.php переконайтесь, що агенти виконуються; налаштуйте cron для /bitrix/modules/main/tools/cron_events.php.
4. HTTPS і сертифікат: оновіть SITE_SERVER_NAME та BX_UTF у налаштуваннях сайту, перевірте .htaccess на редиректи.
5. Кеш: очистіть керований кеш через адміністративну панель.
6. Ліцензія: якщо змінилася IP-адреса сервера — перевірте активацію ліцензії в особистому кабінеті 1С-Бітрікс.

Особливий випадок: зміна домену

Якщо одночасно з перенесенням змінюється домен, додатково потрібно:

• Оновити SITE_SERVER_NAME у таблиці b_lang (або через Налаштування → Сайти).
• Оновити адресу сайту в налаштуваннях Головного модуля.
• Виправити абсолютні шляхи в контенті інфоблоків (через SQL-оновлення або компонент пошуку та заміни).
• Переналаштувати інтеграції, які використовують webhook-URL (платіжні системи, CRM-інтеграції).

Що входить у роботу

Перенесення під ключ включає:

• Діагностику поточної конфігурації та перевірку сумісності з новим хостингом.
• Створення резервної копії (файли + база даних).
• Налаштування нового сервера: PHP, БД, права доступу, cron.
• Перенесення даних і перевірку цілісності.
• Тестування всіх критичних функцій (форма зворотного зв'язку, кошик, замовлення).
• Передачу доступів та інструкцію з експлуатації.
• Підтримку протягом 3 днів після перенесення.

Типові терміни

Що робити, якщо виникли проблеми після перенесення?

Перевірте логи PHP та веб-сервера. Найчастіше проблема в невірних правах на /upload/ або /bitrix/cache/, а також у невідповідності версії PHP. Зв'яжіться з нами — ми проведемо діагностику протягом години. Перенесення проводиться в нічний час або з мінімальним downtime через тимчасове DNS-перемикання та синхронізацію дельти бази даних.

Оцініть ваш проєкт — зв'яжіться з нами для консультації. Отримайте детальний план перенесення та точну оцінку термінів. Замовте послугу і уникайте проблем при міграції. Детальніше про платформу читайте на Wikipedia.

Міграція сайтів на 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().

Як відбувається міграція?

Як зберегти 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)

Міграція інтеграцій

Зовнішні інтеграції — окремий пласт. Ми перепідключаємо:

• Платіжні системи — 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 збережені, конфіг задокументовано, доступ до старого хостингу є.

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

Економія: після міграції ви перестаєте платити за ліцензію старої CMS та підтримку застарілого коду. Типова економія на рік — значна сума за рахунок відмови від плагінів та хостингу з низькою продуктивністю. Додайте сюди вартість ліцензії 1С-Бітрікс (редакція «Бізнес») — вона повністю окупається в перший місяць.

Отримайте консультацію з міграції: заповніть форму на сайті, і ми підготуємо пропозицію за 1 день. Оцінимо ваш проєкт безкоштовно — напишіть нам для розрахунку.