Перенос сотрудников между порталами Битрикс24: пошаговая инструкция

Перенос сотрудников между порталами Битрикс24 - задача, с которой ко мне приходят при слиянии компаний, разделении юрлица или переходе с коробочной версии на облако. Кнопки «перенести всех сотрудников на другой портал» в Битрикс24 нет и не предполагалось: система считает каждый портал независимым, со своей нумерацией пользователей и отделов. Всё, что выглядит как «просто скопировать структуру», на деле собирается через REST API, и это первое, о чём я предупреждаю клиента до того, как называть сроки.

Когда нужен перенос структуры компании между порталами Битрикс24

Чаще всего заказывают в четырёх ситуациях. Первая - покупка или продажа бизнеса, когда отдел продаж целиком уходит на портал новой управляющей компании. Вторая - разделение одного юрлица на два, например розница и опт разъезжаются по отдельным CRM. Третья - миграция с коробочной версии Битрикс24 на облачный тариф, потому что на коробке закончилась поддержка сервера или обновления встали намертво. Четвёртая - смена основного домена компании, когда старый портал решили не продлевать, а завести новый с чистого листа под текущий тариф.
В каждом случае задача одна и та же: на новом портале должна появиться та же оргструктура, те же сотрудники с теми же должностями и привязками, а история в CRM не должна «осиротеть», потеряв ответственного менеджера.

Что переносится вместе с сотрудниками, а что нет

Структура компании в Битрикс24 - это дерево отделов с полем PARENT для иерархии и UF_HEAD для руководителя. Сотрудник привязан к отделу через UF_DEPARTMENT, у него есть должность, роль в правах доступа и рабочий график. Всё это переносимо через REST API, но по частям и в строгом порядке.
А вот что не переезжает само по себе: переписка в Битрикс24.Чате, лента компании, история звонков, встречи в календаре и файлы на Диске. Их либо архивируют отдельно, либо сознательно оставляют на старом портале как архив. Отдельная головная боль - CRM: если не переназначить ответственных, все лиды и сделки старых сотрудников на новом портале повиснут на несуществующих ID, и менеджер откроет CRM, а своих клиентов там не увидит.

Способы переноса сотрудников между порталами Битрикс24

Штатный экспорт - для чего он на самом деле

В Битрикс24 есть экспорт списков (товары, элементы CRM, задачи), но для оргструктуры и учётных записей между двумя независимыми аккаунтами штатного инструмента нет. Экспорт пользователей в CSV даёт только справочную информацию для отчётности, обратно её не загрузить как полноценных сотрудников с правами и привязками к отделам. На эту иллюзию «просто выгружу и загружу» я трачу минут десять на каждой консультации, потому что заказчики находят кнопку экспорта и решают, что дело закрыто.

Перенос через REST API и Python-скрипт

Рабочий вариант - написать скрипт, который читает структуру и пользователей с исходного портала методами department.get и user.get, строит таблицу соответствия старых и новых ID и последовательно создаёт всё на втором портале: сначала отделы сверху вниз по иерархии (иначе department.add упадёт с ошибкой на несуществующем родителе), затем пользователей через user.add с привязкой к уже созданным отделам, затем права доступа и роли.
Вот так выглядит фрагмент запроса на добавление сотрудника через входящий вебхук:

curl -X POST "https://portal2.bitrix24.ru/rest/1/xxxxxxxxxxxxxxxx/user.add.json" 
  -H "Content-Type: application/json" 
  -d '{
    "NAME": "Иван",
    "LAST_NAME": "Петров",
    "EMAIL": "ivan.petrov@company.ru",
    "WORK_POSITION": "Менеджер по продажам",
    "UF_DEPARTMENT": [12]
  }'

Важный нюанс: на облачных тарифах REST API ограничен примерно двумя запросами в секунду, метод batch позволяет упаковать до 50 вызовов за один запрос - без него перенос полусотни сотрудников с проверкой ошибок растянется на час вместо нескольких минут. После переноса людей отдельным проходом обновляю ASSIGNED_BY_ID в сделках и лидах через crm.deal.list и crm.lead.list с фильтром по старому ID, иначе привязка сделок к новому менеджеру просто не появится.

Автоматизация переноса через n8n

Если компании планируют не разовый перенос, а периодическую синхронизацию оргструктуры между двумя порталами (например, головной офис и дочерняя структура остаются на разных аккаунтах, но обмен сотрудниками идёт постоянно), скрипт на Python избыточен. Тут удобнее собрать сценарий в n8n: узел HTTP Request дергает REST API исходного портала по расписанию, узел Function сверяет список с таблицей маппинга ID, а следующий узел пишет изменения через вебхук на втором портале. Такую разработку я оформляю как отдельный проект, поскольку логика синхронизации и обработка конфликтов ID требуют полноценной разработки скрипта переноса сотрудников под структуру конкретной компании, а не разовой настройки по шаблону.

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

1. Выгружаю дерево отделов и список сотрудников с исходного портала через department.get и user.get, сохраняю в JSON как эталон.
2. Строю таблицу соответствия старых и новых ID отделов и пользователей - без неё дальнейшие шаги переделывать придётся с нуля.
3. Создаю отделы на новом портале строго сверху вниз по иерархии через department.add с указанием PARENT.
4. Добавляю сотрудников через user.add с привязкой к уже созданным отделам и рассылаю приглашения на подтверждение доступа - в среднем часть команды подтверждает вход не сразу, а в течение суток-двух.
5. Настраиваю роли и права доступа под каждый отдел, сверяя со старым порталом.
6. Прохожу по CRM и переназначаю ответственных в сделках, лидах и делах через batch-обновление по таблице соответствия ID.
7. Тестирую перенос на двух-трёх сотрудниках из разных отделов, проверяю доступ к CRM и задачам, и только после этого переношу остальных.

Для команды из 20-30 человек с пятью-шестью отделами такой цикл с тестированием обычно укладывается в 3-5 дней. Если в компании больше сотни сотрудников и нужно тащить историю CRM за пару лет, закладываю полторы-две недели с учётом ограничений REST API по скорости запросов.

Ошибки, из-за которых перенос проваливается

• Забыли таблицу соответствия ID и после переноса не смогли переназначить ответственных в сделках - CRM превращается в набор «ничьих» лидов.
• Создали отделы не по иерархии, а произвольно - department.add отваливается на дочерних подразделениях, потому что родителя ещё не существует.
• Перенесли пользователей, но не скопировали роли и права доступа - сотрудник видит портал, но не видит свои сделки или разделы CRM.
• Не предупредили сотрудников заранее, и приглашения на новый портал уходят в спам или просто игнорируются неделями.
• Запустили перенос сразу на всей компании без теста на небольшой группе - и любую ошибку в маппинге приходится чинить руками по каждому человеку.

Сколько стоит перенос сотрудников между порталами Битрикс24

Цена зависит от способа переноса и от того, нужно ли тянуть историю CRM или речь только о структуре и учётных записях.

Если после переноса нужно ещё какое-то время сопровождать оба портала параллельно и донастраивать права по ходу работы, беру это отдельно как техподдержку от 15 000 ₽ в месяц.

Частые вопросы

Можно ли перенести сотрудников между порталами Битрикс24 без программирования

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

Что будет со сделками и лидами старых сотрудников после переноса

Если не обновить поле ответственного через crm.deal.update и crm.lead.update по таблице соответствия ID, сделки останутся привязаны к пользователю, которого на новом портале не существует. Внешне это выглядит как «пропавшие» клиенты у менеджера, хотя данные никуда не делись, просто ссылаются на старый ID.

Сколько времени занимает перенос структуры компании на новый портал

Для 20-30 сотрудников с тестированием на небольшой группе - обычно 3-5 рабочих дней. Для компаний свыше сотни человек с переносом истории CRM закладываю полторы-две недели, в основном из-за ограничения REST API на количество запросов в секунду.

Нужно ли предупреждать сотрудников заранее

Да, обязательно. Приглашение на новый портал приходит на email, и часть людей не подтверждает его сразу, если не знает, чего ждать. Я обычно прошу заказчика разослать короткое уведомление за день до переноса, это сокращает время подтверждения доступа с двух дней до нескольких часов.