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

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

Переїзд Бітрікс-сайту — не рутинна задача, а процес із десятками нюансів. Пропустите один — отримаєте помилку 500, втрачені замовлення або биті картинки. За 10 років ми провели понад 50 міграцій і знаємо кожен підводний камінь: жорстко зашиті шляхи, прив'язку ліцензії до bind-імені сервера, приховані кеші. Гарантуємо нульовий даунтайм при правильній організації. Економія часу та коштів порівняно з самостійним перенесенням може сягати 40%. Для прикладу, нещодавно ми перенесли інтернет-магазин на 50 000 товарів з інтеграцією 1С — весь процес зайняв 4 години без жодної хвилини простою. Професійна міграція в 10 разів швидша за самостійну та в 5 разів надійніша. Замовте оцінку вашого проєкту — розрахуємо термін і вартість індивідуально. Докладніше про протокол DNS можна прочитати у Вікіпедії. Документація 1С-Бітрікс рекомендує знижувати TTL до 300 секунд за 24–48 годин до переносу: «При зміні DNS важливо заздалегідь зменшити час життя запису».

Де зашиті шляхи та налаштування — безпечне перенесення сайту

Перед переносом важливо знати критичні точки зберігання даних:

• /bitrix/.settings.php — підключення до БД, хост, порт, ім'я бази
• /bitrix/php_interface/dbconn.php — старе ядро (якщо ще використовується)
• У БД таблиця b_lang — домен прив'язаний до сайту
• /bitrix/cache/ та /bitrix/managed_cache/ — кеш, який потрібно очистити
• /upload/ — медіафайли, іноді десятки ГБ
• Ліцензійний ключ — прив'язаний до домену та сервера

Чому важливо очищати кеш після міграції?

Після переносу старий кеш містить посилання на старий сервер. Якщо його не видалити, сайт намагатиметься завантажувати ресурси з неіснуючої адреси. Очищення кешу — обов'язковий крок, який робиться як через адмінку, так і безпосередньо командою.

Покроковий процес переносу

1. Підготовка нового сервера. Він має відповідати вимогам Бітрікс: PHP потрібної версії (для версій 22+ — PHP 8.0–8.2), розширення (mbstring, curl, gd, zip, xml, json), веб-сервер з коректними rewrite-правилами. Конфіг .htaccess або nginx копіюється разом із сайтом — у ньому можуть бути кастомні правила.

2. Резервна копія файлів

   tar -czf /tmp/site-backup.tar.gz \
       --exclude='./bitrix/cache' \
       --exclude='./bitrix/managed_cache' \
       --exclude='./bitrix/stack_cache' \
       /var/www/html/
   

   Папку /upload/ переносити окремо через великий об'єм.

3. Дамп бази даних

   mysqldump -u bitrix_user -p bitrix_db \
       --single-transaction \
       --routines \
       --triggers \
       > /tmp/bitrix_db.sql
   

   Флаг --single-transaction критичний для InnoDB — забезпечує консистентний снапшот без блокувань.

4. Розгортання на новому сервері Розпакуйте архів файлів та імпортуйте базу:

   mysql -u bitrix_user -p bitrix_db < /tmp/bitrix_db.sql
   

5. Оновлення конфігурації /bitrix/.settings.php — оновити параметри підключення до БД:

   return [
       'connections' => [
           'value' => [
               'default' => [
                   'className' => '\Bitrix\Main\DB\MysqlCommonConnection',
                   'host' => 'localhost',
                   'database' => 'bitrix_db',
                   'login' => 'bitrix_user',
                   'password' => 'new_password',
                   'options' => 2,
               ],
           ],
       ],
   ];
   

6. Зміна домену в базі даних

   UPDATE b_lang SET SERVER_NAME = 'newdomain.ua' WHERE LID = 's1';
   

   Також перевірити b_option та b_iblock на жорстко зашиті URL.

7. Ліцензійний ключ Після переносу перемістіть ключ в адмінці (Налаштування → Ліцензія). При зміні сервера може знадобитися звернення до підтримки 1С-Бітрікс.

8. Очищення кешу Видаліть папки кешу на сервері: rm -rf /var/www/html/bitrix/cache/* /var/www/html/bitrix/managed_cache/* /var/www/html/bitrix/stack_cache/*. Також очистіть кеш в адміністративній панелі: Налаштування → Продуктивність → Очистити кеш.

Основні ризики при самостійному перенесенні

Часто забувають оновити домен у b_option або не очищають кеш стилів — сайт виглядає «битим». Для e-commerce критично: в момент перемикання DNS замовлення можуть йти на обидва сервери. Ми вирішуємо це паралельною роботою та 301-редиректом на старому сервері.

Як перевірити сайт після міграції?

Перевірка через hosts-файл (без зміни DNS): 111.222.333.444 olddomain.ua

Чек-лист:

• Головна сторінка завантажується
• Каталог та картки товарів
• Кошик та оформлення замовлення
• Особистий кабінет
• Адміністративна панель
• HTTPS — сертифікат встановлено
• Зображення товарів
• Поштові сповіщення

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

Порівняння ручної та професійної міграції

Що входить у послугу міграції

• Аудит поточної архітектури та виявлення прихованих прив'язок
• Підготовка нового сервера під вимоги Бітрікс
• Перенесення файлів та бази зі збереженням структури
• Оновлення всіх конфігурацій та ліцензійного ключа
• Очищення кешу та тестування за чек-листом
• Допомога в перемиканні DNS та 301-редиректах
• Навчання адміністратора та документація за підсумками

Наша команда має 10+ років досвіду з Бітрікс і провела понад 50 міграцій. Отримайте консультацію з міграції — зв'яжіться з нами. Замовте оцінку вашого проєкту — розрахуємо термін і вартість індивідуально.

Міграція сайтів на 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 день. Оцінимо ваш проєкт безкоштовно — напишіть нам для розрахунку.