Міграція хостингу без даунтайму: як переїхати і не втратити жодного відвідувача

Уявіть: ви переїжджаєте з однієї квартири в іншу, але вам потрібно, щоб гості навіть не помітили, що адреса змінилася. Двері мають відчинятися, світло - горіти, вода - текти. Саме так виглядає міграція хостингу для працюючого сайту. Один невдалий крок - і ваші клієнти бачать білий екран замість каталогу товарів. Пошукові системи фіксують помилки 5xx і тихенько опускають вас у видачі. Рекламний бюджет зливається в нікуди. Я пройшов через десятки переїздів - від маленьких блогів до проєктів із 200 000 відвідувачів на добу - і зараз розкажу, як зробити це правильно.

Коли переїзд - не примха, а необхідність

Багато хто відкладає міграцію роками, бо "працює ж". Але є ситуації, коли зволікання коштує реальних грошей. Ось п'ять маркерів того, що час пакувати валізи:

• Сервер регулярно не витримує піки - у чорну п'ятницю чи під час рекламних кампаній сайт лягає
• Техпідтримка відповідає довше, ніж ваш дедлайн - тікет висить 48 годин, а проблема критична
• Вартість зросла, але якість - ні - провайдер підняв ціни на 30%, а uptime залишився на рівні 99.5%
• Потрібна інша географія серверів - ви вийшли на європейський ринок, а дата-центр стоїть у Сінгапурі
• Технологічний стек застарів - потрібен PHP 8.3, а хостер пропонує максимум 7.4

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

Анатомія безшовного переїзду: 7 кроків без паніки

Я розбив процес на конкретні етапи, які працюють для 90% сайтів - від WordPress-блогів до кастомних SaaS-платформ. Головне правило: ніколи не перемикайте DNS, поки не переконалися, що новий сервер працює ідеально.

1. Аудит поточного стану. Зберіть повний список файлів, баз даних, cron-завдань, SSL-сертифікатів, поштових налаштувань. Забудете про один cron - і щоденна розсилка зникне без сліду.
2. Вибір нового хостингу та тестування. Замовте тариф, але не поспішайте. Розгорніть тестову копію сайту, проженіть через GTmetrix і навантажувальні тести.
3. Повне копіювання. Файли через rsync або SFTP, базу - через mysqldump. Для великих баз (понад 2 ГБ) використовуйте потокове копіювання - звичайний phpMyAdmin просто впаде.
4. Налаштування серверного оточення. Версії PHP, модулі Apache/Nginx, права доступу до папок, .htaccess або конфіги Nginx.
5. Перевірка через hosts-файл. Пропишіть IP нового сервера у файлі hosts на вашому комп'ютері. Тепер ви бачите сайт на новому хостингу, а всі інші - ще на старому.
6. Фінальна синхронізація. Перед перемиканням DNS зробіть повторний дамп бази, щоб підхопити свіжі замовлення, коментарі, реєстрації.
7. Перемикання DNS. Змініть A-запис і дочекайтеся повної пропагації. Старий хостинг тримайте ще 72 години як страхувальну сітку.

Сім кроків. Не три, не двадцять. Саме ця послідовність дозволяє мінімізувати ризик до мінімуму.

Файл hosts - ваш секретний тунель у майбутнє

Цей прийом настільки простий, що його часто ігнорують. А дарма. Файл hosts на вашій машині дозволяє "обдурити" браузер і направити домен на будь-яку IP-адресу - без зміни DNS. Тобто ви відкриваєте свій сайт, але бачите його вже на новому сервері. Решта світу нічого не помічає.

На Windows файл лежить у C:WindowsSystem32driversetchosts, на macOS та Linux - у /etc/hosts. Додаєте рядок виду:

185.123.45.67 vashdomen.com www.vashdomen.com

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

TTL і DNS-пропагація: чому переїзд "затягується" на добу

Найбільший страх під час міграції - момент перемикання DNS. Ви змінили A-запис, але частина користувачів ще годинами бачить старий сервер. Чому? Через TTL (Time To Live) - час, протягом якого DNS-резолвери кешують ваш запис.

"Більшість проблем із міграцією виникають не через технічні помилки, а через нетерплячість. Люди перемикають DNS із TTL 86400 секунд і дивуються, чому через годину половина трафіку ще йде на старий сервер." - Matt Mullenweg, співзасновник WordPress, інтерв'ю для WP Tavern, 2023

Золоте правило: за 24-48 годин до міграції знизьте TTL до 300 секунд (5 хвилин). Тоді після зміни A-запису більшість користувачів побачать новий сервер вже через 5-15 хвилин, а не через добу.

Після завершення міграції та стабілізації поверніть TTL на 3600-86400. Низький TTL збільшує кількість DNS-запитів і трохи уповільнює перший візит.

Чек-лист після переїзду: що перевірити у перші 72 години

Ви перемкнули DNS, сайт відкривається з нового сервера. Ура! Але розслаблятися рано. Перші три доби - це період, коли помилки ще можна зловити до того, як вони нашкодять SEO та продажам.

1. SSL-сертифікат. Переконайтеся, що HTTPS працює коректно. Якщо використовуєте Let's Encrypt - перевипустіть сертифікат на новому сервері.
2. Пошта. Надішліть тестовий лист на всі корпоративні адреси. MX-записи могли "загубитися" при переїзді.
3. Форми зворотного зв'язку та оплати. Оформіть тестове замовлення. Якщо платіжний шлюз прив'язаний до IP - оновіть whitelist.
4. Cron-завдання. Перевірте, що всі заплановані скрипти працюють за розкладом.
5. 301-перенаправлення. Переконайтеся, що старі URL коректно перенаправляються, якщо структура змінилася.
6. Google Search Console. Слідкуйте за помилками сканування протягом тижня. Спайк помилок 5xx - сигнал, що щось не так.

Я зазвичай тримаю старий хостинг активним ще 7 днів після переїзду. Це коштує декілька доларів, але дає можливість миттєво відкотитися, якщо щось піде не так. Думайте про це як про страховку - краще не знадобиться, але мати її обов'язково.

Автоматизація проти ручного режиму: що обрати

Зараз майже кожен хостинг-провайдер пропонує "безкоштовну міграцію". SiteGround, Cloudways, Kinsta - всі мають або плагіни, або команду, яка переїде за вас. Чи варто довіряти?

Коротка відповідь: для простих сайтів - так. Для складних проєктів - з обережністю.

Плагін All-in-One WP Migration, наприклад, ідеально справляється з сайтами до 1 ГБ. Але якщо у вас мультисайт із кастомними таблицями в базі, двадцятьма мікросервісами і нестандартними серверними правилами - ніякий плагін не замінить людину, яка розуміє, що відбувається "під капотом".

Мій підхід: навіть коли використовую автоматичні інструменти, завжди перевіряю результат вручну. Автоматизація скорочує час, але не знімає відповідальності.

Найгірше, що може статися - і як до цього підготуватися

Давайте будемо чесними. Помилки трапляються. У мене одного разу під час міграції інтернет-магазину "зникли" 340 замовлень за останню годину - я зробив дамп бази о 14:00, а DNS перемкнув о 15:30. Півтори години замовлень залишилися на старому сервері. Добре, що я тримав доступ до старої бази і зміг вручну імпортувати ті записи за 20 хвилин.

Ось три найчастіші катастрофи та їхні "вогнегасники":

• Втрата свіжих даних - рішення: робіть фінальний дамп бази буквально за 5 хвилин до перемикання DNS
• Некоректні права доступу до файлів - рішення: перевіряйте chmod для uploads, tmp, cache директорій одразу після копіювання
• "Змішаний" трафік - рішення: низький TTL + моніторинг обох серверів протягом перших 24 годин

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

А тепер питання до вас: коли ви востаннє перевіряли, чи справді ваш поточний хостинг заслуговує на ту суму, яку ви щомісяця йому платите? Можливо, саме зараз - найкращий час, щоб це з'ясувати.