Коротка відповідь
Головний принцип переносу магазину без втрат — робити копію й тестувати на новому сервері паралельно з роботою старого, а не вимикати старий одразу. DNS перемикається лише після повної перевірки, і в ідеалі — у момент найменшого трафіку, з коротким вікном «заморозки» нових замовлень.
Крок 1. Підготовка: інвентаризація того, що переносимо
- Файли: сама CMS, тема, завантажені зображення товарів.
- База даних: товари, категорії, клієнти, історія замовлень.
- Налаштування інтеграцій: платіжні системи, служби доставки, поштові сповіщення.
- SSL-сертифікат і .htaccess/правила редиректів, якщо вони є.
Загальний алгоритм переносу файлів і бази для WordPress описаний у статті перенести WordPress на новий хостинг: покроково — для магазину на WooCommerce ці кроки повністю застосовні, з додатковою увагою до таблиць замовлень.
Крок 2. Перенос на новий сервер без перемикання DNS
Файли й база копіюються на новий сервер, сайт перевіряється через технічну адресу чи файл hosts на своєму комп'ютері — так, щоб бачити новий сайт, поки всі інші відвідувачі досі йдуть на старий сервер. Це ключовий момент: магазин продовжує приймати замовлення на старому хостингу, поки новий готується й перевіряється.
Крок 3. Перевірка платіжних інтеграцій окремо
Платіжні шлюзи часто прив'язані до конкретного домену чи IP-адреси в налаштуваннях безпеки провайдера оплати. Перед перемиканням DNS варто:
- Перевірити, чи потрібно повідомити платіжну систему про новий сервер/IP.
- Зробити тестове замовлення на мінімальну суму (або в тестовому режимі, якщо шлюз це підтримує) саме на новому сервері.
- Перевірити, що сповіщення про нове замовлення доходять і адміну, і клієнту.
Типова помилка — перенести сайт технічно ідеально, але забути, що платіжний шлюз досі «бачить» тільки старий IP і блокує оплату на новому сервері. Це виявляється вже після того, як клієнти почали скаржитись, — тому тестове замовлення обов'язкове до, а не після перемикання.
Крок 4. Вікно «заморозки» замовлень
Навіть при ідеальній підготовці база даних на новому сервері — це знімок на певний момент часу. Якщо між копіюванням бази і перемиканням DNS хтось оформить замовлення на старому сайті, воно ризикує «загубитися» при фінальному перенесенні. Рішення — коротке технічне вікно (зазвичай нічний час з мінімальним трафіком), коли:
- На старому сайті тимчасово вимикається можливість оформити нове замовлення (банер «технічні роботи», 15-30 хвилин).
- Знімається фінальна, актуальна копія бази даних.
- Ця копія переноситься на новий сервер поверх тестової.
- Перемикається DNS чи A-запис на новий сервер.
Як саме перемикається домен на новий сервер (A-запис чи зміна NS) і скільки це займає — у статті як спрямувати домен на хостинг.
Крок 5. Перші 24 години після перемикання
DNS оновлюється не миттєво для всіх відвідувачів — частина трафіку може ще кілька годин йти на стару адресу. Тому старий сервер варто не вимикати одразу, а лишити доступним ще 24-48 годин у режимі «тільки читання» — щоб не втратити запізнілі запити, і водночас звірити, чи не з'явилися замовлення на старому сервері вже після перенесення бази.
Про SEO-позиції при переносі
Якщо адреса сайту (домен) не змінюється, а переноситься тільки хостинг, — позиції в пошуку зазвичай не страждають, за умови що сайт не «лежав» довго і структура URL не змінилася. Якщо ж плануєте одночасно й зміну домену, і зміну хостингу — це вже інший, значно ризикованіший процес, який варто розносити в часі.
Перенесення відгуків і рейтингів товарів
Якщо на магазині накопичені відгуки покупців і рейтинги товарів, важливо переконатися, що ця інформація переноситься разом з основною базою даних, а не губиться через специфічну структуру зберігання (наприклад, якщо відгуки зберігаються не в стандартних таблицях CMS, а через сторонній плагін із власною структурою даних). Втрата накопичених роками відгуків — це втрата соціального доказу, який часто прямо впливає на конверсію, тому цей момент варто перевірити окремим пунктом, а не вважати "просто частиною бази".
Резервна копія — обов'язковий крок до старту
Перед будь-якими діями варто мати свіжу копію і старого сайту, і бази — незалежно від автоматичних бекапів хостингу. Як улаштовані бекапи на Meridaro й чи можна замовити позаплановий знімок — у статті як улаштовані щоденні бекапи поза сервером.
Чек-лист після перенесення: що перевірити в перші години
- Оформити тестове замовлення повністю, від додавання товару в кошик до підтвердження оплати.
- Перевірити, чи приходять сповіщення про замовлення адміністратору й підтвердження клієнту.
- Перевірити розрахунок доставки й інтеграцію зі службами (Нова пошта тощо) на реальному прикладі.
- Звірити кількість товарів і замовлень у базі нового сервера з тим, що було на старому на момент фінального копіювання.
- Перевірити швидкість завантаження ключових сторінок — каталог, картка товару, кошик.
- Переконатись, що SSL-сертифікат активний і немає попереджень про змішаний контент.
А якщо щось пішло не так уже після перемикання DNS
Якщо проблему виявили вже після повного перемикання (наприклад, не спрацьовує якась інтеграція), не варто одразу відкочуватися назад на старий сервер — це створює нову плутанину з тим, де саме зараз "правдива" версія бази даних із замовленнями. Краще діагностувати конкретну проблему на новому сервері й виправити її точково, звернувшись у підтримку з описом симптомів. Повний відкат виправданий тільки у справді критичному сценарії, коли магазин повністю не працює й швидкого рішення не видно.
Хто має бути залучений у команду перенесення
Перенесення працюючого магазину — це не суто технічна задача одного адміністратора. Варто заздалегідь залучити людину, що відповідає за маркетинг (щоб призупинити чи скоригувати активні рекламні кампанії на час технічного вікна), людину, що спілкується з клієнтами (щоб бути готовою відповісти на можливі питання про тимчасові технічні роботи), і, звісно, технічного виконавця самого перенесення. Коли ролі розподілені заздалегідь, а не з'ясовуються в процесі, ризик плутанини й помилок суттєво нижчий.
Особливості перенесення для конкретних платформ
Для WooCommerce (WordPress) додатково варто перевірити налаштування постійних посилань (permalinks) після перенесення — вони можуть скинутися до дефолтних, ламаючи всі URL товарів і категорій. Для OpenCart важливо звірити шлях до директорії завантажень (image/) — товари можуть лишитися без зображень, якщо шлях у базі даних не збігається зі структурою на новому сервері. Для будь-якої платформи корисно мати під рукою чек-лист специфічних для CMS налаштувань, а не покладатися виключно на загальний алгоритм "скопіювати файли й базу".
Вартість помилки порівняно з вартістю підготовки
Ретельна підготовка до перенесення — тестова копія, перевірка платіжних інтеграцій, узгоджене вікно заморозки — займає додаткові кілька годин роботи порівняно зі спрощеним підходом "скопіювали і одразу перемкнули". Але вартість помилки при спрощеному підході — це реальні втрачені замовлення, розгублені клієнти й, у гіршому випадку, репутаційні втрати від публічних скарг. Ці кілька годин підготовки — одна з найвигідніших інвестицій часу у всьому процесі перенесення магазину.
Комунікація з клієнтами під час технічного вікна
Якщо очікується вікно "заморозки" замовлень (навіть на 15-30 хвилин), варто розмістити помітне повідомлення на сайті про тимчасові технічні роботи, а не просто прибрати кнопку "оформити замовлення" без пояснень. Це дрібниця, яка суттєво знижує кількість занепокоєних звернень у підтримку саме в момент, коли команда зайнята технічним перенесенням.