Коротка відповідь
На відміну від WordPress, Бітрікс значно чутливіший до версії PHP, налаштувань .htaccess і прав доступу до файлів. Перенесення «просто скопіювати файли й базу» тут спрацьовує рідше — потрібна ретельніша перевірка сумісності середовища до перенесення, а не після.
Помилка 1: не перевірили сумісність версії PHP заздалегідь
Бітрікс історично чутливий до версії PHP — старіші редакції чи кастомні модулі можуть не працювати на найновішій версії PHP без правок коду, тоді як надто стара версія PHP — це вже вразливості безпеки. Перед переносом варто:
- Дізнатися поточну версію PHP на старому сервері (у панелі керування чи через
phpinfo()). - Перевірити, з якими версіями сумісна встановлена редакція Бітрікс і модулі.
- Узгодити з підтримкою нового хостингу, яка версія PHP доступна і чи можна перемкнути окремо для цього сайту.
Помилка 2: забули про .htaccess і правила ЧПУ (людино-зрозумілих URL)
Бітрікс активно використовує .htaccess для правил ЧПУ (людино-зрозумілих адрес сторінок). Якщо при копіюванні файл .htaccess не переноситься (буває, що приховані файли, які починаються з крапки, губляться при копіюванні через деякі FTP-клієнти чи архіватори), сайт відкривається, але всі внутрішні посилання й сторінки видають 404.
Перевірка: після перенесення відкрити не тільки головну сторінку, а кілька внутрішніх — картку товару, розділ каталогу. Якщо головна працює, а розділи видають помилку 404 — це майже завжди про .htaccess чи налаштування mod_rewrite на новому сервері.
Помилка 3: не перенесли або не переналаштували модуль бітрікс24.диск чи хмарні інтеграції
Якщо на сайті підключені хмарні сервіси Бітрікс (диск, CRM-інтеграції), при зміні домену чи IP частина інтеграцій може вимагати повторної авторизації або оновлення налаштувань підключення. Це варто перевірити окремим пунктом у чек-листі, а не сподіватися, що «саме запрацює» після копіювання файлів.
Помилка 4: неправильні права доступу до файлів після копіювання
Бітрікс має власну систему перевірки прав на директорії (зокрема upload/ і bitrix/cache/), і при перенесенні через архів права часто скидаються на дефолтні значення нового сервера. Симптом — адмінка Бітрікс видає попередження про «недостатньо прав» на певні директорії або не може записати кеш. Рішення — після розпакування файлів явно виставити права відповідно до вимог редакції Бітрікс (зазвичай 755 для директорій, 644 для файлів, з окремими виключеннями для upload і кешу).
Помилка 5: забули про cron-завдання
Бітрікс активно використовує cron для агентів (фонових задач) — індексація, розсилки, синхронізація з 1С. Якщо cron не налаштований на новому сервері так само, як на старому, сайт технічно працює, але фонові процеси мовчки перестають виконуватися, і це часто помічають не одразу.
Загальний план перенесення для Бітрікс
- Зняти повну копію файлів (включно з прихованими .htaccess) і дамп бази даних.
- Перевірити сумісність версії PHP на новому сервері з поточною редакцією Бітрікс.
- Розгорнути на новому сервері, перевірити через технічну адресу чи файл hosts.
- Виставити правильні права доступу на директорії upload і bitrix/cache.
- Перевірити внутрішні сторінки на 404 (правила ЧПУ), не тільки головну.
- Перенести й перевірити cron-завдання.
- Тільки після повної перевірки — перемкнути DNS.
Загальні принципи переносу без простою й з увагою до платіжних інтеграцій — ті самі, що й для будь-якого магазину: перенос інтернет-магазину на новий хостинг без втрати замовлень.
Чому підтримка з досвідом Бітрікс має значення
Різниця між «просто хостингом» і хостингом, де підтримка розуміє специфіку Бітрікс, — саме в цих деталях: права доступу, .htaccess, cron. Технічне питання про це — гарний спосіб перевірити підтримку до оплати, як описано в статті про вибір хостингу.
Помилка 6: не врахували вимоги до розширень PHP
Бітрікс залежить від низки розширень PHP (наприклад, для роботи з зображеннями, архівами, кодуваннями), які не завжди увімкнені за замовчуванням на новому сервері. Симптом — окремі модулі адмінки (наприклад, обробка зображень товарів) працюють некоректно або взагалі не завантажуються, хоча основний сайт відкривається без помилок. Перед переносом варто звірити повний список вимог поточної редакції Бітрікс до складу PHP і заздалегідь узгодити це з підтримкою нового хостингу.
Помилка 7: система "Веб-кластер" і кешування, налаштовані під старий сервер
Якщо на попередньому хостингу було налаштоване специфічне кешування Бітрікс (наприклад, через Memcached чи інший механізм), ці налаштування прив'язані до конкретної конфігурації сервера й не переносяться автоматично разом із файлами. На новому сервері варто перевірити налаштування кешування в адмінці Бітрікс і за потреби переналаштувати під доступні на новому хостингу механізми — інакше сайт може або показувати застарілі дані, або взагалі видавати помилки при спробі звернутися до недоступного кеш-сервісу.
Специфіка ліцензування Бітрікс при переносі
На відміну від WordPress (безкоштовна CMS із відкритим кодом), Бітрікс — комерційний продукт із ліцензією, часто прив'язаною до конкретного домену чи кількості серверів. Перед перенесенням варто перевірити умови власної ліцензії — чи потрібно повідомляти виробника про зміну хостингу, чи ліцензія прив'язана виключно до домену (і тоді зміна сервера не проблема), чи є якісь технічні обмеження кількості активацій. Це організаційний, а не суто технічний момент, який легко пропустити, зосередившись тільки на файлах і базі даних.
Чому не варто переносити Бітрікс "наживо" без тестового етапу
Через велику кількість взаємопов'язаних налаштувань — прав доступу, .htaccess, cron, кешування, версії PHP — імовірність, що хоч щось піде не за планом при першій спробі, доволі висока навіть у досвідчених команд. Перенесення "наживо", одразу з перемиканням DNS без проміжної перевірки на технічній адресі, означає, що будь-яка з цих типових помилок стає видимою відвідувачам сайту в реальному часі, а не виявляється й виправляється до того, як хтось із клієнтів це побачить.
Документування налаштувань перед перенесенням
Перш ніж почати перенесення, варто зробити знімки (скріншоти чи текстовий опис) ключових налаштувань зі старого сервера: версія PHP і список активних розширень, налаштування кешування, список cron-завдань з розкладом їх виконання. Це звучить як зайва бюрократія, але саме цей документ рятує години діагностики, коли після перенесення щось працює не так, як мало б, — набагато простіше звірити з зафіксованим еталоном, ніж пригадувати по пам'яті, що й як було налаштовано.
Особливості перенесення інтернет-магазину на Бітрікс
Якщо на Бітрікс працює саме магазин (а не просто корпоративний сайт), додаються ті самі ризики, що й для будь-якого e-commerce перенесення, — активні замовлення, платіжні інтеграції, актуальні залишки товарів. Загальний підхід із паралельним тестуванням і коротким вікном заморозки замовлень, описаний у статті перенос інтернет-магазину без втрати замовлень, застосовний і тут, разом зі специфічними для Бітрікс перевірками з цієї статті.
Тестування перед фінальним перемиканням: розширений підхід для Бітрікс
Через велику кількість взаємопов'язаних налаштувань варто виділити для тестування Бітрікс більше часу, ніж для простішої CMS. Рекомендований підхід: розгорнути копію на новому сервері за технічною адресою, пройтися по всіх ключових розділах адмінки (не тільки публічна частина сайту), перевірити роботу як мінімум однієї транзакції "з нуля" — від перегляду каталогу до оформлення замовлення чи заявки, — і тільки після цього призначати вікно фінального перемикання DNS.