Перенос сайта на Битрикс без простоя: план и откат

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

Соберите временную схему

1. За несколько дней. Проверьте текущий DNS TTL и заранее снизьте его; старое значение должно успеть истечь в кешах.
2. За сутки. Зафиксируйте состав данных, ограничьте массовые изменения и подтвердите окно переключения.
3. Перед переключением. Сделайте финальную синхронизацию файлов и базы, затем остановите запись на старой стороне или согласуйте дельту.
4. После переключения. Проверьте сайт с внешней сети и продолжайте наблюдать за старым и новым сервером.

Снижение TTL непосредственно перед заменой записи почти не помогает: рекурсивные DNS‑серверы могут продолжать хранить старое значение до окончания предыдущего TTL.

Определите источник истины

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

Подготовьте критерии отката

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

До переноса

• собрать доступы к хостингу, домену, DNS, базе и внешним сервисам;
• проверить свежий бэкап тестовым восстановлением;
• измерить объём файлов, upload и базы;
• зафиксировать версии PHP, Битрикс, модулей и расширений;
• выгрузить старые URL, редиректы и DNS‑записи;
• проверить лицензии, cron, агентов, почту и интеграции;
• подготовить план переключения, проверки и отката.

Тестовый перенос

Сначала разверните проект на временном домене или закрытом стенде. Проверьте админку, страницы, формы, поиск, корзину, оплату, CRM и письма на копии production‑данных с защищённым доступом.

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

День переключения

1. Подтверждаем готовность нового сервера и действующий TLS‑сертификат.
2. Ограничиваем запись на старой стороне или включаем согласованный режим обслуживания.
3. Делаем финальную синхронизацию базы, файлов и upload.
4. Проверяем конфиги, владельцев, права и фоновые задания.
5. Переключаем DNS или внешний прокси.
6. Проверяем главные страницы, авторизацию, формы, оплату, CRM и почту.
7. Сравниваем новые записи с контрольной точкой и принимаем решение: продолжить или откатить.

После переноса

• проверить 301‑редиректы;
• обновить sitemap;
• проверить robots.txt;
• убедиться, что формы отправляются;
• сверить цели аналитики;
• посмотреть логи ошибок;
• оставить старый сервер на короткий период как запасной вариант.

Наблюдение после переключения

Проверяйте не только главную страницу. Следите за кодами 4xx/5xx, временем ответа, очередями писем, агентами, платежами, входящими заявками и логами интеграций. Полезно выполнить контрольную операцию по каждому критичному сценарию.

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

После стабилизации верните DNS TTL к рабочему значению и обновите документацию по окружению.