Перенос сайта Битрикс на другой хостинг

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

Главный страх клиента: сайт ляжет, и пойдут потери

Самое частое опасение — что во время переезда сайт станет недоступен и бизнес потеряет заказы. Так бывает, когда переключают DNS вслепую, без подготовки, и трафик идёт то на старый, то на новый хостинг, пока запись расходится по провайдерам. Мы строим процесс иначе. Старый хостинг работает и принимает заказы весь период подготовки, новый поднимается параллельно и проверяется на техническом домене. Заранее, за сутки-двое, понижаем TTL у DNS, чтобы смена адреса распространилась за минуты, а не за сутки. Само переключение делаем в согласованное окно минимальной нагрузки. В результате реальный простой стремится к нулю, а пользователи не замечают, что сайт переехал на другую площадку.

Мы не считаем переезд завершённым в момент переключения DNS. После него проверяем работу всех разделов, форм, корзины и оплаты, смотрим логи на ошибки, контролируем отправку почты и работу cron-задач. Если что-то ведёт себя не так, мы видим это первыми, а не узнаём от клиента через неделю.

Проблема вторая: страх потерять данные

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

Проблема третья: на новом хостинге что-то не заработает

Сайт Битрикс капризен к окружению: ему важны конкретные версии PHP и MySQL, правильные права доступа, настроенный кэш и рабочая отправка почты. Перенести файлы на хостинг с кривым окружением — значит получить сайт с ошибками. Мы разворачиваем рекомендованную BitrixVM с верными версиями ПО, настраиваем права на файлы и каталоги по требованиям Битрикс, поднимаем кэш и сессии, проверяем отправку почты. Отдельно переносим cron-задачи и агентов — фоновые процессы, которые обновляют каталог, обмениваются с 1С и шлют уведомления. Перед переключением прогоняем проверку по встроенной панели Битрикс, которая показывает соответствие сервера требованиям платформы. Это превращает «вроде скопировали» в «проверили по чек-листу вендора».

Проблема четвёртая: что если после переключения станет хуже

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

Как устроен наш процесс переноса

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

• Аудит и подбор. Изучаем текущий хостинг, нагрузку, версии ПО и требования сайта. Подбираем подходящий хостинг, VPS или выделенный сервер с запасом по ресурсам под Битрикс.
• Полный бэкап. Снимаем резервную копию всех файлов и базы данных, фиксируем cron-задачи, агентов и настройки почты — это страховка и точка возврата.
• Новое окружение. Разворачиваем BitrixVM на новом хостинге, настраиваем nginx, PHP, MySQL, права доступа, кэш и сессии по рекомендациям вендора.
• Развёртывание копии. Переносим файлы и базу один в один, поднимаем сайт на техническом домене и сверяем его с боевым по данным и работе разделов.
• Понижение TTL и переключение DNS. Заранее понижаем TTL, а в согласованное окно переключаем DNS на новый хостинг — простоя практически нет.
• Проверка и резерв. Проверяем работу, логи и почту после переезда, держим старый хостинг в резерве для быстрого отката.

Почему важна экспертиза именно по BitrixVM

BitrixVM — это не просто набор пакетов, а выверенное вендором окружение, в котором десятки параметров влияют на скорость и стабильность сайта. Администратор без опыта работы с Битрикс собирает окружение «как привык», и сайт формально запускается, но работает с ошибками: то отваливается композитный кэш, то не уходит почта, то фоновые агенты висят. Мы десять лет работаем только с Битрикс и знаем подводные камни платформы: какие права нужны каталогам upload и bitrix, как правильно настроить пулы и кэш, какие версии PHP и MySQL рекомендованы под вашу редакцию. Поэтому после нашего переезда сайт не просто открывается — он работает так, как задумано вендором.

Что вы получаете на выходе

По завершении переезда у вас на руках сайт на 1С-Битрикс, работающий на новом хостинге с запасом по ресурсам, в чистом окружении BitrixVM с верными правами, кэшем и рабочей почтой. Все данные перенесены и сверены, cron-задачи и интеграции работают, адреса страниц и позиции в поиске не изменились. Аккаунт хостинга оформлен на вас, мы передаём документацию по окружению и доступам — привязки к подрядчику не возникает. Старый хостинг какое-то время остаётся в резерве, после чего его можно спокойно отключить.

Частые возражения — и честные ответы

«У нас большой магазин с базой в десятки гигабайт, его невозможно перенести без простоя». Большие базы — наш привычный сценарий. Основной массив данных переносим заранее, а в окно переключения досинхронизируем только свежие изменения. Мы переносили магазины с базой больше десяти гигабайт на новый VPS с нулевым простоем — размер базы влияет на длительность подготовки, но не на доступность сайта.

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

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

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

Логика реальных переездов: чему учат наши проекты

За годы инфраструктурных переносов мы вывели несколько закономерностей, которые экономят клиентам нервы и деньги. Первая: TTL нужно понижать заранее, а не в момент переключения — иначе смена DNS растягивается на часы, и часть пользователей видит старый сайт, а часть новый. Вторая: сверка базы число к числу обязательна даже на «простых» сайтах, потому что частичная потеря данных при копировании не видна глазом и вскрывается в самый неподходящий момент. Третья: cron-задачи и агенты — самая забываемая часть переезда, и именно их отсутствие приводит к тому, что каталог перестаёт обновляться, а почта не уходит. Мы фиксируем расписания на этапе бэкапа и проверяем их работу после переключения.

Показательный пример из практики — переезд интернет-магазина с базой четырнадцать гигабайт на мощный VPS. Мы развернули BitrixVM с запасом по ресурсам, перенесли данные и в окно переключения досинхронизировали свежие заказы, простой составил ноль часов, а пики, на которых старый хостинг задыхался, новая площадка держит без тормозов. Другой случай — уход с подорожавшего хостинга: сняли полный бэкап, подняли сайт на новой площадке, переключили DNS ночью, и пользователи не заметили переезда. Третий — перенос сайта с кривым окружением, где мы заодно навели порядок в правах, кэше и почте, и ошибки, годами висевшие в логах, исчезли. Эти результаты не случайность, а следствие методики, где бэкап, сверка и откат — не опция, а фундамент.

Когда переезжать не нужно — и мы скажем об этом прямо

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

Перенос нагруженного магазина: на что обращаем внимание особо

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

Перенос корпоративного сайта и проекта со стендами

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

Что вы теряете, откладывая переезд

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

Давайте обсудим ваш переезд

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