Как перенести несколько установок 1С‑Битрикс, расположенных на разных серверах одного хостинга, на единый сервер на другом хостинге?

Здравствуйте. Как перенести 10–12 отдельных сайтов на 1С‑Битрикс (в настоящее время размещённых на разных VPS у одного хостера) на один сервер на другом хостинге и объединить их в одну установку/мультисайт с единой админ‑панелью? Читал, что в Битрикс есть мультісайтовость и не требуются отдельные лицензии, и видел стандартный инструмент переноса сайта между хостингами, но не нашёл информации о массовом переносе нескольких сайтов в одну установку — какие существуют решения и порядок действий для такой массовой миграции и объединения?
  • 15 мая 2026 г. 8:02
Ответы на вопрос 4
Короткий ответ — да, можно. Но это не «поставил мигратор на 10 сайтов и всё само объединилось» — есть два принципиально разных пути и набор подготовительных работ. Ниже — что можно сделать, какие у каждого пути риски и пошаговый план в общем виде.

Варианты решения
1) Перенос каждой территории в одну установку (рекомендуемый, если хотите единую админ‑панель)
- Создаёте на новом сервере одну чистую/актуальную установку 1С‑Битрикс (одна кодовая база + одна БД).
- Для каждого сайта из старых VPS переносите только его «сайт» в эту установку — то есть добавляете новую запись b_site / b_lang и импортируете шаблон, страницы, инфоблоки, медиафайлы, настройки сайта.
- Это самый правильный с точки зрения архитектуры мультисайт (одна инсталляция — много сайтов), но технически самый трудоёмкий, потому что нужно мерджить контент/инфоблоки/файлы и разрешать конфликты ID и ссылок.

2) Просто собрать все старые инсталляции на одном сервере, не объединяя в мультисайт
- На новом сервере разместить 10–12 отдельных сайтов (каждый в своём корне, со своей БД). Лёгкий перенос: архив файлов + дамп БД -> восстановление -> настройка виртуальных хостов.
- Удобно и быстро, минимальные риски. Но админ‑панель у каждого сайта останется своя; единая админ‑панель возможна только через дополнительную разработку (SSO/централизованный мониторинг), но не из коробки в Битрикс.

3) Гибрид / профессиональный импорт с маппингом
- Для сайтов с простым содержимым — использовать встроенные экспорт/импорт (мастера) и перенос шаблонов/инфоблоков.
- Для сложных или конфликтующих — делать ручной перенос с временными БД, скриптами для переназначения ID (iblock_id, file_id, user_id), слиянием прав, корректировкой ссылок.

На что обязательно обратить внимание до начала
- Версия ядра Bitrix и модулей на всех исходных установках — лучше привести всё к одной версии перед объединением.
- Размеры БД и /upload — от них зависит сложность и время переноса.
- Наличие кастомных компонентов, модулей, расширений — их нужно перенести в /local или /bitrix/components.
- Пользователи: одинаковые email/логины — нужно решить, объединять ли аккаунты.
- Лицензии и платные модули/компоненты — проверьте лицензионные условия (иногда ключи/модули привязаны к домену/инсталляции).
- Cron, очереди, задачник, внешние интеграции (1C, API) — перенастроить.
- SSL, почтовые настройки, robots/sitemap, SEO‑настройки.
- Параметры PHP, расширения, права на файлы, дисковая квота.

Общий пошаговый план (вариант «объединяем в одну установку»)
1. Подготовка
- Сделать полный бэкап (файлы + дамп БД) каждого старого VPS.
- Сверить версии 1С‑Битрикс и модулей; на новом сервере установить ту же или более новую версию (рекомендуется последняя стабильная).
- Настроить окружение (PHP, MySQL/MariaDB, nginx/apache, права, cron).

2. Создать чистую инсталляцию на новом сервере
- Установить Bitrix и убедиться, что работающая «тестовая» инсталляция.
- Настроить базовую конфигурацию и резервирование.

3. Для каждого сайта:
а) Экспорт содержимого и шаблона
- Скопировать шаблоны: /bitrix/templates/ и /local/templates/ для конкретного сайта; компоненты /bitrix/components/ и /local/components/; кастомные модули /bitrix/modules/ и /local/modules/; медиа /upload/.
- Экспортировать инфоблоки/каталоги: через стандартный экспорт XML (если используется инфоблок) или средствами модуля «Экспорт/Импорт» в админке. Также экспортировать привязанные свойства, цены, торговые каталоги если есть.
- Экспортировать меню, страницы, пользовательские настройки сайта (b_menu, b_option, b_event_message и т.д.) — либо через встроенный мастер экспорта сайта (если подходит), либо через выборочные SQL‑дампы таблиц.

б) Импорт в целевую БД/установку
- Создать новую запись сайта в админке (Настройки -> Сайты) — задать SITE_ID, домены и корневые папки.
- Импортировать шаблон и компоненты в кодовую базу.
- Импортировать данные инфоблоков/элементов: при импорте нужно следить за ID — если ID в целевой БД пересекаются, делать remap (скрипты/временная таблица).
- Импортировать файлы в /upload или в специальную папку, обновить таблицы b_file / b_file_associated (либо использовать инструмент импорта, который подправит ссылки).
- Обновить ссылки и пути в контенте (внутренние ссылки, картинки в текстах и т.п.) — можно с помощью SQL‑замен или специальных скриптов.

4. Тестирование
- После импорта каждого сайта проверять работоспособность: страницы, формы, авторизации, корзины, интеграции.
- Выполнить индексацию поиска, если нужно.
- Проверить права доступа, шаблоны, CSS/JS, кэш.

5. Финальные шаги
- Настроить виртуальные хосты для доменов и обновить DNS.
- Установить SSL.
- Перенастроить cron, задачу по очистке кэша и обновлению индекса.
- Мониторинг и откатный план (если что-то пойдёт не так).

Типичные сложности и как с ними бороться
- Конфликты ID (iblock_id, user_id, file_id) — решаются remap‑скриптами и пересозданием связей.
- Дубли пользователей — нужно решить, мерджить ли по email или создавать префиксы.
- Конфликты компонент/модулей — убедитесь, что кастомные компоненты не перезаписывают друг друга; лучше переносить в /local.
- Большие объёмы файлов/БД — перенос по SFTP/rsync, дампы по частям, возможно использовать репликацию/pipe.
- SEO: сохранить URL структуры, 301 правила, robots, перенаправления.
- Платные модули/ключи — заранее согласовать с поставщиками.

Инструменты и команды, которые пригодятся
- rsync для копирования файлов (быстро, с инкрементом).
- mysqldump / mysql для дампов и частичного импорта.
- SQL‑скрипты для выборочного экспорта/импорта таблиц.
- Скрипты на PHP/SQL для remap ID и обновления ссылок.
- Встроенные в Битрикс мастера экспорта/импорта сайтов и инфоблоков (использовать, если подходят).

Рекомендации
- Делайте перенос сначала для 1–2 сайтов как тестовый прогон, чтобы наработать процесс и скрипты.
- Если сайты большие и/или есть сложные интеграции — лучше привлечь опытного разработчика/интегратора Bitrix. Ошибки при мердже БД могут привести к долгой отладке.
- Документируйте все манипуляции и держите план отката.

Если хотите, могу:
- Прислать более детальный чек‑лист с точными таблицами Bitrix, которые обычно нужно переносить для «сайта» (b_site, b_lang, b_iblock*, b_file*, b_menu и т.д.).
- Оценить трудоёмкость, если вы пришлёте: версии Bitrix, размер БД и /upload для каждого сайта, список кастомных модулей/интеграций.

Напишите, какой у вас сейчас вариант (версия Bitrix, структура сайтов, сколько инфоблоков/пользователей, есть ли кастомные модули), и я предложу конкретный план и прикидку трудозатрат.
с учётом комментариев и ответов: <br/> <blockquote>есть ли какое-то решение, чтобы массово перенести это всё под одну админ панель и на один сайт?</blockquote> <br/> Ответ такой:  а) зависит от лицензии и б) автоматически - нет. Вручную - зависит от нюансов. <br/> Теперь подробнее: <br/> Лицензия "Старт" <a href="https://www.1c-bitrix.ru/products/cms/license.php" rel="nofollow">позволяет только 2 сайта</a> , остальные лицензии такого ограничения не имеют. Если лицензии на сайтах разные, то надо выбрать ту, которая по возможностям покрывает любой из сайтов. <br/> <br/> Допустим простой случай: лицензия везде одинакова, и это "Стандарт". <br/> Дальше зависит от того, как сделаны эти страницы. Чтобы не путаться в терминологии, я буду ваши "сайты, лежащие на разных VPS" называть <b>проектами</b> , а под <b>сайтом</b> понимать сущность в Битриксе. <br/> <br/> 1) обычные статичные страницы. Непонятно, зачем тут Битрикс, но это самая простая группа случаев. Буду разбирать группу от простого к сложному. <br/> 1а) у каждого проекта шаблон сайта имеет уникальный код,. В шаблоне сайта .default нет используемых шаблонов компонентов. В bitrix/php_interface нет кода,  или он идентичен на всех проектах. <br/> (* здесь " <b>шаблон сайта</b> " это терминология Битрикса. Каждый сайт может использовать несколько шаблонов сайта, это задаётся в настройках сайта  ). <br/> <b>Идеальный случай</b> . Берём VPS, ставим туда BitrixEnv ( aka Bitrix Virtual Appliance ). ( Упс, опять коллизия терминологии. В BitrixEnv <b>сайт</b> - это та сущность, которая создаётся через "8. Configure pool sites" - "1. Create a site" . Пока идёт речь про BitrixEnv, под сайтом понимается именно она ). <br/> В BitrixEnv после начальной настройки создаём сайт типа ext_kernel , а уже нужные нам сайты - как link к этому сайту. ( сам я этот путь не пробовал, извините ). В итоге вы получите каталоги /home/bitrix/ext_www/mysite1.ru , /home/bitrix/ext_www/mysite2.ru и так далее, внутри которых будут симлинки на bitrix и upload , ведущие в каталог ext_kernel сайта.  Раскидываете туда контент и радуетесь. <br/> <br/> 1б) то же самое, но В bitrix/php_interface есть различный код, но он не может быть запущен из админки ( например, это не обработчики каких-то событий ). <br/> Тут единственное дополнительное действие: перемещаем в каждом проекте bitrix/php_interface в local/php_interface , проверяем, что нет проблем с путями ( нет инклюдов с  "bitrix/php_interface/...", нет относительных инклюдов типа "../modules/.." . <br/> <br/> 1в) шаблоны сайтов неуникальны, и/или в шаблоне сайта .default что-то лежит используемое. <br/> Похоже на 1б: папку bitrix/templates переместить в local/templates, проверить пути и поправить при необходимости. <br/> <br/> 1г) В bitrix/php_interface есть различный код, и он может запускаться из админки. <br/> Это настоящая проблема, Решение тут одно: объединить содержимое всех папок php_interface в одну кучу . <br/> Вариант "переложить bitrix/php_interface из всех проектов в bitrix/php_interface/s1 , bitrix/php_interface/s2 и так далее на новой площадке" не рассматриваю, потому что он не для этого случая ( а для одного очень частного случая, который никому не нужен практически никогда). <br/> <br/> 2) используются инфоблоки. <br/> Тут придётся на всех проектах (кроме одного) делать экпорт каждого инфоблока в XML, потом на новой площадке импорт, смотреть ID созданного инфоблока и править параметры вызова компонентов в публичной части каждого проекта. А если есть свойства привязки к другим инфоблокам, то это практически провал. <br/> <br/> 3) используются highload блоки. <br/> Тут можно попробовать импорт-экспорт, и на крайний случай можно сами highload блоки завести руками через админку, а данные перелить старым добрым SQL. <br/> <br/> 4) веб-формы, опросы и прочее. <br/> Для них импорта/экспорта нет, увы. <br/> <br/> Нулевой случай: <br/> В BitrixEnv все сайты создаёте как kernel, лежать они будут раздельно, каждый со своим ядром, файлами в upload и прочим. На лицензиях не сэкономите, но, возможно, сэкономите на VPS.
Вы сначала подумайте, а точно это нужно. 10-12 сайтов это выглядит как то что вы хотите создать себе на ровном месте проблемы. <br/> Потому что это единая админка, единая база данных будет, единый список пользователей, заказов... <br/> Кто бы что не говорил, но многосайтовость на битриксе это по большей степени для создания многоязычности и мультирегиональности. В остальном(сугубо мое мнение) лучше разделять. Конечно нужно смотреть что за сайты, если это простые новостные, то можно и объединить(размещать из одного места сразу на разных сайтах новости и статьи вполне будет удобно), но если это магазины, то я бы не стал(отмахивался бы всеми возможными способами от такого решения), особенно если есть интеграции хотя бы у парочки с 1С, потому что даже обмены придется распредлять так чтобы они не пересекались иначе будут ошибки.
Да, в Битриксе есть штатная многосайтовость, которая позволяет управлять 10–12 сайтами из одной админки на одном ядре без покупки отдельных лицензий. Переносите один сайт как основной через агент «Перенос сайта с одного хостинга на другой», а остальные добавляете через «Настройки» → «Настройки продуктов» → «Многосайтовость», при переносе контента заменяя SITE_ID в таблицах БД. Все домены настраиваете в веб-сервере на одну корневую папку — Битрикс сам определяет сайт по домену. По документации ищите «многосайтовость 1с битрикс» там подробно описано. <br/> <br/> Вы в вопросе не описали про контент сайта. Поэтому я на всякий случай оставлю это здесь: <br/>
Похожие вопросы