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

Уявіть: ви переїжджаєте в нову квартиру, але при цьому в старій досі горить світло, працює холодильник і навіть сусіди думають, що ви нікуди не ділися. Саме так має виглядати ідеальна міграція хостингу - непомітна для всіх, крім вас. На практиці ж більшість переїздів нагадують евакуацію під обстрілом: щось загубили, щось зламали, сайт лежить годину-дві, а Google вже встиг проіндексувати порожню сторінку з помилкою 503. Я бачив проєкти, де втрата 40 хвилин аптайму коштувала $3 000 недоотриманого доходу. І все це - через поспіх та ігнорування простих правил, які ми зараз розберемо.

Чому більшість переїздів закінчуються нервовим зривом

Головна проблема не в технічній складності. Проблема - у відсутності плану. Серйозно. За моїм досвідом, 7 з 10 міграцій починаються зі слів: «Та що тут складного, просто скопіюємо файли і все». А потім виявляється, що забули про базу даних, cron-завдання, SSL-сертифікат, кеш DNS і ще десяток дрібниць, кожна з яких може покласти сайт.

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

Ось типові причини, чому міграція перетворюється на катастрофу:

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

Анатомія ідеальної міграції: 9 кроків без паніки

Ок, давайте розкладемо весь процес на конкретні етапи. Не абстрактні поради в дусі «будьте обережні», а чіткий алгоритм, який я використовую вже років сім і який жодного разу не підвів.

1. Аудит поточного хостингу - запишіть усе: версія PHP, MySQL, модулі Apache/Nginx, cron-завдання, поштові скриньки, SSL. Буквально все.
2. Зниження TTL DNS - за 24-48 годин до переїзду поставте TTL на 300 секунд (5 хвилин). Це дасть змогу швидко переключити трафік.
3. Налаштування нового сервера - встановіть ідентичне середовище. Та сама версія PHP, ті самі розширення, ті самі параметри.
4. Копіювання файлів - через rsync або SCP, не через FTP. FTP у 2025 році - це як пересилати документи голубом.
5. Перенесення бази даних - mysqldump на старому сервері, імпорт на новому. Перевірте кодування - utf8mb4 чи utf8.
6. Тестування на новому сервері - через hosts-файл або тимчасову URL перевірте кожну сторінку, форму, платіжний модуль.
7. Фінальна синхронізація - повторне копіювання лише змінених файлів і свіжий дамп бази.
8. Переключення DNS - змініть A-запис на нову IP-адресу. Завдяки низькому TTL зміни поширяться за хвилини.
9. Моніторинг 72 години - слідкуйте за логами, швидкістю, помилками. Старий хостинг не видаляйте мінімум тиждень.

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

Що саме копіювати і в якому порядку

Здавалося б, просте питання. Але саме тут ховається більшість підводних каменів. Давайте систематизуємо.

Зверніть особливу увагу на email. Я знаю випадок, коли інтернет-магазин після міграції три дні не отримував замовлення на пошту, бо MX-записи вказували в нікуди. Три дні. Уявіть масштаб втрат.

Zero-downtime: техніки, які працюють у реальному житті

«Нуль даунтайму» - це не маркетинговий міф. Це цілком досяжна мета, якщо використовувати правильні інструменти.

Техніка 1: Паралельна робота обох серверів. Не вимикайте старий сервер. Нехай обидва працюють одночасно. Коли DNS повністю переключиться (а це можна відстежити через dig або nslookup), старий сервер стає резервним.

Техніка 2: Зворотний проксі. Якщо у вас складна інфраструктура, поставте Cloudflare або інший CDN перед сайтом. Змініть origin-сервер у панелі CDN - і переключення відбудеться миттєво, без жодного очікування DNS-пропагації.

Техніка 3: Реплікація бази в реальному часі. Для великих проєктів з активною базою даних (інтернет-магазини, форуми, SaaS) можна налаштувати MySQL-реплікацію master-slave між старим і новим сервером. Коли все синхронізовано - перемикаєте трафік і робите slave новим master. Елегантно.

Найпростіший спосіб досягти нульового даунтайму для 90% звичайних сайтів - знизити TTL до 300 секунд і тримати старий сервер активним ще тиждень після міграції.

Чек-лист «після переїзду»: те, що всі забувають

Переключили DNS, сайт відкривається - перемога? Ні. Це лише половина роботи. Ось що треба зробити в наступні 72 години:

• Перевірте всі форми - контактні, замовлення, реєстрації. Часто SMTP-налаштування прив'язані до старого сервера.
• Запустіть краулер (Screaming Frog, Sitebulb) - пройдіться по всіх URL і переконайтеся, що немає 404 або 500 помилок.
• Перевірте Google Search Console - немає нових помилок сканування? Карта сайту доступна?
• Протестуйте швидкість через GTmetrix і PageSpeed Insights - новий сервер має бути швидшим, інакше навіщо переїзд?
• Оновіть URL у зовнішніх сервісах - Google Analytics, рекламні кабінети, платіжні шлюзи, якщо вони прив'язані до IP.

Коли варто наймати спеціаліста, а коли впоратися самому

Давайте чесно. Не кожен переїзд потребує DevOps-інженера за $100/годину. Але і не кожен можна зробити руками за допомогою YouTube-відео.

Ось мій простий фреймворк для прийняття рішення:

Переїзд простий (зробите самі за 2-4 години): статичний сайт або WordPress-блог без ecommerce, до 5 ГБ даних, немає кастомних серверних конфігурацій, один домен без піддоменів.

Переїзд середній (потрібна консультація або часткова допомога): WooCommerce або інший магазин з активними замовленнями, кілька доменів і піддоменів, кастомні cron-завдання і серверні правила, база даних понад 2 ГБ.

Переїзд складний (наймайте спеціаліста, без варіантів): кластерна інфраструктура з кількома серверами, кастомні мікросервіси і API, SLA з гарантією аптайму 99.9%+, юридичні вимоги до обробки даних (GDPR, PCI DSS).

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

А що з SEO? Google не покарає за переїзд?

Це питання я чую найчастіше. І відповідь радує: ні, Google не карає за зміну хостингу, якщо ви не зламали при цьому структуру URL. Домен залишається тим самим, контент - тим самим, посилання - тими самими. Для пошукових систем нічого не змінилося.

Але є підступний момент. Якщо під час міграції ваш сайт був недоступний навіть кілька годин і саме в цей час прийшов Googlebot - він може тимчасово «подумати», що з сайтом щось не так. Позиції можуть просісти на 1-2 тижні. Не критично, але неприємно. Саме тому переїзд варто робити в період найменшого трафіку - як правило, ніч з неділі на понеділок.

Ще одна порада: якщо ви змінюєте не тільки хостинг, а й регіон сервера (наприклад, з Європи в США), це може вплинути на швидкість завантаження для вашої цільової аудиторії. А швидкість - це фактор ранжування з 2021 року (Core Web Vitals). Тому обирайте дата-центр ближче до ваших відвідувачів.

Ось вам фінальна думка, яка змусить задуматися. Більшість людей відкладають міграцію хостингу роками, терплять повільний сервер, дорогий тариф або жахливу підтримку - тому що бояться «щось зламати». Але чим довше ви відкладаєте, тим більший сайт доведеться переносити і тим вищі ризики. Якщо ваш хостинг вас не влаштовує - коли ви плануєте діяти? Через рік, коли база виросте вдвічі?