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

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

Міграція сервера — це не просте копіювання та вставка. Особливо для WordPress, WooCommerce, Laravel, самописних PHP-застосунків, новинних порталів із високою відвідуваністю або бізнесів із корпоративною поштою неправильне перенесення може призвести до втрати замовлень, проблем із кириличним кодуванням, помилок 500, сповіщень SSL, перебоїв у роботі пошти та падіння позицій у пошукових системах. Тому міграція має виконуватися за чітким планом, із технічним чеклістом і сценарієм відкату.

У цьому посібнику ми покроково розглянемо, як змінити хостинг або сервер відповідно до вимог SEO та продуктивності у 2026 році. Також ми обговоримо різні сценарії: міграцію через cPanel, Plesk, VPS, хмарний сервер і ручне перенесення; поділимося практичними порадами щодо часу DNS-оновлення, обсягу бекапу, сумісності баз даних, встановлення SSL та SEO-перевірок після переїзду.

Коли потрібна міграція сервера?

Потреба перенести вебсайт на новий сервер зазвичай виникає через вимоги до продуктивності, безпеки, бюджету або масштабування. Наприклад, корпоративний сайт із 5 000 відвідувачів на місяць може стабільно працювати на віртуальному хостингу, тоді як інтернет-магазин із 20 000 відвідувачів на добу може стикатися з перевищенням лімітів CPU, повільними запитами та тайм-аутами на сторінці оплати. У такому разі варто обрати потужніший тарифний план, VPS або хмарну інфраструктуру.

Поширені сигнали, що вказують на необхідність міграції:

• Час завантаження сторінки перевищує 3 секунди, а показники Core Web Vitals погіршилися.
• У панелі керування хостингом часто закінчуються ліміти CPU, RAM, inode або дискового простору.
• Потрібне оновлення версій PHP, MySQL, MariaDB, Node.js або ionCube.
• Регулярно виникають проблеми з оновленням SSL, доставкою листів або керуванням DNS.
• Поточний провайдер не забезпечує належного рівня підтримки, бекапу або безпеки.
• Трафік сайту різко зростає під час рекламних кампаній або сезонних розпродажів.

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

Підготовка до міграції: найважливіший етап

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

1. Проведіть інвентаризацію сайту

Перший крок — створити технічну карту вебсайту. Слід занотувати використовувану CMS або фреймворк, версію PHP, тип бази даних, обсяг диска, поштові скриньки, cron-завдання, DNS-записи, SSL-сертифікат, спеціальні переспрямування та сторонні інтеграції. Наприклад, для сайту на WordPress недостатньо перенести лише папку wp-content; необхідно також перевірити правила .htaccess, налаштування wp-config.php, префікси таблиць бази даних, плагіни кешування та медіафайли.

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

2. Зробіть повний бекап і перевірте його

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

• Файли вебсайту: public_html, папки застосунків, директорії завантажень, файли тем і плагінів.
• Бази даних: MySQL, MariaDB, PostgreSQL або інші бази даних, які використовує застосунок.
• Поштові дані: скриньки, переспрямування, фільтри, налаштування автовідповідачів.
• DNS-записи: записи A, AAAA, CNAME, MX, TXT, SPF, DKIM, DMARC.
• Конфігурації: .htaccess, nginx.conf, php.ini, cron-завдання, файли оточення.
• SSL-сертифікати та спеціальні правила безпеки.

Як практичний підхід, перед міграцією варто зробити щонайменше дві копії бекапу: одну залишити на поточному сервері, іншу зберегти в іншому місці. Для великих сайтів можна використовувати rsync для файлів і mysqldump або інструменти панелі керування для бази даних. Для баз даних обсягом понад 10 ГБ безпечніше використовувати стиснуті та розділені на частини дампи, а не один великий файл.

3. Заздалегідь знизьте значення TTL DNS

Щоб зміни DNS поширилися швидше, рекомендується знизити значення TTL за 24 години до міграції. Наприклад, якщо TTL становить 14400 секунд, деякі користувачі можуть годинами продовжувати потрапляти на старий сервер. Зменшення TTL до 300 секунд перед міграцією робить перехід більш контрольованим. Після завершення міграції та перевірки всього можна знову збільшити TTL до 3600 або 14400 секунд.

Правильне керування DNS вашого домену безпосередньо впливає на успіх міграції. Ви можете ознайомитися з посібниками Перевірка домену та управління доменним ім'ям для налаштування домену та DNS.

Порівняння методів міграції сервера

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

Вибираючи нову інфраструктуру, орієнтуватися лише на дисковий простір — помилка. На продуктивність також впливають такі критерії, як кількість PHP-воркерів, ядра CPU, RAM, NVMe-диски, частота бекапів, розташування дата-центру, підтримка LiteSpeed або Nginx, WAF і DDoS-захист. Тому перехід на найдешевший пакет без аналізу потреб може швидко призвести до необхідності нової міграції.

Покрокова інструкція з міграції сервера

Крок 1: Підготуйте новий сервер

На новому сервері необхідно встановити операційну систему, вебсервер, версію PHP, сервіс бази даних і необхідні модулі. Для WordPress рекомендується PHP 8.2 або 8.3, актуальна MariaDB, OPcache і відповідне значення memory_limit. Для фреймворків на кшталт Laravel потрібно окремо налаштувати Composer, cron, queue worker і права доступу до storage. Якщо на новому сервері відсутні PHP-розширення, які були на старому, після міграції сайт може видавати білий екран або помилку 500.

У плані безпеки слід налаштувати політику SSH-портів, надійні паролі, фаєрвол, сканування на шкідливе ПЗ та автоматичні оновлення. Закласти основу безпеки на порожньому сервері до міграції набагато легше, ніж виправляти щось потім. Якщо вам потрібен SSL, обов'язково додайте встановлення сертифіката SSL до плану міграції.

Крок 2: Перенесіть файли

Залежно від розміру сайту для передачі файлів можна використовувати FTP, SFTP, SSH, rsync або бекап панелі керування. Для невеликих сайтів достатньо створити стиснутий архів і розпакувати його на новому сервері. Для великих сайтів рекомендується зробити першу копію через rsync, а безпосередньо перед зміною DNS виконати другу синхронізацію. Цей метод економить час, особливо для сайтів, де папка завантажень постійно змінюється.

Після передачі файлів перевірте права доступу. Зазвичай для папок встановлюються права 755, для файлів — 644; однак потреби кожного застосунку можуть відрізнятися. Конфіденційні файли, такі як wp-config.php, .env тощо, не повинні бути доступними для читання всім. Також переконайтеся, що приховані файли, як-от .htaccess і .user.ini, були скопійовані.

Крок 3: Перенесіть базу даних

Перенесення бази даних — найвідповідальніший етап для запобігання втраті даних. Спочатку зі старого сервера знімається дамп, потім на новому сервері створюється база даних і користувач. Кодування слід по можливості встановити як utf8mb4. Щоб уникнути проблем із кириличними символами, під час експорту та імпорту необхідно зберігати однакову структуру collation.

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

Крок 4: Оновіть конфігураційні файли

Назву бази даних, ім'я користувача, пароль, хост і шляхи до файлів потрібно відредагувати відповідно до нового сервера. Для WordPress це wp-config.php, для Laravel — .env, для самописних застосунків — config.php або аналогічні файли. Якщо залишаться абсолютні шляхи, IP-адреси, SMTP-налаштування або директорії кешу зі старого сервера, сайт може візуально відкриватися, але генерувати помилки у фоновому режимі.

Крім того, значення PHP memory_limit, upload_max_filesize, post_max_size і max_execution_time слід налаштувати відповідно до потреб вашого застосунку. Наприклад, якщо адмінпанель дозволяє завантажувати зображення товарів обсягом 200 МБ, а ліміт завантаження залишиться на рівні 32 МБ, операційна діяльність буде неможливою, навіть якщо міграція пройшла успішно.

Крок 5: Протестуйте перед зміною DNS

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

Чекліст тестування має включати такі перевірки:

• Чи відкриваються головна сторінка, категорії, товари, блог і контактна сторінка?
• Чи працюють відправка форм, вхід для користувачів, скидання пароля та платіжний процес?
• Чи повністю завантажуються зображення, CSS і JavaScript файли?
• Чи відкривається адмінпанель без помилок?
• Чи встановлено SSL-сертифікат для правильного домену?
• Чи є помилки 404, 500, mixed content або цикли переспрямування?
• Чи правильні файли robots.txt, sitemap.xml і канонічні теги?

Крок 6: Встановіть SSL-сертифікат

Для сучасних вебсайтів SSL є обов'язковим не лише з міркувань безпеки, а й для SEO та довіри користувачів. Якщо змінити DNS до встановлення SSL на новому сервері, користувачі можуть побачити попередження про небезпечне з'єднання. Тому SSL-сертифікат слід підготувати безпосередньо перед або одночасно з перемиканням DNS. Безкоштовних сертифікатів, як-от Let's Encrypt, може бути достатньо для багатьох сайтів; для корпоративних проєктів, що приймають платежі, можна обрати SSL-сертифікати з вищим рівнем валідації.

Після встановлення SSL переконайтеся, що HTTP-адреси переспрямовуються на HTTPS за допомогою 301 редиректу, відсутня помилка mixed content, а в карті сайту вказані HTTPS URL-адреси. Ви можете переглянути сертифікати SSL для отримання інформації про продукти та варіанти встановлення SSL.

Крок 7: Змініть DNS-записи

Після успішного завершення тестів A-запис DNS спрямовується на IP-адресу нового сервера. Якщо поштовий сервіс також переноситься на цей сервер, необхідно оновити записи MX, SPF, DKIM і DMARC. Якщо пошта залишається в іншого провайдера, записи MX змінювати не можна. Одна з найпоширеніших помилок — випадково змінити поштові записи, коли потрібно перенести лише вебсайт, що призводить до перебоїв у доставці листів.

Оновлення DNS-кешу зазвичай триває від кількох хвилин до 24 годин. Якщо TTL було заздалегідь знижено, більшість користувачів швидко потраплять на новий сервер. Не вимикайте старий сервер одразу. Безпечною практикою є тримати його доступним щонайменше 48 годин, а краще — 72 години.

Крок 8: Виконайте фінальну синхронізацію та перевірку логів

Після зміни DNS слід перевірити, чи не було записано нових даних на старому сервері. Особливо це стосується замовлень, контактних форм, реєстрацій користувачів і коментарів. Файли access log і error log вебсервера допоможуть зрозуміти, які IP-адреси надсилали запити на який сервер.

Протягом перших 24 годин після міграції необхідно відстежувати помилки 500, збільшення кількості помилок 404, повільні запити, стрибки CPU та поштові черги. Без цих перевірок сайт може виглядати працездатним, але у фоновому режимі відбуватиметься втрата конверсій.

Професійний чекліст для міграції сайту без втрати даних

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

• Час міграції заплановано на години з низьким трафіком.
• Зроблено повний бекап файлів, бази даних, пошти та DNS.
• Перевірено, що бекап можна розпакувати та відновити.
• Значення TTL DNS знижено щонайменше за 24 години до початку.
• На новому сервері підготовлено PHP, базу даних і необхідні модулі.
• Файли перенесено повністю, права доступу перевірено.
• Перевірено сумісність кодування та collation бази даних.
• Конфігураційні файли оновлено відповідно до даних нового сервера.
• Проведено тестування через файл hosts до запуску в продакшн.
• Встановлено SSL, перевірено HTTPS-переспрямування.
• Записи DNS A, AAAA, MX, TXT оновлено коректно.
• Старий сервер залишався активним щонайменше 48 годин.
• Проводився моніторинг Google Search Console, Analytics і лог-файлів.

Перевірки після міграції, щоб уникнути втрати позицій SEO

Теоретично міграція сервера не повинна спричиняти втрату позицій SEO, якщо структура URL не змінюється. Однак на практиці повільна робота, помилки 404, неправильний robots.txt, відсутність SSL або помилки переспрямування можуть вплинути на позиції. Тому SEO-перевірка після міграції така ж важлива, як і технічна міграція.

Перевірка URL-адрес і переспрямувань

Якщо під час міграції ви не змінюєте структуру URL, потреба в 301 редиректах мінімальна. Однак, якщо одночасно змінюється домен, структура пермалінків або папок, старі URL-адреси слід переспрямувати на нові відповідники за допомогою 301 редиректу. Тимчасовий 302 редирект не підходить для постійної передачі SEO-сигналів. Наприклад, якщо стара сторінка /product/abc переїхала на нову адресу /shop/abc, слід налаштувати пряме переспрямування; редірект усіх старих URL на головну сторінку негативно впливає на користувацький досвід і SEO.

Перевірка robots.txt і Sitemap

Якщо під час тестування для блокування пошукових систем у robots.txt використовувався Disallow, після запуску його слід прибрати. Ця помилка є однією з найпоширеніших причин втрати індексації після міграції. Файл Sitemap має містити нові HTTPS URL-адреси, і його слід повторно надіслати через Google Search Console.

Продуктивність і Core Web Vitals

Навіть якщо новий сервер потужніший, неправильні налаштування кешу можуть знизити продуктивність. LiteSpeed Cache, Redis, OPcache, CDN і оптимізацію зображень слід налаштувати правильно. Протягом першого тижня після міграції потрібно відстежувати показники LCP, INP і CLS за допомогою PageSpeed Insights, Chrome UX Report і логів сервера, щоб перевірити, чи немає погіршень. Для покращення продуктивності хостингу ви можете скористатися матеріалами Оптимізація швидкості WordPress.

На що звернути увагу під час міграції пошти

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

На рівні DNS запис MX визначає поштовий сервер, SPF — дозвіл на відправку, DKIM — підпис, а DMARC — політику домену. Якщо ці записи налаштовані неправильно, листи можуть потрапляти в спам або повністю відхилятися. Після міграції слід надіслати тестові листи на Gmail, Outlook і корпоративні скриньки та перевірити заголовки листів.

Поширені помилки під час міграції сервера

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

• Виконання міграції без бекапу або без перевірки його працездатності.
• Зміна IP-адреси без попереднього зниження TTL DNS.
• Вимкнення старого сервера до завершення оновлення DNS-кешу.
• Неправильне перенесення кодування бази даних і проблеми з кирилицею.
• Забування правил переспрямування в .htaccess або nginx.
• Спрямування HTTPS-трафіку на новий сервер без встановлення SSL.
• Неправильне оновлення поштових записів MX і TXT.
• Залишення плагіна кешування з налаштуваннями шляхів старого сервера.
• Відсутність моніторингу Search Console і логів після міграції.

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

Коли варто звернутися за професійною підтримкою міграції?

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

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

Висновок: спланована міграція сервера запобігає простою та втраті даних

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

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

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

Скільки часу займає міграція сервера?

Час залежить від розміру та складності сайту. Невеликий сайт на WordPress можна перенести за 30-60 хвилин, тоді як для великих проєктів електронної комерції або корпоративних проєктів із великою кількістю пошти процес, включаючи підготовку, тестування та оновлення DNS-кешу, може тривати 1-3 дні.

Чи буде мій сайт недоступний під час міграції сервера?

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

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

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

Чи впливає міграція сервера на позиції SEO?

Якщо структура URL збережена, сайт працює швидко, SSL і переспрямування налаштовані правильно, міграція сервера сама по собі не спричиняє втрати позицій SEO. Однак помилки 404, неправильний robots.txt, повільний сервер або некоректні 301 редиректи можуть негативно вплинути на позиції.

Чи переносяться поштові скриньки під час міграції сервера?

Якщо пошта розміщена на старому хостингу, її потрібно переносити окремо. Слід перевірити поштові скриньки, переспрямування, фільтри та записи MX, SPF, DKIM, DMARC. Якщо пошта залишається в іншого провайдера, записи MX змінювати не потрібно.