Перенос сайта на Битрикс без простоя: пошаговый чек-лист

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

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

Что означает «без простоя»

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

Поэтому «без простоя» не означает, что обе копии могут независимо принимать заказы. В каждый момент должен существовать один источник истины — сервер и база, в которые разрешена запись.

Этап 1. Соберите информацию о текущем сервере

• версии PHP, базы данных, веб-сервера и модулей;
• объём файлов, каталога /upload/ и базы;
• cron, агенты Битрикса и фоновые очереди;
• почтовые настройки, SPF, DKIM и SMTP;
• интеграции с CRM, 1С, оплатой, доставкой и внешними API;
• DNS-записи, SSL-сертификаты и редиректы;
• нестандартные пути, права и системные пакеты.

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

Этап 2. Подготовьте новый сервер

Настройте операционную систему, firewall, веб-сервер, PHP, базу, резервное копирование и мониторинг до загрузки проекта. Версии окружения должны соответствовать требованиям установленной версии Битрикса и сторонних модулей.

Если одновременно планируется обновление PHP или базы, сначала отделите проблемы совместимости от самого переноса. Безопаснее выполнить тестовый запуск на новом стеке и только после исправлений планировать переключение.

Этап 3. Разверните тестовую копию

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

На копии нужно проверить:

• главную, разделы, поиск и страницы с ЧПУ;
• авторизацию и личный кабинет;
• формы и создание сущностей в CRM;
• корзину, оформление, оплату и статусы заказов;
• обмен с 1С, импорт и экспорт;
• агенты, cron и обработку очередей;
• изображения, документы и права на файлы;
• логи PHP, веб-сервера и Битрикса.

Этап 4. Заранее снизьте DNS TTL

Если домен переключается изменением A-записи, уменьшите TTL за несколько дней. Старое значение должно успеть истечь в кешах рекурсивных DNS-серверов. Изменение TTL за пять минут до переноса не ускорит обновление уже закешированной записи.

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

Этап 5. Определите окно и способ финальной синхронизации

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

1. остановить или перенаправить фоновые задания на старом сервере;
2. сделать финальный дамп базы;
3. синхронизировать изменившиеся файлы и /upload/;
4. импортировать базу и проверить конфигурацию;
5. разрешить запись только на новой стороне;
6. переключить DNS или прокси.

Этап 6. Проверьте сайт сразу после переключения

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

Одновременно следите за кодами 4xx и 5xx, временем ответа, нагрузкой, свободным диском, очередями, логами и новыми записями в базе.

Когда нужно откатываться

Критерии отката определяют до начала работ. Например:

• не создаются или теряются заказы;
• не работает оплата или обмен с 1С;
• формы не доходят до CRM;
• массово возникают ошибки 500;
• исправление превышает согласованное окно.

Откат — это не импровизация. Нужно знать, как вернуть трафик, какая база после этого является актуальной и как перенести записи, созданные за время работы нового сервера.

Что сделать после стабилизации

• вернуть рабочий DNS TTL;
• проверить robots.txt, sitemap.xml, canonical и 301-редиректы;
• обновить настройки мониторинга и резервного копирования;
• убедиться, что старый сервер больше не запускает задания;
• сохранить документацию по новому окружению;
• отключить старый сервер только после согласованного периода наблюдения.

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