Переезд сайта начинается с проверки того, что нужно сохранить: страниц, файлов, заявок, заказов, почты и фоновых задач. Затем на новом хостинге запускают проверенную копию, согласуют обращение с новыми данными и только после этого переключают посетителей. Открывающаяся главная страница ещё не означает, что перенос завершён.
Ниже — практический план для владельца бизнеса и исполнителя. Он относится к смене хостинга с сохранением домена и адресов страниц. Если одновременно меняется домен, понадобится отдельный план: как сменить домен и сохранить связи страниц.
Сначала зафиксируйте состав переезда
Попросите исполнителя составить перечень ресурсов и доступов до заказа нового тарифа. «Сайт лежит у провайдера» — слишком общее описание: сайт, база, почта и DNS могут обслуживаться в разных местах.
| Что выяснить | Что зафиксировать |
|---|---|
| Домен и DNS | Кто управляет доменом и записями, какие имена используются для сайта и связанных сервисов |
| Приложение | CMS или фреймворк, версия, зависимости, сборка, настройки веб-сервера |
| Данные | Базы, загруженные посетителями файлы, изображения, документы, внешние хранилища |
| Обращения и заказы | Где хранится исходная запись, куда уходят уведомления, какие системы меняют её статус |
| Почта | Где находятся ящики, через что сайт отправляет письма, зависит ли почта от старого хостинга |
| Автоматические процессы | Очереди, задания по расписанию, обмен с учётной системой, входящие уведомления от сервисов |
| Защита и наблюдение | Сертификат HTTPS, права доступа, журналы, мониторинг, резервные копии |
Проверьте, что доступами распоряжается уполномоченный человек со стороны бизнеса. Исполнителю выдавайте необходимые для работы права через безопасный канал; пароли и ключи не должны попадать в общие документы и переписку с лишними участниками.
По перечню сравните новый хостинг с требованиями действующего приложения. Важны поддерживаемые версии и расширения, доступ к базе, возможность запускать фоновые процессы, место для данных и копий. Покупка тарифа до такой проверки может закончиться тем, что перенести файлы можно, а запустить рабочий сайт — нельзя.
Согласуйте ответственного за технические действия, человека, который проверяет бизнес-сценарии, и того, кто разрешает переключение. В плане должны быть условия начала работ, допустимые ограничения для посетителей, критерии остановки и порядок возврата. Продолжительность определяют после инвентаризации и пробного переноса, а не по универсальному обещанию.
Подготовьте копию, которую действительно можно запустить
Нужны совместимые между собой код, база и пользовательские файлы. Архив папки сайта не заменяет выгрузку базы, а выгрузка базы не содержит прикреплённые документы, если они хранятся отдельно.
Первую копию используют для подготовки и тестирования нового окружения. Её время создания фиксируют: всё, что бизнес получил позже, требует отдельной синхронизации перед переключением.
Способ выгрузки зависит от базы и приложения. Например, у MySQL режим согласованной выгрузки через одну транзакцию применим к таблицам InnoDB; для других типов таблиц и при изменении структуры во время выгрузки нужны дополнительные меры. Универсальная команда из инструкции не доказывает, что копия именно вашего сайта согласована.
Проверьте не только наличие архива, но и восстановление в новом окружении. Сверьте критичные записи, связи между ними и доступность связанных файлов: последний заказ с его позициями, заявку с вложением, товар с изображениями. Количество строк и контрольные суммы полезны для сверки, но сами по себе не подтверждают правильность работы приложения.
Исходную копию храните вне публичной папки сайта с ограниченным доступом. Она нужна для восстановления и разбора ошибок, поэтому не заменяйте её единственным рабочим экземпляром на новом сервере. Подробности состава и проверки вынесены в материал о резервном копировании сайта; при согласовании резервного копирования отдельно зафиксируйте хранение, доступ и проверку восстановления.
Проверьте новый хостинг до переключения посетителей
Тестовая копия должна быть изолирована от посторонних. Исполнитель может ограничить доступ и настроить на своём компьютере разрешение рабочего имени сайта в адрес нового сервера. Так проверяют сайт под его обычным доменом до изменения публичного DNS. При этом важно убедиться по журналам, что запрос действительно попал на новый сервер.
Открытие копии по временному имени удобно для части проверок, но не заменяет проверку рабочего имени, HTTPS, переходов и настроек, зависящих от домена.
Тесты не должны рассылать письма клиентам, создавать настоящие платежи или передавать учебные заказы в рабочую учётную систему. Для интеграций используйте предусмотренный сервисом тестовый режим или согласованную изоляцию. Отмечайте тестовые записи так, чтобы их можно было отличить от рабочих и безопасно удалить.
| Проверка | Какой результат нужен |
|---|---|
| Страницы и файлы | Ключевые адреса, изображения и документы доступны; прежние переходы работают |
| HTTPS | Сертификат соответствует рабочему имени; браузер не показывает предупреждений |
| Вход и кабинет | Авторизация, выход и важные действия пользователя выполняются корректно |
| Заявка | Запись сохранена там, где её обрабатывает бизнес; проверено получение уведомления |
| Заказ и интеграции | Состав и статус заказа корректны; обмен проверен в согласованном режиме |
| Фоновые задачи | Задания выполняются в нужном окружении и не создают повторных действий |
| Доступ и ошибки | Секреты и архивы недоступны посетителям; ошибки фиксируются без раскрытия ключей |
Сохраните результаты проверки: какие сценарии пройдены, что осталось проверить только после переключения, какие проблемы блокируют запуск. Письмо «всё перенесли» без этих сведений не даёт владельцу основания принять работу.
Если сайт работает на Laravel
Проверьте требования установленной версии Laravel и зависимостей. Веб-сервер должен обслуживать приложение из каталога public, а не открывать корень проекта с конфигурацией. Нужны корректные права на storage и bootstrap/cache, пользовательские файлы и актуальные настройки базы, почты, очередей и сессий.
При обычной смене сервера сохраните действующий APP_KEY. Его случайная замена может прервать сеансы и сделать ранее зашифрованные данные недоступными без прежнего ключа. Плановую смену ключа рассматривают отдельно.
Проверьте кэш конфигурации, сборку ресурсов и запуск долгоживущих процессов по документации вашей версии. В рабочем окружении APP_DEBUG должен быть выключен. Не запускайте очереди и задания по расписанию сразу в двух независимых копиях, если они могут повторно отправить письма, списать остатки или изменить заказы.
Решите, куда попадут новые данные
Самый опасный промежуток — между первой копией и завершением переезда. Старый сайт продолжает получать заявки, сотрудники меняют каталог, платёжный сервис присылает статусы, а копия на новом сервере остаётся в прошлом состоянии.
Для простого сайта с редкими изменениями можно согласовать окно, когда запись приостановлена. В это окно прекращают изменения через сайт и административную часть, учитывают фоновые процессы и внешние уведомления, дожидаются завершения выполняющихся операций и делают финальную синхронизацию базы и файлов. После неё повторяют критичные проверки.
Закрыть только форму заказа недостаточно: данные могут изменяться через API, очередь или интеграцию. Исполнитель должен перечислить все источники записи и объяснить, что произойдёт с событиями, которые придут во время ограничения. Для отложенных уведомлений нужен подтверждённый способ повторного получения и обработки без дублей.
Если приостанавливать приём заказов нельзя, нужен отдельный технический план: как поддерживается актуальность данных, где находится единственное согласованное место записи и как туда направляются запросы. Такая схема зависит от приложения и инфраструктуры; она требует подготовки и проверки.
Учебный пример. В магазине сначала скопировали сайт для проверки. Пока шли тесты, на старом сервере появился новый заказ с вложенным файлом. Перед запуском нужно перенести сам заказ, его связанные записи и вложение, а также учесть пришедшее подтверждение оплаты. Переключение DNS без финальной синхронизации этих данных оставит новый сайт с неполной картиной работы магазина.
Переключите сайт, сохранив почту и связанные сервисы
Сначала проверьте, какие изменения DNS действительно нужны. При сохранении провайдера DNS перенос сайта часто требует изменения записей, направляющих веб-трафик, а не смены всех серверов имён. Если управление DNS тоже переносится, предварительно перенесите и проверьте всю необходимую зону.
Обратите внимание на записи A, AAAA и CNAME для рабочего сайта и его вариантов. Оставшаяся запись на старый адрес может направлять часть посетителей в прежнее окружение.
TTL определяет время кэширования DNS-записи. Его заблаговременное уменьшение может ускорить получение новых значений, но не удаляет уже сохранённые ответы и не гарантирует одновременное переключение всех пользователей. Локальные кэши тоже влияют на наблюдаемый результат. Поэтому план работы с данными должен учитывать обращения к обоим серверам в переходный период.
Почта требует отдельного решения:
- Если ящики остаются у прежнего почтового провайдера, сохраните необходимые MX и связанные записи, включая настройки SPF, DKIM и DMARC.
- Если MX указывает на имя, адрес которого меняется вместе с сайтом, одного сохранения MX недостаточно: проверьте, куда теперь направляется почтовое соединение.
- Если ящики находились на старом хостинге, согласуйте перенос писем, папок, учётных записей и сообщений, поступающих в переходный период.
- Независимо от места хранения ящиков проверьте исходящую почту самого сайта: настройки отправителя, подключения и получение письма адресатом.
Не закрывайте старый тариф, пока не проверено, что на нём не остались нужные ящики, DNS, файлы или другие зависимости.
Переключение выполняют после финальной сверки данных и согласованного разрешения. У новой рабочей версии проверьте также отсутствие тестовых запретов индексации и наличие прежних настроек аналитики. Сохраняющийся домен не отменяет этих проверок.
Принимайте перенос по результатам работы
После изменения DNS повторите критичные сценарии уже через обычный доступ к сайту. Проверьте разрешение имени из разных сетей, HTTPS, страницы, новую заявку и её доставку, вход пользователей и работу интеграций. По журналам сравните обращения к старому и новому серверам.
В период наблюдения следите за ошибками приложения, неотправленными письмами, зависшими очередями, расхождениями заказов и доступностью файлов. Продолжительность наблюдения согласуйте по особенностям сайта; окончание одного TTL не является универсальным критерием завершения.
Перенос можно принять, когда:
- подтверждена актуальность рабочих данных и их связей с файлами;
- бизнес-сценарии проходят на новом хостинге;
- обращения, ещё попадающие на старый сервер, обработаны по согласованному плану;
- почта, фоновые процессы и интеграции работают в нужном окружении;
- настроена и проверена резервная копия нового окружения;
- переданы актуальные доступы, результаты проверок и порядок восстановления.
Старую инфраструктуру отключают после подтверждения, что она больше не нужна посетителям и связанным процессам. До этого она сохраняется под контролем доступа и с согласованной ролью, а не как забытая вторая рабочая база.
Почему откат нельзя свести к возврату DNS
Условия отката нужны до начала переезда. Например, основанием для остановки могут быть подтверждённая потеря записей, неработающий критичный сценарий или сбой интеграции. Какие проблемы требуют возврата, а какие можно устранить на новом сервере, решают заранее с учётом бизнеса.
Если новая копия ещё не принимала рабочие изменения, возврат может быть проще. Но после появления новых заказов, загрузок и статусов старая база уже не отражает текущее состояние. Возврат DNS к ней без сверки способен потерять результаты работы после переезда.
При сбое сначала сохраняют данные и диагностические журналы обоих окружений, ограничивают конфликтующие записи и выясняют, где находятся актуальные сведения. Затем выбирают проверенный путь восстановления или согласованного переноса изменений. Отдельно учитывают повторные уведомления и незавершённые операции. Откат DNS тоже проходит через кэши, поэтому не является мгновенным аварийным выключателем.
Если поручаете перенос сайта исполнителю, просите план именно для вашего приложения: состав данных, тестовый запуск, обращение с новыми записями, почту, критерии переключения и восстановления. Такой план даёт понятные основания для решения о запуске. Обещание «без простоя» без описания этих условий — не подтверждение готовности.
