Переезд коробочного Битрикс24 на новый сервер выглядит рутиной ровно до момента, когда выясняется: портал это не «сайт с базой», а связка из десятков гигабайт файлов, фоновых агентов, почтовых ящиков, телефонии, обмена с 1С и полусотни привычек, которые сотрудники считают само собой разумеющимися. Файлы копируются за вечер. Приведение в чувство всего остального растягивается на неделю, если к этому не подготовиться.
Ниже порядок работ, по которому мы переносим порталы клиентов, и список мест, где рвётся чаще всего.
Когда переезд оправдан, а когда лечит не ту болезнь
Хорошие причины сменить площадку понятны. Закончилась аренда сервера. Железо физически устарело. Портал перерос конфигурацию. Компания консолидирует инфраструктуру в одном дата-центре. Есть требование держать данные внутри страны. Меняется подрядчик, а вместе с ним хостинг.
Плохая причина ровно одна, зато встречается чаще остальных: «портал тормозит, давайте переедем на сервер помощнее». Иногда это правда помогает. Но медленный коробочный Битрикс24 обычно следствие того, что база разрослась без обслуживания, кэш настроен формально, поиск переиндексируется в рабочие часы, а на одном хосте вместе с порталом живут ещё три проекта. Перенос такой конфигурации на более дорогое железо даёт эффект на пару месяцев, после чего всё возвращается.
Прежде чем планировать миграцию портала, стоит посмотреть на профиль нагрузки: что именно упирается, процессор, диск, память или конкретные тяжёлые запросы. Если узкое место окажется в настройках, рискованное мероприятие можно отложить и сэкономить.
Инвентаризация: что на самом деле переезжает
Перед началом работ полезно составить список сущностей, каждая из которых требует отдельного действия. Минимальный набор для коробочного портала выглядит так:
- код портала и каталог загрузок с файлами Диска, документами и вложениями к задачам;
- база данных со всей CRM, задачами, чатом и историей;
- задания планировщика и фоновые агенты;
- почта: параметры отправки писем и ящики, из которых портал забирает входящие;
- SSL-сертификаты и записи DNS;
- вспомогательные сервисы серверного окружения: кэширование, полнотекстовый поиск, обработка медиа, обмен сообщениями в чате;
- интеграции, привязанные к адресу сервера: обмен с 1С, телефония, входящие вебхуки, платёжные сервисы;
- лицензионный ключ и данные активации;
- решения из Маркетплейса и собственные доработки в служебных каталогах.
Последний пункт приносит больше всего сюрпризов. За несколько лет жизни портала в нём накапливаются правки, о которых знал только предыдущий администратор: свой обработчик событий, скрипт выгрузки, самописный модуль. На новом сервере они либо не заводятся, либо заводятся молча наполовину.
Требования к новой площадке
Официальные технические требования к коробочному Битрикс24 стоит открыть и сверить построчно, а не по памяти: они меняются от версии к версии. На сентябрь 2026 года ключевое из документации выглядит так. PHP версии 8.2 и выше с расширениями GD, XML, FreeType, поддержкой регулярных выражений и Zlib, желательно с акселератором вроде OPcache. Из баз данных поддерживаются MySQL 8.x (Percona Server) и PostgreSQL 11 и выше, причём PostgreSQL только для лицензий Enterprise. Oracle и MSSQL не поддерживаются. В качестве веб-сервера рекомендован Apache 2.4.x, nginx версии 1.16 и выше использовать можно, но настраивать его придётся самостоятельно.
Минимальные 2 ГБ памяти и 10 ГБ диска из документации это порог запуска, а не рабочая конфигурация. Для реального портала считать нужно от объёма данных: размер каталога загрузок, размер базы, скорость их прироста за последний год. Практическое правило простое, берите двукратный запас по диску относительно текущего объёма. Иначе через полгода придётся переезжать снова или экстренно расширять раздел.
Отдельно проверьте часовой пояс, локали и кодировку на новом сервере. Расхождение в таймзоне не роняет портал, но сдвигает время в календарях, отчётах и уведомлениях. Обнаруживается это обычно через неделю, когда кто-то опаздывает на встречу.
Два маршрута переноса и как выбрать свой
Штатный механизм резервного копирования живёт в административной панели: Настройки → Инструменты → Резервное копирование. Там создаётся архив, там же лежит список копий и настройки автоматического копирования. Для восстановления на новом сервере используется скрипт restore.php, его кладут в корневой каталог и открывают в браузере. Мастер спрашивает источник архива (файл в корне, уже распакованные данные, загрузка с другого сайта или из облака), пароль, если архив шифровался, и параметры подключения к базе. После завершения служебные файлы, то есть сам скрипт, архив и дамп, нужно удалить.
Есть нюансы, о которых лучше знать заранее. Архив делится на части: максимальный размер части 200 МБ, оптимальным документация называет 100 МБ. Для портала с сотней гигабайт вложений это означает сотни файлов и процесс, которым неудобно управлять. Копии привязаны к лицензионному ключу, а повторный ввод ключа на другом сервере блокирует запись новых копий в облако. Это защита от переполнения хранилища, но при неаккуратном порядке действий она выглядит как поломка. После восстановления бывает нужно переименовать .htaccess.restore в .htaccess, иначе не заработают человекопонятные адреса.
Отсюда правило выбора. Портал компактный, вложений немного, простой на несколько часов допустим: штатный архив плюс restore.php закрывают задачу. Портал крупный, каталог загрузок исчисляется десятками гигабайт, простой должен уложиться в ночь: переносите файлы синхронизацией, а базу отдельным дампом.
Перенос большого портала по частям
Схема для крупных установок отличается тем, что тяжёлые данные едут заранее, а в окно простоя попадает только дельта.
Файлы копируются синхронизацией в два прохода. Первый идёт за несколько дней до переезда и он самый долгий. Второй запускается непосредственно в окно работ, забирает только изменившееся и занимает минуты вместо часов. База снимается дампом с блокировкой на согласованном снимке, чтобы данные не разъехались во время выгрузки. Для очень больших баз имеет смысл физическая копия вместо логического дампа, она восстанавливается заметно быстрее.
На новом сервере после разворачивания проверяются параметры подключения к базе в служебных файлах конфигурации, права доступа (файлы не ниже 0644, каталоги 0755, это требование из документации по переносу) и совпадение кодировки с правилами сравнения строк. Расхождение в collation между старой и новой базой даёт весёлый эффект: поиск по клиентам перестаёт находить записи с буквой «ё» или начинает считать разными строки, отличающиеся регистром. Кэш после переезда чистится полностью, потому что файловый кэш от предыдущего сервера содержит абсолютные пути и приносит с собой ошибки, которых на новом месте быть не должно.
Порядок работ: сначала репетиция
Мы никогда не делаем боевой перенос первым. Схема из четырёх шагов дороже по времени, но снимает большую часть рисков.
Шаг первый, тестовый перенос. Копия портала разворачивается на новом сервере под служебным адресом, закрывается от посторонних и от поисковых систем. На этой копии проверяется всё, что перечислено ниже в чек-листе приёмки. Здесь же выясняется реальное время переноса: сколько на самом деле копируются файлы и разворачивается база. Эта цифра нужна, чтобы честно назвать длительность окна простоя, а не пообещать два часа и уйти в утро.
Шаг второй, согласование окна. Дата и время выбираются с запасом и заранее сообщаются сотрудникам. Отдельно предупреждаются те, кто работает с порталом извне: колл-центр, склад, бухгалтерия с обменом 1С. Нерабочая ночь пятницы удобна технически и неудобна тем, что при проблемах вы будете чинить портал в выходные без поддержки хостера.
Шаг третий, боевой перенос. Портал переводится в режим, когда пользователи не создают новых данных, снимается финальная дельта файлов и свежий дамп базы, всё разворачивается на новом сервере, переключается адресация. За сутки-двое до этого стоит уменьшить время жизни DNS-записей до пяти минут. Тогда переключение произойдёт быстро, а не размажется на сутки, в течение которых часть сотрудников работает на старом сервере, а часть на новом. Раздвоение базы это самая неприятная авария переезда, потому что склеивать данные придётся вручную.
Шаг четвёртый, наблюдение. Первые три-пять дней после переезда логи смотрят ежедневно: ошибки PHP, отказы почты, зависшие задания планировщика, жалобы пользователей. Старый сервер в это время держат живым, выключенным из работы, но готовым к возврату.
Где рвётся чаще всего
Список ниже собран из реальных инцидентов, а не из теории. Почти всё в нём проверяется на тестовой копии за час.
Интеграции, привязанные к адресу сервера. Обмен с 1С, телефония, входящие вебхуки от сторонних сервисов, платёжные шлюзы. Везде, где на другой стороне прописан IP или домен, настройки надо обновить. Часть контрагентов дополнительно держит списки разрешённых адресов, и заявку на добавление нового IP лучше подать до переезда, а не в ночь работ.
Почта. Новый сервер означает новый адрес отправки. Если записи SPF и DKIM не обновлены, письма портала начинают уходить в спам, и узнают об этом по сорванным сделкам. Отдельно проверяются ящики, из которых портал забирает входящие письма в CRM: доступ к ним нужно подтвердить заново.
Планировщик задач. Фоновые операции портала должны запускаться регулярно. Если задания на новом сервере не завести, внешне всё работает, но бизнес-процессы стоят, роботы не срабатывают, рассылки не уходят, отчёты не пересчитываются. Это самая тихая поломка переезда, она не даёт ошибок, просто ничего не происходит.
Вспомогательные сервисы окружения. Кэширование, полнотекстовый поиск, обмен сообщениями в чате идут отдельными компонентами, и состав их зависит от того, какое серверное окружение используется. При ручной сборке нового сервера про них регулярно забывают: портал открывается, CRM работает, а чат не обновляется без перезагрузки страницы.
Поисковый индекс. Индекс не переносится вместе с файлами. После переезда его нужно перестроить, и на большой базе это заметная нагрузка, так что планируйте переиндексацию на нерабочее время.
Права доступа и владелец файлов. После копирования от имени root каталоги нередко остаются недоступными веб-серверу на запись. Проявляется это не сразу: портал открывается, но не сохраняется файл на Диск или не создаётся кэш.
Сертификат и смешанный контент. Новый сертификат ставится до переключения адресации, а не после. Иначе первые пользователи увидят предупреждение браузера и сделают вывод, что портал взломали.
Собственные доработки. Правки в служебных каталогах, скрипты выгрузки, самописные обработчики переносятся руками и проверяются отдельно. Если предыдущий подрядчик не оставил документации, инвентаризацию делают по датам изменения файлов.
Как это выглядит на практике
Сценарий ниже собирательный, но узнаваемый. Производственная компания, около 80 сотрудников в портале, коробка живёт четыре года. Хостер поднимает стоимость аренды, принимается решение переехать на собственный сервер в дата-центре. Внутренний системный администратор оценивает работу в один вечер: скопировать каталог, снять дамп, поднять на новом месте.
Вечер уходит на копирование, потому что каталог загрузок оказывается на 60 ГБ больше, чем предполагалось: в нём лежат сканы актов за четыре года. К утру портал открывается, сотрудники заходят, CRM работает. Дальше проблемы всплывают по одной. В понедельник выясняется, что не уходят письма клиентам, записи домена остались настроены на прежний адрес. Во вторник бухгалтерия сообщает, что из 1С не пришли документы, на стороне обмена прописан старый IP. В среду руководитель отдела продаж замечает, что напоминания по сделкам перестали приходить: задания планировщика на новом сервере просто не завели, и все фоновые операции стоят с ночи переезда. В четверг обнаруживается, что поиск по клиентам находит половину записей, индекс никто не перестраивал.
Ни одна из этих поломок не была сложной, каждая заняла от пятнадцати минут до часа. Но растянулись они на неделю, обнаруживались через жалобы сотрудников, а не через проверку, и всю эту неделю отдел продаж работал вслепую. Полдня тестового переноса на служебном домене закрыли бы все четыре пункта до боевых работ.
Окно простоя и план отката
План отката пишется до начала работ и содержит ответ на один вопрос: при каких признаках мы возвращаемся на старый сервер. Признаки формулируются заранее и в измеримом виде. Например: портал не поднялся за отведённое время, обмен с 1С не заработал к утру, потеряна часть вложений. Без такого списка решение принимается в четыре часа ночи уставшим человеком, и принимается оно обычно в пользу «сейчас ещё немного починим».
Старый сервер не выключается сразу. Две-четыре недели он стоит нетронутым, и за это время всплывают редкие сценарии: квартальный отчёт, ежемесячная выгрузка, годовой документ, который вдруг не открывается. Пока старая площадка жива, любую потерю можно восстановить.
Чек-лист приёмки после переноса
Проверяется на тестовой копии, затем повторяется на боевой:
- вход сотрудников, в том числе через мобильное приложение;
- CRM: создание сделки, движение по стадиям, срабатывание роботов;
- запуск и завершение бизнес-процесса;
- отправка письма из портала и получение входящего в CRM;
- телефония: входящий и исходящий звонок, запись разговора;
- Диск: загрузка файла, открытие старого документа, права на папки;
- чат и уведомления в реальном времени;
- поиск по CRM и по документам;
- обмен с 1С в обе стороны;
- отчёты с данными за прошлые периоды;
- выгрузка и печать документов;
- резервное копирование на новом сервере, настроено и проверено восстановлением.
Последний пункт пропускают чаще всего. Портал переехал, работает, все выдохнули, а копий на новой площадке нет ещё месяц. Настраивать их нужно в тот же день.
Кто выполняет работы
Перенос коробочного Битрикс24 на новый сервер лежит на стыке системного администрирования и знания самого продукта. Админ без опыта работы с порталом развернёт файлы и базу, но не проверит роботов, обмен и вспомогательные сервисы. Специалист по Битрикс24 без доступа к серверу не соберёт окружение. Поэтому либо работают двое, либо это делает подрядчик, у которого обе компетенции внутри.
Мы такие переезды ведём под ключ: инвентаризация текущей площадки, подбор конфигурации, тестовый перенос, боевое окно с планом отката и сопровождение первых дней. Если у вас нет своего администратора или предыдущий подрядчик уже недоступен, посмотрите наши услуги по Битрикс24, миграция портала входит в их состав. Оценка делается после осмотра сервера: без понимания размера базы, состава интеграций и количества доработок любые сроки будут выдуманными.
Частые вопросы
Сколько времени занимает перенос портала?
Само окно работ для среднего портала занимает от нескольких часов до ночи. Полный цикл с инвентаризацией, тестовым переносом и проверками растягивается от нескольких дней до пары недель, в зависимости от объёма данных и количества интеграций. Реальную длительность окна показывает тестовый перенос, до него любые оценки приблизительны.
Нужно ли покупать лицензию заново при смене сервера?
Нет, лицензия принадлежит компании, а не серверу. Но ключ и данные активации участвуют в переносе, а резервные копии привязаны к лицензионному ключу, поэтому порядок действий с ключом лучше уточнить заранее, до начала работ, а не выяснять это ночью.
Можно ли перенести портал вообще без простоя?
Полностью без простоя нельзя. Момент переключения всё равно требует остановки записи данных, иначе часть информации останется на старом сервере. Но простой сокращается до десятков минут, если файлы синхронизировать заранее, а в окно работ переносить только изменения и базу.
Что делать, если после переезда портал стал работать медленнее?
Сначала исключить очевидное: не запущена ли в этот момент переиндексация поиска, настроено ли кэширование, хватает ли памяти, не делит ли сервер ресурсы с другими проектами. Если конфигурация в порядке, смотреть на медленные запросы к базе. Обычно причина там, и к переезду она отношения не имеет, просто на прежнем железе её маскировал запас мощности.
Стоит ли одновременно с переездом обновлять версию портала?
Лучше нет. Два изменения сразу означают, что при поломке непонятно, какое из них виновато. Разумный порядок: переехать, убедиться, что всё работает, выждать неделю и обновляться отдельным мероприятием.
Переезд коробочного портала не самая сложная техническая задача, но самая нетерпимая к спешке. Почти все неприятные истории начинаются со слов «там же просто файлы скопировать». Час, потраченный на инвентаризацию, и один тестовый прогон стоят дешевле, чем неделя разбирательств с потерянными вложениями и молчащими бизнес-процессами.