Краткий ответ: Заказы — это строки базы данных, поэтому окно риска — между последней копией базы и переключением DNS. Включите короткий maintenance/заморозку checkout, сделайте финальную синхронизацию базы внутри этого freeze, переключите DNS и снимите заморозку уже на новом сервере. При такой последовательности ни один заказ не может незаметно осесть на старом сервере.

Обзор

Магазин WooCommerce отличается от обычного сайта одним критичным моментом: клиенты пишут в базу круглосуточно. Копию файлов можно повторять безопасно, но каждый заказ, изменение остатков или аккаунт клиента, созданные после снимка базы, существуют только на старом сервере. Вся миграция поэтому вращается вокруг контроля этого окна записей.

Что нужно иметь

  • Проверенную копию магазина, уже работающую на новом сервере (см. миграцию WordPress без простоя).
  • Проверенный механизм maintenance-режима: coming-soon в WooCommerce, maintenance-плагин или уведомление на уровне веб-сервера.
  • Окно наименьшего количества заказов из вашей аналитики продаж.

Пошаговая инструкция

  1. Анонсируйте короткое техническое окно, если клиенты привыкли заказывать 24/7.
  2. Включите заморозку checkout на СТАРОМ сайте в начале окна — просматривать можно, заказывать нет.
  3. Финальная синхронизация базы: сделайте дамп базы (или минимум таблиц заказов, постов и пользователей WooCommerce) и импортируйте на новый сервер.
  4. Проверьте поток заказа на новом сервере через hosts-файл: проведите тестовый заказ от начала до конца, включая sandbox платёжного шлюза, если доступен.
  5. Переключите DNS, снимите заморозку на НОВОМ сервере, а на старом оставьте её ВКЛЮЧЁННОЙ — случайный посетитель со старым DNS не сможет там ничего заказать.
  6. Сверка: на следующий день сравните последние ID заказов на обоих серверах и убедитесь, что на старую сторону ничего не упало.

Типичные проблемы

  • Платёжные вебхуки: обновите URL вебхуков/allowlist-ы IP в шлюзе, если они ссылаются на сервер напрямую, иначе асинхронные подтверждения платежей теряются.
  • Cron-письма: отключите WP-Cron на старом сервере после переключения, чтобы он не слал дубликаты уведомлений.
  • Сессии и корзины: корзины залогиненных в базе переживают синхронизацию; гостевые корзины в cookies переживают DNS — но всё, что кешировалось посреди переключения, может требовать обновления.

Когда обращаться в поддержку

Магазинам с постоянным потоком заказов, несколькими валютами или кастомными платёжными интеграциями стоит заказать ассистированную миграцию — мы спланируем окно заморозки вместе и будем онлайн в течение переключения.

Частые вопросы

Как магазины теряют заказы при миграции?

Заказы, сделанные между последней копией базы и переключением DNS, существуют только на старом сервере. Заморозка checkout на время финальной синхронизации полностью закрывает этот разрыв.

Насколько долгой должна быть заморозка checkout?

Только на время финальной синхронизации базы и проверки — обычно минуты, если полную копию сделали раньше. Планируйте её на окно минимума заказов по аналитике.

Что с вебхуками платёжного шлюза после переезда?

Обновите URL вебхуков и allowlist-ы IP в кабинете шлюза на новый сервер, иначе асинхронные подтверждения оплат могут тихо перестать приходить.

Как убедиться, что ни один заказ не потерялся?

Держите старый магазин в заморозке checkout после переключения, а на следующий день сравните последние ID заказов в обеих базах; одинаковые ID означают, что на старую сторону ничего не упало.

Похожие статьи

Нужна помощь? Связаться с поддержкой Cloud2Y →

Помог ли вам данный ответ? 0 Пользователи нашли это полезным (0 голосов)