Сначала определите вид переезда

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

Перед работами составьте опись: где находится код, база, пользовательские загрузки, резервные копии и настройки внешних сервисов. Отметьте ответственных и доступный способ выгрузки. Административный доступ к CMS не обязательно даёт возможность сохранить весь проект.

Что входит в исходный комплект

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

Для базы важна согласованность копии. Обычное копирование каталога работающей СУБД нельзя считать универсальной процедурой резервирования. Например, PostgreSQL предусматривает логическую выгрузку и отдельный порядок восстановления; особенности описаны в документации SQL Dump. Конкретный метод выбирают для используемой СУБД и условий работы.

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

Сохраните не только данные, но и ориентиры

Выгрузите список старых адресов, карту сайта и правила переадресаций. Для смены URL составьте соответствия «старый адрес — новый адрес» по смыслу страниц. Google рекомендует подготовить такую карту и следить за старыми и новыми адресами в руководстве по переносу сайта.

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

Чек-лист перед переключением

  • Назначьте момент исходного снимка и порядок обработки новых данных после него.
  • Соберите файлы, базу, пользовательские загрузки и описание среды в подписанную опись.
  • Сохраните старые адреса, правила переходов, настройки домена и относящиеся к сайту DNS-записи.
  • Проверьте доступы к интеграциям; не помещайте секреты в общий архив для обсуждения.
  • Выполните пробное восстановление в изолированной среде с отключёнными реальными отправками.
  • Сопоставьте несколько разных типов записей и файлов, а не только общий размер архива.
  • Запишите контрольные сценарии до переезда и повторите их после.
  • Согласуйте условия отката и способ сохранить данные, появившиеся уже на новой площадке.

Условный пример: пропавшие вложения

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

Без такой описи остаётся несколько версий: файл не перенесён, изменились права или построен неверный адрес. Само сообщение «после переезда не работает» не различает их. Этот пример условный, а не результат проведённого исследования.

Ограничения сохранённой копии

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