Що варто врахувати при переході до іншого провайдера веб-хостингу

Міграція веб-сайту до нового хостинг-провайдера є однією з найбільш ризикованих інфраструктурних операцій, які може виконувати власник сайту. При правильному виконанні вона забезпечує нульову втрату даних, мінімальний простій і помітно кращу продуктивність. При недбалому виконанні вона призводить до пошкоджених баз даних, збоїв DNS, падіння позицій у пошукових системах і годин аварійних відновлювальних робіт.

Цей посібник охоплює кожну критичну фазу міграції хостингу — від попереднього аудиту та перевірки сумісності, через механіку перемикання DNS, до моніторингу після міграції — з технічною глибиною, необхідною для безінцидентного виконання.

Фаза 1: Проведіть аудит поточного хостинг-середовища перед будь-якими діями

Найпоширеніша причина невдалої міграції — пропуск ретельного аудиту існуючого середовища. Перш ніж оцінювати нового провайдера, вам потрібен точний перелік того, що ви фактично запускаєте.

Профілювання трафіку та ресурсів

Зберіть щонайменше 90 днів даних про ресурси сервера — не лише кількість переглядів сторінок. Важливі такі метрики:

• Пікові одночасні підключення — не середній трафік, а максимальний пік, який повинен витримувати ваш сервер
• Споживання пам’яті на PHP-воркер або процес застосунку
• Шаблони дискового введення/виведення (Disk I/O) — особливо важливо, якщо ви запускаєте застосунок з інтенсивним використанням бази даних, як-от WooCommerce або власна CRM
• Використання пропускної здатності — загальний місячний трафік порівняно з лімітом вашого поточного плану

Якщо ваш поточний хост надає cPanel або Plesk, ці дані доступні в розділах використання ресурсів або AWStats. На Linux VPS виконайте наступне для отримання базового знімка стану:

vmstat 1 10
iostat -x 1 5
free -m
df -h

Цей результат покаже вам, чи є вашим вузьким місцем CPU, RAM або диск — що безпосередньо визначає, чи потрібен вам більший спільний план, VPS, чи Виділений сервер.

Інвентаризація програмного стека

Задокументуйте кожен компонент вашого стека з точними номерами версій:

• Версія PHP (наприклад, 8.1, 8.2) та активні розширення (mbstring, curl, gd, imagick, redis)
• Версія MySQL або MariaDB та рушій зберігання (InnoDB проти MyISAM має значення для інструментів міграції)
• Програмне забезпечення веб-сервера: Apache, Nginx, LiteSpeed або комбінація зворотного проксі
• Будь-які скомпільовані модулі, власні правила .htaccess або блоки nginx.conf location
• Завдання Cron — експортуйте їх з crontab -l та задокументуйте окремо
• Тип SSL-сертифіката та видавець (Let’s Encrypt, комерційний CA, wildcard)

Відсутність навіть одного PHP-розширення на цільовому сервері може непомітно порушити функціональність, яка проявляється лише при певних діях користувача — помилка, яку надзвичайно важко відстежити після міграції.

Фаза 2: Оцініть і виберіть правильний рівень хостингу

Вибір неправильного рівня хостингу є структурною помилкою, яка змушує виконувати повторну міграцію протягом кількох місяців. Зіставте результати аудиту з правильним класом інфраструктури.

Порівняння рівнів хостингу

Ключове правило вибору: Якщо ваш застосунок потребує специфічної конфігурації PHP-FPM пулу, підключень Redis через сокет, власних правил перезапису Nginx або будь-якого фонового процесу-демона, спільний хостинг є архітектурно несумісним. Вам потрібен щонайменше VPS з root-доступом.

Для сайтів на WordPress або Joomla з помірним трафіком VPS з cPanel забезпечує знайомий інтерфейс панелі керування, зберігаючи при цьому ізоляцію та продуктивність віртуальної машини.

Критерії оцінки провайдера

Окрім маркетингових заяв, оцінюйте провайдерів за цими перевіреними технічними факторами:

• SLA щодо доступності з пунктами про фінансові штрафи — SLA 99.9% без компенсації не має сенсу
• Рейтинг рівня дата-центру (Tier III або Tier IV для виробничих навантажень)
• Мережева надлишковість — BGP multi-homing, кілька провайдерів upstream
• Тип сховища — NVMe SSD проти SATA SSD проти жорсткого диска (різниця у затримці є суттєвою)
• Політика резервного копіювання — частота, термін зберігання, чи зберігаються резервні копії поза сайтом
• SLA часу відповіді підтримки — розрізняйте час першої відповіді та час вирішення проблеми

Фаза 3: Створіть і перевірте повну резервну копію

Жодна міграція не повинна починатися без перевіреної, придатної для відновлення резервної копії. «Перевірена» означає, що ви фактично протестували відновлення — а не просто підтвердили існування файлу резервної копії.

Що повинна включати повна резервна копія

• Файли кореневої директорії веб-сайту — весь кореневий каталог документів, включаючи приховані файли, як-от .htaccess та .env
• Всі бази даних — експортовані як дампи .sql, а не просто копія директорії бази даних
• Дані електронної пошти — якщо ви використовуєте Поштовий хостинг, прив’язаний до вашого домену, експортуйте поштові скриньки до будь-яких змін DNS
• Завдання Cron — crontab -l > crontab_backup.txt
• SSL-сертифікати та приватні ключі — якщо використовується комерційний сертифікат, експортуйте повний ланцюжок
• Файли конфігурації сервера — /etc/nginx/, /etc/apache2/, /etc/php/, власні налаштування my.cnf

Виконання експорту бази даних

Для MySQL/MariaDB використовуйте mysqldump з параметрами, що забезпечують повну точність:

mysqldump 
  --single-transaction 
  --routines 
  --triggers 
  --events 
  --set-gtid-purged=OFF 
  -u root -p your_database_name > database_backup_$(date +%F).sql

Прапорець --single-transaction є критично важливим для таблиць InnoDB — він робить узгоджений знімок без блокування таблиць, що означає, що ваш живий сайт продовжує обслуговувати запити під час дампу.

Перевірка цілісності резервної копії

# Check the SQL dump is not truncated
tail -5 database_backup_2024-01-15.sql

# Verify file count in web root backup
tar -tzf webroot_backup.tar.gz | wc -l

# Test restoration to a local or staging environment
mysql -u root -p test_restore_db < database_backup_2024-01-15.sql

Резервна копія, відновлення якої ви не тестували, — це не резервна копія, а хибне відчуття безпеки.

Фаза 4: Перевірте сумісність на цільовому сервері

Перш ніж переносити виробничі дані, розгорніть нове середовище та перевірте сумісність за допомогою підходу зі staging-середовищем.

Перевірка версії PHP та розширень

# On the destination server
php -v
php -m | grep -E 'mbstring|curl|gd|imagick|redis|zip|intl|opcache'

Порівняйте цей результат з вашим переліком з Фази 1. Будь-яке відсутнє розширення необхідно встановити до міграції, а не після.

Перевірка сумісності бази даних

При міграції з MySQL 5.7 на MySQL 8.0 (поширений сценарій) зверніть увагу на такі критичні зміни:

• Кодування utf8mb3 є застарілим; стовпці можуть потребувати явних оголошень кодування
• Поведінка GROUP BY змінилася — запити, що працювали у версії 5.7, можуть не виконуватися у версії 8.0 без коригування режиму ONLY_FULL_GROUP_BY
• NO_ZERO_DATE увімкнено за замовчуванням у суворому режимі, що відхиляє поля дати, які містять 0000-00-00

Протестуйте ваш SQL-дамп на цільовій версії MySQL перед переключенням виробничого трафіку.

Переклад конфігурації веб-сервера

При міграції з Apache на Nginx (частий сценарій при переході на продуктивно оптимізований VPS) ваші правила .htaccess не транслюються автоматично. Поширені перетворення:

Перенаправлення Apache .htaccess:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Еквівалент Nginx у блоці server:

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

Пропуск цього перетворення є однією з найпоширеніших причин помилок 404 та циклів перенаправлення після міграції.

Фаза 5: Виконайте міграцію з мінімізацією простою

Стратегічно оберіть вікно міграції

Проаналізуйте Google Analytics або журнали сервера, щоб визначити вікно з найнижчим трафіком — зазвичай між 02:00 та 05:00 за часовим поясом основної аудиторії у вівторок або середу. Уникайте п’ятниць; якщо щось піде не так, ваші можливості підтримки суттєво звужуються на вихідних.

Робочий процес міграції з попереднім staging-середовищем

1. Направте субдомен на новий сервер (наприклад, staging.example.com) за допомогою A-запису, не торкаючись виробничого DNS
2. Перенесіть усі файли та бази даних на новий сервер
3. Оновіть рядок підключення до бази даних застосунку, щоб він вказував на нову базу даних
4. Змініть ваш локальний файл /etc/hosts, щоб виробничий домен розпізнавався як IP нового сервера — це дозволяє вам тестувати повну виробничу конфігурацію без впливу на живих користувачів:

# Add to /etc/hosts on your local machine
203.0.113.50  example.com www.example.com

1. Проведіть повне функціональне тестування — кожну форму, платіжний процес, систему входу, кінцеву точку API та завантаження медіафайлів
2. Запустіть бенчмарки продуктивності за допомогою ab (Apache Benchmark) або wrk:

ab -n 1000 -c 50 https://example.com/

1. Лише після проходження всіх тестів переходьте до перемикання DNS

Конфігурація SSL-сертифіката

Переконайтеся, що ваш SSL-сертифікат встановлено та перевірено на новому сервері до перемикання DNS. Якщо використовується Let’s Encrypt:

certbot --nginx -d example.com -d www.example.com

Якщо використовується комерційний сертифікат від провайдера, як-от ті, що доступні через SSL-сертифікати, встановіть повний ланцюжок сертифікатів (сертифікат + проміжний CA + кореневий CA), щоб уникнути помилок перевірки ланцюжка на старих клієнтах.

Фаза 6: Перемикання DNS — найбільш технічно чутливий крок

Поширення DNS широко неправильно розуміється. Цифра 48 годин є максимальним порогом у найгіршому випадку, а не типовою тривалістю. На практиці більшість резолверів дотримуються значення TTL запису, що змінюється.

Зменшення TTL перед перемиканням

Щонайменше за 24–48 годин до вікна міграції зменшіть TTL ваших A-записів та CNAME-записів до 300 секунд (5 хвилин):

example.com.    300  IN  A  203.0.113.50
www.example.com. 300 IN  A  203.0.113.50

Це означає, що після оновлення запису на новий IP стара кешована версія закінчиться протягом 5 хвилин для більшості резолверів — а не через 48 годин. Це найбільш ефективна техніка для мінімізації вікна поширення DNS.

Оновлення Name Server проти A-запису

Існують два різних підходи до перемикання DNS:

• Зміна лише A-записів (зі збереженням тих самих авторитативних nameserver): Поширення відповідає TTL запису. Найшвидший підхід, якщо ваш реєстратор домену дозволяє пряме керування записами.
• Зміна nameserver (вказівка на DNS нового хоста): TTL nameserver зазвичай становить 24–48 годин і не знаходиться під вашим прямим контролем. Цей підхід займає більше часу.

За можливості надавайте перевагу оновленням A-записів. Керуйте DNS вашого домену через панель керування Реєстрації домену для прямого контролю на рівні записів.

Збереження активності старого сервера під час поширення

Не скасовуйте та не вимикайте старий хостинг-план одразу після перемикання DNS. Тримайте його активним щонайменше 72 години. Під час поширення частина ваших користувачів все ще буде звертатися до старого IP — ці запити повинні продовжувати обслуговуватися. Передчасне вимкнення старого сервера створює реальний збій для цих користувачів.

Фаза 7: Моніторинг та перевірка після міграції

Моніторинг доступності та продуктивності

Налаштуйте зовнішній моніторинг доступності одразу після перемикання DNS — а не після того, як ви вважаєте, що поширення завершено. Інструменти для розгортання:

• UptimeRobot або Better Uptime — HTTP(S)-перевірки кожні 1–5 хвилин з кількох географічних місць
• Google Search Console — стежте за звітами Coverage та Core Web Vitals на наявність аномалій протягом 7 днів після міграції
• New Relic або Datadog — моніторинг продуктивності на рівні застосунку, якщо ваш застосунок цього потребує

Виявлення та усунення помилок після міграції

Негайно виконайте сканування нового сайту за допомогою Screaming Frog або дзеркала wget:

wget --spider --recursive --no-verbose --output-file=crawl_log.txt https://example.com
grep -i "broken|404|error" crawl_log.txt

Поширені проблеми після міграції та їх причини:

Виправлення жорстко закодованих URL у базах даних WordPress

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

wp search-replace 'http://old-domain.com' 'https://new-domain.com' 
  --all-tables 
  --precise 
  --report-changed-only

Прапорець --precise правильно обробляє серіалізовані дані PHP, які наївна заміна рядків пошкоджує.

Фаза 8: Скасуйте старий хостинг-план

Скасовуйте старий план лише після підтвердження всіх наступних умов:

• Поширення DNS завершено (перевірте за допомогою dig +trace example.com з кількох місць)
• Моніторинг доступності показує 100% доступність протягом щонайменше 72 послідовних годин
• Жодних помилок 404 або непрацюючих посилань не виявлено в журналах сканування
• Доставка електронної пошти функціонує правильно на новому сервері
• Аналітика показує нормальні шаблони трафіку без аномальних падінь
• У вас є локальна копія всіх файлів резервних копій, незалежна від обох хостинг-провайдерів

Технічний контрольний список ключових висновків

Використовуйте це як контрольний список виконання міграції:

До міграції

• [ ] Експортовано базовий показник використання ресурсів за 90 днів (CPU, RAM, I/O, пропускна здатність)
• [ ] Задокументовано повний програмний стек з точними номерами версій
• [ ] TTL DNS зменшено до 300 секунд щонайменше за 24 години до перемикання
• [ ] Створено та протестовано повну резервну копію (файли + бази даних + завдання cron + електронна пошта)
• [ ] Перевірено версію PHP та всі необхідні розширення на цільовому сервері
• [ ] Правила .htaccess переведено у формат Nginx при зміні веб-серверів
• [ ] SSL-сертифікат встановлено та перевірено на новому сервері до зміни DNS

Під час міграції

• [ ] Файли перенесено за допомогою rsync з перевіркою контрольної суми (rsync -avz --checksum)
• [ ] База даних імпортована та перевірено відповідність кількості рядків джерелу
• [ ] Повна функціональність сайту протестована через перевизначення /etc/hosts до зміни DNS
• [ ] Оновлено файли конфігурації застосунку (хост бази даних, облікові дані, URL сайту)

Після міграції

• [ ] Зовнішній моніторинг доступності активовано протягом 5 хвилин після перемикання DNS
• [ ] Старий сервер залишається активним щонайменше 72 години після перемикання
• [ ] Повне сканування сайту завершено; всі помилки 404 та непрацюючі посилання усунено
• [ ] Жорстко закодовані URL виправлено в базі даних (особливо для WordPress)
• [ ] Google Search Console відстежується протягом 7 днів після міграції
• [ ] Старий хостинг-план скасовано лише після підтвердження всіх вищезазначених пунктів

Часті запитання

Скільки насправді триває поширення DNS і чи можна його прискорити?

Тривалість поширення DNS визначається значенням TTL запису, що змінюється, а не фіксованим вікном у 48 годин. Якщо ви зменшите TTL вашого A-запису до 300 секунд щонайменше за 24 години до міграції, більшість резолверів підхоплять новий IP протягом 5–10 хвилин після зміни. Цифра 48 годин стосується змін делегування nameserver, TTL яких знаходиться поза вашим контролем.

Чи вплине міграція на новий хост на мої позиції в пошуку Google?

Правильно виконана міграція без простою, зі збереженою структурою URL та дійсним SSL не має негативного впливу на SEO. Позиції можуть тимчасово знизитися, якщо новий сервер повільніший, якщо URL змінюються без належних 301-перенаправлень або якщо сайт недоступний під час сканування. Відстежуйте звіти Coverage та Core Web Vitals у Google Search Console протягом 14 днів після міграції.

Який найбезпечніший спосіб перенести великі бази даних без пошкодження даних?

Використовуйте mysqldump з прапорцем --single-transaction для таблиць InnoDB, щоб забезпечити узгоджений знімок без блокування таблиць. Передавайте файл дампу через SSH за допомогою scp або rsync, а не через phpMyAdmin, який має обмеження розміру файлу та обмеження часу очікування, що призводять до непомітного усічення великих баз даних.

Чи потрібно перевстановлювати SSL-сертифікат після міграції?

Так. SSL-сертифікати прив’язані до приватного ключа сервера, який знаходиться на оригінальному сервері. Вам необхідно або перевипустити сертифікат на новому сервері (безкоштовно для Let’s Encrypt), або експортувати приватний ключ та ланцюжок сертифікатів зі старого сервера та встановити їх на новому. Переконайтеся, що сертифікат повністю перевірено до оновлення DNS, щоб HTTPS працював одразу після перемикання.

Як перевірити, що міграція завершена, перш ніж скасовувати старий план?

Виконайте dig +trace example.com @8.8.8.8 та dig +trace example.com @1.1.1.1, щоб підтвердити, що резолвери Google і Cloudflare повертають IP нового сервера. Перевірте моніторинг доступності протягом 72 послідовних годин чистих відповідей. Виконайте сканування сайту на помилки 404 та перевірте доставку електронної пошти. Лише після проходження всіх цих перевірок безпечно завершувати старий хостинг-акаунт.