Перенос Битрикс на другой хостинг: план миграции и приёмка результата

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

Что входит в перенос Битрикс на другой хостинг и что остаётся за рамками

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

В состав переноса обычно входят:

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

Эти элементы образуют единую систему, нарушение целостности которой приводит к неработоспособности сайта.

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

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

План миграции: этапы, артефакты и развилки

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

Типовые этапы:

1. Инвентаризация: что именно переносим, какие есть интеграции и расписания. 2. Подготовка нового окружения: проверка, что оно подходит проекту по требованиям продукта. 3. Снятие копии: полный архив проекта и базы, проверка целостности копии. 4. Развёртывание на тестовом контуре: сайт поднимается на временном адресе, без влияния на рабочий домен. 5. Приёмка на тестовом контуре: проверка сценариев, обменов, фоновых задач. 6. Переключение домена и работа в переходный период. 7. Наблюдение и закрытие проекта: снятие старого окружения по плану возврата.

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

Развилки удобно свести в таблицу: от выбранного варианта зависит объём работ и набор проверок.

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

Предварительная подготовка: инвентаризация и требования

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

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

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

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

Что зафиксировать письменно

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

Копия проекта: архив сайта и резервные копии

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

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

Практические требования к копии:

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

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

Развёртывание на новом окружении

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

Порядок работ:

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

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

Что проверить в настройках окружения

• Совпадение параметров обработчика с требованиями проекта.
• Доступность нужных расширений.
• Корректность путей к каталогам и права на запись.
• Настройки почтовых отправлений.
• Расписание фоновых задач.
• Настройки кеширования и их совместимость с проектом.

Переключение домена и переходный период

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

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

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

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

Проверка заказов, обменов и фоновых задач

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

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

Административные сценарии: вход в административную часть, редактирование товара и страницы, выгрузка отчёта, работа с заказом, управление правами доступа.

Фоновые сценарии: обмен с учётной системой, отправка писем, пересчёт остатков и цен, задачи по расписанию, обработка очередей.

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

Как проверять обмен

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

Многосайтовая конфигурация: отдельный порядок

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

Что нужно сделать до переноса:

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

Ошибка в многосайтовой конфигурации обходится дороже: часть сайтов может работать, а часть — отдавать ошибки, при этом причина будет в общих настройках, а не в конкретном сайте.

Учебный пример: перенос магазина на тестовых данных

Учебный пример. Данные условные и не описывают реальный проект.

Входные условия. Интернет-магазин на одной установке, один сайт, около 1500 товаров, обмен с учётной системой по расписанию, около 40 заказов в сутки, несколько сотрудников работают с заказами в административной части. Сайт работает круглосуточно. Задача — переехать на новое окружение без длительного простоя.

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

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

Развёртывание. Проект развернули на тестовом контуре под временным адресом. Настроили почту и расписание фоновых задач. Прогнали пользовательские сценарии и административные операции.

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

Переключение. Домен переключили в согласованное окно. Старое окружение оставили в режиме готовности. В течение переходного периода сотрудники фиксировали все обращения в один журнал.

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

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

Как принять работу: чек-лист

Приёмка — это не «сайт открывается». Это набор проверок, каждая из которых имеет наблюдаемый результат. Ниже — чек-лист, который можно использовать при приёмке у подрядчика или своей команды.

• Копия проекта снята до начала работ, проверена на отдельном контуре и сохранена в двух местах.
• План миграции существует в письменном виде, с этапами, ответственными и планом возврата.
• Новое окружение сверено с требованиями продукта по списку, расхождения устранены.
• Сайт открывается на рабочем домене без ошибок, страницы каталога и карточки товара отображаются.
• Оформление заказа проходит полностью, включая оплату и уведомления.
• Административная часть доступна, права сотрудников сохранены.
• Обмен с учётной системой проверен в обе стороны и прошёл по расписанию.
• Фоновые задачи и агенты выполняются по расписанию.
• Почтовые отправления уходят, письма не попадают в спам по техническим причинам.
• Заказ, оформленный в момент переключения, проверен вручную.
• Журналы ошибок просмотрены, критичных записей нет.
• Старое окружение сохранено до окончания наблюдения и отключено по плану.
• Ответственный за наблюдение после переезда назначен, срок наблюдения определён.

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

Типичные ошибки и ограничения

Ошибки при переносе повторяются из проекта в проект. Вот те, что встречаются чаще всего.

• Копия снята частично: только файлы или только база. Восстановление даёт нерабочий сайт.
• Копия не проверена. Ошибку обнаруживают в момент, когда она уже критична.
• Настройки окружения перенесены «по памяти». Расхождения проявляются не сразу, а при обращении к конкретному модулю.
• Обмен проверен в одну сторону. Заказы перестают уходить в учётную систему, и это замечают по жалобам покупателей.
• Фоновые задачи не перенесены. Цены и остатки перестают обновляться.
• Старое окружение отключено сразу после переключения. Возврат становится невозможен.
• Нет ответственного за наблюдение. Ошибки копятся, пока не превращаются в инцидент.

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

Какие исходные данные подготовить для оценки

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

• Количество сайтов на установке и их домены.
• Объём файлов и базы данных.
• Список используемых модулей и сторонних решений.
• Перечень интеграций с описанием направления обмена и расписания.
• Расписание фоновых задач и агентов.
• Схема почтовых отправлений.
• Требования к окружению, если они уже известны.
• Ограничения по времени простоя и предпочтительное окно переключения.
• Ответственные за каждый блок со стороны заказчика.
• Наличие и состояние предыдущих резервных копий.

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