Как сохранить заявки и заказы при переносе сайта с Beget

Blog image

Самая опасная часть переезда интернет-магазина — не копирование файлов, а изменения, которые продолжают приходить во время переноса. Новые заказы, заявки и обновления остатков могут записываться на старый сайт после того, как копия уже создана. Чтобы не потерять их, назначьте окно переключения и заранее определите, где будет храниться каждая новая запись.

Сначала составьте карту заявок и заказов

Выпишите все места, куда попадают данные: база магазина, CRM, почта, таблица менеджера, сервис доставки и платёжный кабинет. Уточните, где создаётся первичная запись и какие интеграции отправляют её дальше. Если менеджер вручную меняет статус заказа, это тоже часть миграции данных.

Разделите операции на читающие и записывающие. Просмотр каталога можно перенести заранее. Оформление заказа, добавление комментария, регистрация, загрузка документа и изменение остатка требуют согласованной стратегии, потому что они меняют базу. Проверьте фоновые очереди, уведомления, вебхуки и задания, которые могут выполниться во время переключения.

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

Рейтинг хостингов для сайта

�஢����� �롨ࠥ��� ��᫥ ⮣�, ��� ��।��� ᯮᮡ ��࠭��� ���� ������ �� �६� ��४��祭��. �ࠢ������ ���頤�� �� ��७��� ����, ��⮢��� ������ � ����⠭�������, �� ������: ३⨭� �� �蠥� ������ ᢥન ������ � �����.

  1. Timeweb — Для небольших и средних сайтов, магазинов и корпоративных проектов; перед заказом сверьте нужные версии PHP, базы и лимиты тарифа.
  2. МакХост — Рассмотрите, если важны привычные инструменты виртуального хостинга и поддержка; проверьте требования проекта и порядок переноса.
  3. SpaceWeb — Вариант для сравнения тарифов виртуального хостинга и дополнительных услуг; проверьте доступные функции на выбранном плане.
  4. Hostland — Проверьте совместимость с CMS, почтой, SSL и планом резервного копирования до переноса.
  5. SprintHost — Сравните доступные ресурсы, ограничения и помощь с миграцией именно для вашего проекта.
  6. AdminVPS — Подходит для сравнения вариантов с расширенными настройками; заранее уточните, какие задачи администрирования включены.

Почему копия сайта быстро устаревает

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

Именно поэтому обычное копирование папки не решает задачу для активного магазина. Нужен план финальной синхронизации данных: временно прекратить запись, повторно выгрузить изменения или использовать проверенную репликацию. Подход зависит от CMS, объёма операций и компетенций исполнителя. Не запускайте самодельное копирование таблиц между работающими базами без проверки консистентности.

Уточните, как обрабатываются платежи и вебхуки. Если один заказ может быть создан на двух площадках, определите главный источник и правила объединения. Не полагайтесь на совпадение номеров заказов, особенно если две копии использовали независимые счётчики.

Выберите способ переключения

Короткое окно без оформления. На время финальной синхронизации сайт показывает сообщение о технических работах или временно закрывает оформление. Подходит для проектов, где можно заранее выбрать тихий период. Клиентам лучше показывать контактный способ связи и ожидаемое время возвращения.

Только чтение на старой площадке. Каталог остаётся доступен, но новые заказы принимаются в одном месте или временно отключены. Это снижает риск записи в две базы. Нужны понятное предупреждение пользователю и договорённость с отделом продаж.

Репликация или синхронизация. Для интенсивного проекта специалист переносит изменения по согласованному механизму. Требуются тест, оценка задержки и заранее известная точка остановки записи. Такой путь сложнее, но может уменьшить перерыв.

Не оставляйте обе копии принимать реальные заказы без общей базы и идемпотентного механизма. Двойная запись часто создаёт больше проблем, чем короткая пауза.

Пошаговый план переезда

  1. Подготовьте резервную копию. Сохраните базу и файлы и убедитесь, что архив можно прочитать. WordPress рекомендует иметь обе части: резервная копия только каталога не включает записи из базы.
  2. Поднимите тестовую копию. Настройте сайт по техническому адресу, отключите отправку реальных писем, оплату и интеграции, если тест может повлиять на клиентов.
  3. Проверьте полный цикл. Сделайте тестовый заказ, проверьте переходы статусов, уведомления, экспорт и связь с CRM.
  4. Объявите окно. Сообщите сотрудникам время ограничения записи и назначьте одного ответственного за новые обращения.
  5. Остановите изменения по плану. Включите режим обслуживания, только чтение или другой заранее протестированный механизм.
  6. Сделайте финальную синхронизацию. Зафиксируйте время последней записи и перенесите данные способом, который выбран для этой CMS.
  7. Переключите домен и проверьте его. Сверьте DNS, сертификат и основные страницы.
  8. Откройте приём заказов. Разрешите создание новых записей только после проверки нового магазина.

Сверка после запуска

Сравните количество заказов за одинаковый период по времени создания, статусу и идентификатору. Проверьте самые свежие заявки до момента переключения. Отдельно проверьте отмены, возвраты, оплату по ссылке, гостевые заказы и записи, которые пришли через интеграцию. Если сумма или количество не совпадает, не исправляйте её вручную до сохранения текущих копий обеих баз.

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

В итоговом протоколе укажите время последней записи на старой площадке, время открытия новой, число сверенных заказов и расхождения. Старую площадку сохраните до завершения периода наблюдения. Если вернуться назад, учитывайте, что новые записи после переключения могут уже жить только в новой базе.

Что сообщить сотрудникам и клиентам

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

Покупателям не обязательно рассказывать внутреннюю историю миграции. Если оформление временно недоступно, покажите короткое уведомление с альтернативным каналом связи и примерным временем возвращения, если оно известно. Не обещайте точное время, пока команда не проверила базу и оплату.

Подготовьте критерии завершения: новые заявки появляются на новом сервере, старые записи доступны, письма доходят, заказы не дублируются, очередь интеграций обрабатывается. Если критерии не достигнуты, остановите дальнейшие изменения и действуйте по плану отката. Сохраните обе базы до выяснения причин.

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

Можно ли переключить магазин ночью?

Можно выбрать тихое окно, если в этот период действительно меньше заказов и доступен ответственный специалист. Ночь сама по себе не гарантирует меньший риск: важно иметь план возврата и контроль новых операций.

Может ли новый сайт работать параллельно со старым?

Да, как тестовая копия без реальных записей или как заранее настроенная схема с одной базой. Две независимые базы, принимающие заказы, требуют механизма синхронизации и объединения.

Нужно ли менять DNS перед финальной копией?

Нет универсального порядка: он зависит от способа тестирования. Важно, чтобы к моменту переключения существовала проверенная копия, а свежие записи были перенесены по выбранному плану.

Документы и инструкции

Проверяйте актуальную редакцию документации перед работами: пункты панелей и условия услуг могут меняться.