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

Огляд

Односайтовий процес (гайд) масштабується лінійно — якщо його не заскриптувати. Що варто автоматизувати: синхронізацію файлів, дамп/імпорт бази й перевірки URL. Що варто не квапити: перемикання DNS (розносьте їх, щоб проблеми спливали по одному сайту) і пост-міграційну валідацію.

Що потрібно мати

  • Таблицю-інвентар: домен, розмір, розмір бази, потреби у версії PHP, особливі плагіни, хостинг пошти, реєстратор DNS/TTL.
  • Розгорнуті й захищені цільові сервери (див. практики агенцій).
  • Знижені до 300 с DNS TTL для кожного домену — за добу.

Покрокова інструкція

  1. Пріоритезуйте: почніть з найменшого низькоризикового сайту, щоб перевірити конвеєр; WooCommerce і високотрафікові лишіть наостанок (див. нотатки про WooCommerce щодо заморозки замовлень під час перемикання).
  2. Заскриптуйте переїзд сайту (старий хост → новий VPS):
    #!/bin/bash
    # migrate-site.sh domain olduser@oldhost /old/path dbname
    set -e
    DOMAIN=$1; SRC=$2; SRCPATH=$3; DB=$4
    rsync -az --exclude='wp-content/cache' $SRC:$SRCPATH/ /var/www/$DOMAIN/
    ssh $SRC "mysqldump $DB | gzip" | gunzip | mariadb ${DB}
    sudo chown -R www-data:www-data /var/www/$DOMAIN
  3. Тестуйте кожен сайт до DNS через override у hosts: головна, вхід, форми, один глибокий URL.
  4. Перемикайте хвилями: 3–5 сайтів на день краще за 30 одразу; тримайте старий хостинг живим до завершення останньої хвилі + кілька днів.
  5. Фінальна синхронізація для змінних сайтів: повторний rsync + свіжий дамп бази безпосередньо перед перемиканням DNS кожного сайту, щоб нічого не загубилось у проміжку.
  6. Пост-міграційний прохід по сайту: SSL випущено, permalinks працюють, пошта шле, бекап-задача охоплює новачка.

Типові проблеми

  • Контент, змінений після копіювання: крок фінальної синхронізації існує саме для цього — пропустите, і втратите коментарі/замовлення.
  • Увесь DNS перемкнули одразу: тикети підтримки від усіх клієнтів одночасно — хвилі тримають збої дебажними.
  • Забули пошту: сайти переїжджають, MX-записи — ні; аудитьте хостинг пошти по кожному домену ще в інвентаризації.

Коли звертатися в підтримку

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

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

У якому порядку мігрувати парк сайтів?

Спершу найменший і найменш критичний, щоб довести конвеєр, потім хвилями по 3–5 на день, завершуючи e-commerce і високотрафіковими сайтами, коли процес уже відпрацьований.

Як не втратити контент, створений під час міграції?

Запустіть фінальний rsync і свіжий дамп бази безпосередньо перед перемиканням DNS кожного сайту — саме в проміжку між копіюванням і перемиканням зникають коментарі й замовлення.

Чи може Cloud2Y перенести всі мої клієнтські сайти?

Так — масова міграція для агенцій робиться через тикет підтримки: надайте інвентар і доступи, команда спланує хвилі й перенесе сайти.

Схожі статті

Готові почати? Замовити WordPress VPS у Cloud2Y →

Ця відповідь Вам допомогла? 0 Користувачі, які знайшли це корисним (0 Голосів)