Как перенести сайт на другой хостинг без простоя и потери заявок

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

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

Содержание:

1. Проведите инвентаризацию

Соберите домены и DNS-зоны, файлы, базы, почтовые ящики, SSL-сертификаты, cron, очереди, CDN, внешние хранилища и интеграции. Запишите версии PHP, базы, веб-сервера и необходимые расширения. Отдельно найдите нестандартные правила в конфигурации.

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

2. Получите независимые доступы и резервную копию

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

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

3. Подготовьте новое окружение

Установите совместимые версии PHP и базы, необходимые расширения, веб-сервер, cron, SSL и правила безопасности. Не обновляйте CMS и плагины одновременно с переездом: иначе при ошибке будет трудно понять, виновата миграция или обновление.

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

4. Разверните первую копию

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

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

5. Проведите функциональную проверку

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

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

6. Подготовьте DNS

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

Скопируйте не только A-запись сайта, но и MX, SPF, DKIM, DMARC, поддомены и записи подтверждения сервисов. Частая ошибка — перенести сайт и случайно остановить корпоративную почту.

7. Выполните финальную синхронизацию

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

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

8. Переключите домен и наблюдайте

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

На новом сервере проверьте сертификат, редиректы, canonical, robots.txt, sitemap, аналитику и рекламные цели. Не меняйте URL без необходимости. Если адреса всё же изменились, заранее подготовьте 301-редиректы.

9. Проверьте заявки и бизнес-процессы

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

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

10. Подготовьте план отката

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

Откат — не просто вернуть DNS. Нужно сохранить новые заказы и обращения, иначе аварийное решение само создаст потерю данных. После стабильной работы нового контура верните обычный TTL и только затем отключайте старый.

Сколько стоит перенос

Стоимость зависит от CMS, объёма данных, почты, интеграций и допустимого простоя. Мы начинаем с просмотра доступов и технической схемы; работа разработчика рассчитывается по ставке 2 300 ₽ в час. Для предварительной подготовки полезен материал о том, как проверить хостинг до переезда.

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

Нужно перенести коммерческий сайт безопасно?

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