Коротка відповідь: Замовлення — це рядки бази даних, тож вікно ризику — між останньою копією бази і перемиканням DNS. Увімкніть короткий maintenance/заморозку checkout, зробіть фінальну синхронізацію бази всередині цього freeze, перемкніть DNS і зніміть заморозку вже на новому сервері. За такої послідовності жодне замовлення не може непомітно осісти на старому сервері.
Огляд
Магазин WooCommerce відрізняється від звичайного сайту одним критичним моментом: клієнти пишуть у базу цілодобово. Копію файлів можна повторювати безпечно, але кожне замовлення, зміна залишків чи акаунт клієнта, створені після знімка бази, існують лише на старому сервері. Уся міграція тому обертається навколо контролю цього вікна записів.
Що потрібно мати
- Перевірену копію магазину, що вже працює на новому сервері (див. міграцію WordPress без простою).
- Перевірений механізм maintenance-режиму: coming-soon у WooCommerce, maintenance-плагін або повідомлення на рівні вебсервера.
- Вікно найменшої кількості замовлень із вашої аналітики продажів.
Покрокова інструкція
- Анонсуйте коротке технічне вікно, якщо клієнти звикли замовляти 24/7.
- Увімкніть заморозку checkout на СТАРОМУ сайті на початку вікна — переглядати можна, замовляти ні.
- Фінальна синхронізація бази: зробіть дамп бази (або щонайменше таблиць замовлень, постів і користувачів WooCommerce) та імпортуйте на новий сервер.
- Перевірте потік замовлення на новому сервері через hosts-файл: проведіть тестове замовлення від початку до кінця, включно з sandbox платіжного шлюзу, якщо доступний.
- Перемкніть DNS, зніміть заморозку на НОВОМУ сервері, а на старому залиште її УВІМКНЕНОЮ — випадковий відвідувач зі старим DNS не зможе там нічого замовити.
- Звірка: наступного дня порівняйте останні ID замовлень на обох серверах і переконайтеся, що на старий бік нічого не впало.
Типові проблеми
- Платіжні вебхуки: оновіть URL вебхуків/allowlist-и IP у шлюзі, якщо вони посилаються на сервер напряму, інакше асинхронні підтвердження платежів губляться.
- Cron-листи: вимкніть WP-Cron на старому сервері після перемикання, щоб він не слав дублікати сповіщень.
- Сесії та кошики: кошики залогінених у базі переживають синхронізацію; гостьові кошики в cookies переживають DNS — але все, що кешувалося посеред перемикання, може потребувати оновлення.
Коли звертатися в підтримку
Магазинам із постійним потоком замовлень, кількома валютами чи кастомними платіжними інтеграціями варто замовити асистовану міграцію — ми сплануємо вікно заморозки разом і будемо онлайн протягом перемикання.
Часті запитання
Як магазини втрачають замовлення під час міграції?
Замовлення, зроблені між останньою копією бази і перемиканням DNS, існують лише на старому сервері. Заморозка checkout на час фінальної синхронізації повністю закриває цей розрив.
Наскільки довгою має бути заморозка checkout?
Лише на час фінальної синхронізації бази та перевірки — зазвичай хвилини, якщо повну копію зробили раніше. Плануйте її на вікно мінімуму замовлень за аналітикою.
Що з вебхуками платіжного шлюзу після переїзду?
Оновіть URL вебхуків і allowlist-и IP у кабінеті шлюзу на новий сервер, інакше асинхронні підтвердження оплат можуть тихо перестати надходити.
Як переконатися, що жодне замовлення не загубилося?
Тримайте старий магазин у заморозці checkout після перемикання, а наступного дня порівняйте останні ID замовлень в обох базах; однакові ID означають, що на старий бік нічого не впало.
Схожі статті
- Як перенести WordPress без простою
- Як перенести бази даних
- Чекліст після міграції
- Як відкотити міграцію
Потрібна допомога? Звернутися в підтримку Cloud2Y →
