Один из самых рискованных моментов в жизни магазина на Битрикс — переезд на новый сервер. Файлы копируются быстро, а вот ошибки обычно прячутся в базе, кэше, cron и DNS. Разбираем, как подготовить перенос сайта Битрикс и не получить сюрпризы после запуска.
Вечером сайт на Битрикс работал нормально, утром уже поехал на новый сервер, а к обеду у владельца магазина появляются странные вопросы: почему заказ зависает, почему письма не уходят, почему часть страниц открывается с задержкой. Именно так обычно выглядит перенос сайта битрикс, если его сделали как обычное копирование файлов. На деле это не копирование, а управляемая миграция, где важны база, кэш, cron, DNS и поведение сторонних модулей.
Самая частая ошибка здесь простая: все смотрят на то, как перенеслись файлы, и забывают, что сайт живёт не в папке, а в связке компонентов. Магазин может стартовать, но фоновые задачи уже сломаны. Или админка открывается, но обмен с 1С молчит. Или браузер показывает старую версию из кэша, а покупатели видят другой результат. Поэтому перенос нужно планировать как отдельный проект, а не как «перекинуть сайт на новый хостинг».
Ниже разберём, что делать до переезда, где ломается миграция Битрикс на новый сервер, как не потерять заказы и как проверить результат после запуска. Это практический разбор для тех, кто не хочет ловить ошибки уже на боевом трафике.
Перенос сайта Битрикс: почему ломается не копирование, а переключение
На первый взгляд всё выглядит просто. Копируете файлы, переносите базу, включаете новый сервер, и сайт снова в строю. Но в проектах на Битрикс почти никогда не бывает только файлов и базы. Есть кэш, агенты, cron, сессии, почтовые события, внешние интеграции и зависимости от окружения. Именно в момент переключения эта связка и начинает вести себя иначе.
Хуже всего то, что многие ошибки не видны сразу. Страница может открываться, но часть логики уже работает не так. Пользователь оформляет заказ, а письмо не уходит. Менеджер меняет статус, а обмен с CRM не срабатывает. Владелец магазина смотрит на главную и думает, что всё хорошо, хотя проблема сидит в другом слое.
Перенос сайта Битрикс лучше воспринимать как цепочку переходов. Сначала готовится копия. Потом проверяется окружение. Потом тестируется поведение сайта. И только после этого меняется DNS или другой способ переключения трафика. Если перепутать порядок, получится не миграция, а лотерея.
Где чаще всего ошибаются
Ошибка номер один — переносят только папку с сайтом и забывают про параметры сервера. Ошибка номер два — не проверяют версию PHP и расширения. Ошибка номер три — не смотрят на агенты и крон. Ошибка номер четыре — переводят трафик до того, как убедились, что тестовая копия работает одинаково.
Есть и менее очевидный риск. На старом сервере кэш мог маскировать проблему, а на новом кэш уже пустой. Тогда сайт начинает вести себя «честнее», и всплывают недочёты в шаблоне, запросах к базе или в самописных компонентах. Это не баг переноса. Это скрытая проблема проекта, которая просто дождалась своего часа.
Что можно сделать прямо сейчас:
- сверить версии PHP, MySQL/MariaDB и веб-сервера на старом и новом хостинге;
- проверить, какие модули и внешние библиотеки использует проект;
- составить список критичных сценариев: вход, корзина, заказ, оплата, обмен.
Миграция Битрикс на новый сервер: что подготовить заранее
Удачная миграция битрикс на новый сервер начинается не с команды копирования, а с подготовки. Чем спокойнее будет этот этап, тем меньше вероятность переделывать всё ночью. Для магазина особенно важно не просто перенести данные, а сохранить поведение системы под нагрузкой.
Первое, что нужно сделать, — зафиксировать исходное состояние. Без этого сложно понять, что именно изменилось после переезда. Второе — поднять тестовую копию. Третье — заранее проверить, как сайт ведёт себя на новом окружении. Если этого нет, любая проблема после запуска превращается в спор «это перенеслось так» или «это и раньше было».
| Что подготовить | Зачем это нужно |
|---|---|
| Полный бэкап файлов и базы | Чтобы можно было откатиться без потерь |
| Тестовую копию сайта | Чтобы проверить новую среду до переключения |
| Список модулей и интеграций | Чтобы не забыть зависимости и внешние сервисы |
| План переключения DNS | Чтобы понимать, когда и как пойдёт трафик |
| Порядок проверки после запуска | Чтобы быстро заметить сбой и не гадать по симптомам |
Важно ещё до переезда понять, где проект хранит временные данные. Это может быть файловый кэш, redis, memcached, временные папки загрузок, логи или отдельные очереди. Если такие точки не учесть, после запуска вы получите не один аккуратный перенос, а набор мелких аномалий, которые трудно отлавливать по одной.
Три действия до переноса:
- сделать резервную копию и проверить, что она реально разворачивается;
- сравнить конфигурацию старого и нового сервера по ключевым параметрам;
- запустить сайт на временном домене или через hosts и пройти основные сценарии.
Что проверить в окружении
Смотрите на PHP, расширения, лимиты памяти, размер upload, таймзону, права на файлы, версию базы и правила доступа к сокетам, если они нужны. Для Битрикса это не формальность. Один неверный параметр способен сломать больше, чем кажется по логам.
Ещё полезно проверить, совпадает ли часовой пояс на сервере и в проекте. Для магазина это влияет на акции, сроки доставки, автоматические статусы и расписание задач. Разница в несколько часов иногда выглядит как странный маркетинговый сбой, хотя причина лежит в обычной системной настройке.
Переезд магазина Битрикс: база, кэш и фоновые задачи
Если речь идёт именно про переезд магазина битрикс, у него есть своя специфика. Магазин почти всегда зависит от непрерывного потока данных: заказы, остатки, статусы, уведомления, интеграция с 1С, доставкой и оплатой. Поэтому перенос должен учитывать не только видимую часть сайта, но и все процессы, которые живут в фоне.
База данных здесь особенно чувствительна. На больших проектах она не просто хранит каталог. Она обслуживает корзины, заказы, скидки, историю пользователей, свойства товаров и журналы событий. Если миграция базы прошла с ошибкой или с потерей нюансов кодировки, проблемы могут появиться не сразу, а уже после первого потока заказов.
Кэш тоже играет свою роль. На старом сервере он может скрывать проблемные запросы. На новом кэш очищается, и сайт начинает честно выполнять всё заново. Это полезно для диагностики, но неприятно для тех, кто рассчитывал на «автоматически всё сохранится». Поэтому при переносе стоит отдельно планировать очистку и прогрев кэша.
Фоновые задачи и cron
Фоновые задачи часто забывают проверить, потому что они не попадают в обычный пользовательский сценарий. Но именно они отвечают за обмены, почту, автоматические статусы и отложенные действия. Если cron не запустился или запустился не по расписанию, магазин ещё какое-то время может выглядеть живым, но потом начнёт накапливать ошибки.
Проверьте, как отрабатывают агенты, есть ли доступ к нужным путям, и не поменялись ли пользователи, от которых запускаются задачи. На практике это одна из самых частых причин, почему после переезда магазин «вроде работает», но менеджеры уже получают жалобы на задержки.
- сверьте базу до и после переноса по размеру и количеству таблиц;
- проверьте корзину, оформление заказа и личный кабинет;
- сравните поведение кэша и фоновых задач на старом и новом сервере.
Если у вас есть интеграция с 1С, проверяйте обмен не только вручную, но и по расписанию. Разовый успешный обмен ещё не значит, что всё в порядке. Важно, чтобы повторяющиеся задания тоже выполнялись без ошибок.
Перемещение сайта Битрикс: DNS, SSL и почта
Само перемещение сайта битрикс заканчивается не тогда, когда файлы на месте. Оно заканчивается тогда, когда трафик корректно идёт на новый сервер, SSL работает без предупреждений, а почта не зависает где-то между старым и новым окружением. Именно здесь всплывают самые раздражающие мелочи.
DNS — отдельная тема. Если TTL был слишком большим, переключение может тянуться дольше ожидаемого. Часть пользователей уже попадёт на новый сервер, а часть ещё будет видеть старый. В этот момент легко получить путаницу в заказах, если обе площадки живут параллельно. Поэтому TTL лучше снижать заранее, а не перед самым переключением.
SSL-сертификаты тоже стоит проверять отдельно. Новый сервер может отдать корректный сайт по HTTP, но показать ошибку или предупреждение по HTTPS. Для покупателя это уже не техническая мелочь, а повод закрыть вкладку. Если магазин принимает оплату, такой сбой недопустим.
Почта и внешние сервисы
Почтовые сценарии часто ломаются из-за новых ограничений отправки, неверного IP или неочевидных правил у почтового провайдера. Иногда письма уходят, но попадают в спам. Иногда не уходят вообще. Для магазина это критично, потому что там завязаны уведомления о заказах, смене статусов и восстановлении пароля.
Не забывайте про внешние сервисы. Это могут быть вебхуки, API оплаты, службы доставки, маркетплейсы, CRM и антифрод-системы. Если у сервиса есть белый список IP, новый сервер нужно заранее туда добавить. Иначе после запуска вы увидите цепочку отказов, которую легко принять за проблему сайта.
Что проверить в день переключения:
- открывается ли сайт по HTTPS без предупреждений;
- попадают ли письма на тестовый адрес;
- идут ли запросы к внешним API с нового IP;
- не осталось ли пользователей на старом сервере из-за DNS-кэша.
Что проверить после запуска и как быстро откатиться
После запуска не надо сразу считать задачу закрытой. В первые часы после переноса сайт работает под самой честной проверкой. Именно в это время лучше всего видно, что забылось, где просела производительность и какой сценарий не пережил переезд.
Я всегда советую держать короткий список контроля. Он помогает не расползаться по десятку вкладок и не забыть про важные вещи. Начните с главной страницы, потом проверьте каталог, карточку товара, корзину, заказ, почту и админку. После этого запустите обмены и фоновые задачи. Если всё совпадает с ожиданиями, можно считать перенос успешным.
Порядок быстрого контроля
1. Открыть сайт по HTTP и HTTPS. 2. Проверить регистрацию и вход. 3. Добавить товар в корзину. 4. Оформить тестовый заказ. 5. Убедиться, что письмо ушло. 6. Запустить обмен и посмотреть логи. 7. Проверить cron и агенты.
Если проблема всё же всплыла, откат должен быть не импровизацией, а заранее понятной процедурой. Поэтому резервная копия и план возврата на старый сервер нужны не «на всякий случай», а как обязательная часть миграции. Хорошо, когда решение об откате принимается по фактам, а не по панике.
Когда сайт работает стабильно, не спешите отключать старый сервер мгновенно. Иногда полезно оставить короткое окно наблюдения, чтобы увидеть скрытые расхождения по трафику, заказам и уведомлениям. Это особенно полезно для магазинов с высокой нагрузкой.
Если нужен спокойный перенос, без спешки и ручного разбора в последний момент, проверьте сервер на support.orangecode.ru.