Как сменить интегратора Битрикс24 и ничего не потерять
Компания недовольна сроками или качеством работ и хочет немедленно отключить старого подрядчика. Это понятная реакция, но у портала могут быть внешние приложения, вебхуки, почта, телефония, автоматизации и учётные записи, о которых знает только прежняя команда.
Смена интегратора — не перенос Битрикс24 в другое место. Портал остаётся у компании, а передаются знания, полномочия, документация и ответственность за работающие зависимости. Если отключить доступ до инвентаризации, можно потерять не данные как таковые, а управление системой и способность быстро восстановить её логику.
Команда компании «Первый Приятный Интегратор» | 1PI.PRO предлагает относиться к смене подрядчика как к отдельному проекту передачи.
Сначала назначьте владельца перехода
Со стороны компании нужен один человек, который имеет полномочия принимать решения и подтверждать результат. Он не обязан знать каждую настройку, но отвечает за список систем, приоритеты и доступ участников.
Владелец перехода фиксирует:
причину смены и желаемый результат;
дату начала и контрольные точки;
критичные процессы, которые нельзя останавливать;
текущего и нового ответственных;
порядок общения с прежним подрядчиком;
перечень открытых работ и спорных вопросов;
правило изменения настроек во время передачи.
Без единого владельца старый интегратор продолжает менять портал, новый одновременно проводит аудит, а сотрудники сообщают разные требования обеим сторонам.
Не отключайте доступ до инвентаризации
Обычный переход лучше начинать с чтения и фиксации. Исключение — подтверждённый риск безопасности: утечка учётной записи, вредоносное действие или несанкционированный доступ. Тогда сначала ограничивают риск и только потом восстанавливают картину.
Для плановой смены зафиксируйте:
| Область | Что нужно получить | |---|---| | владельцы портала | кто контролирует домен, тариф, оплату и администраторов | | пользователи и роли | действующие сотрудники, администраторы, внешние участники | | CRM | воронки, стадии, поля, обязательность, источники и права | | автоматизации | роботы, триггеры, бизнес-процессы, расписания и зависимости | | интеграции | 1С, сайт, телефония, почта, мессенджеры и обмены | | приложения | владелец установки, подписка, назначение и критичность | | вебхуки | кто создал, где используется, с какими правами и секретами | | документы | шаблоны, папки, права и жизненный цикл | | отчёты | источники данных и правила расчёта | | открытые работы | задача, состояние, исполнитель, срок и критерий готовности |
Критичная система должна принадлежать компании или быть управляемо передана ей. Проверьте:
корпоративную почту и домен;
номер телефонии и договор с оператором;
учётную запись 1С и сервер интеграции;
хостинг сайта;
аккаунты приложений и подписок;
репозитории кода;
облачные функции и базы данных;
адреса технических уведомлений;
ключи и вебхуки.
Не копируйте секреты в таблицу передачи или письмо. Фиксируйте владельца и место безопасного хранения, а ключи при необходимости перевыпускайте. Новому интегратору выдавайте отдельный доступ по инструкции как пригласить интегратора в Битрикс24.
Составьте реестр автоматизаций
Для каждого значимого сценария достаточно короткой карточки:
название и бизнес-задача;
точка запуска;
используемые поля;
изменяемые стадии и ответственные;
внешние вызовы;
владелец процесса;
критичный результат;
способ тестирования;
известные ограничения.
Не требуйте идеальную документацию задним числом. Цель первого реестра — не описать каждый блок, а понять, какие процессы затронет смена доступа, приложения или интеграции.
Разделите данные и знания
Сделки, контакты и задачи находятся в портале, но этого недостаточно для сопровождения. Новый подрядчик должен понимать:
почему используется конкретная воронка;
какие поля обязательны для отчётности;
откуда приходят данные;
какие исключения считаются нормальными;
кто утверждает изменение процесса;
как проверяется результат автоматизации;
что временно сделано вручную.
Экспорт отдельных таблиц полезен для контрольной сверки, но не является полной резервной копией портала. Он может не включать логику роботов, права, внешние зависимости и историю всех связанных объектов.
Зафиксируйте открытые работы
Для каждой незавершённой задачи определите одно из решений:
завершает прежний подрядчик;
принимает и завершает новый;
задача останавливается;
результат уже готов и проходит приёмку;
требуется совместная передача.
Статус «почти готово» бесполезен. Нужны текущий результат, оставшаяся работа, используемые данные, среда проверки и критерий приёмки.
Проведите переход в два контура
Контур 1. Наблюдение
Новый интегратор получает ограниченный доступ, изучает портал, задаёт вопросы и составляет карту зависимостей. Изменения выполняются только по согласованному списку.
Контур 2. Управление
После приёмки карты новый подрядчик получает необходимые полномочия, а старые доступы последовательно закрываются. Для каждого критичного процесса выполняется контрольный сценарий.
Такой порядок уменьшает риск одновременных изменений и позволяет связать проблему с конкретным действием.
Какие сценарии принять до отключения старого доступа
Минимальный набор зависит от портала, но обычно проверяются:
новая заявка с сайта;
входящий звонок;
письмо клиента;
создание и движение сделки;
назначение ответственного;
ключевые роботы и бизнес-процессы;
обмен с 1С или другой системой;
формирование документа;
права обычного менеджера;
отчёт руководителя;
уведомление об ошибке интеграции.
У каждого теста должны быть входные данные, ожидаемый результат и ответственный за решение. Если тест проходит только под администратором, работа не принята.
Для оценки нового подрядчика используйте критерии выбора интегратора Битрикс24, но применяйте их к реальной передаче: как команда фиксирует неизвестность, проверяет зависимости и объясняет риски.
Что можно подготовить самостоятельно
Компания может безопасно:
назначить владельца перехода;
собрать договоры, счета и контакты подрядчиков;
перечислить критичные процессы;
составить список администраторов и внешних пользователей;
выгрузить перечень приложений;
собрать последние технические задания и инструкции;
зафиксировать открытые задачи;
выбрать контрольные бизнес-сценарии;
запретить несогласованные изменения на время передачи.
передавать новому подрядчику пароль администратора;
удалять старых пользователей до инвентаризации;
удалять приложения и вебхуки по неизвестному названию;
считать экспорт CRM полной копией портала;
менять интеграции одновременно с аудитом;
принимать работу без контрольных сценариев;
оставлять внешние сервисы на личной почте сотрудника или подрядчика;
смешивать спор по договору с технической безопасностью портала.
Частые вопросы
Нужно ли предупреждать старого интегратора?
При плановом переходе — да: согласуйте формат передачи и открытые работы. При инциденте безопасности сначала ограничьте риск.
Когда отключать старый доступ?
После инвентаризации, выдачи отдельного доступа новой команде и проверки критичных сценариев, если нет срочной угрозы.
Достаточно ли выгрузить сделки и контакты?
Нет. Данные не заменяют настройки, права, автоматизации, приложения, интеграции и знания о правилах работы.
Что делать с вебхуками?
Определить владельца, назначение, права и внешнего потребителя. После передачи при необходимости перевыпустить секреты и повторить тест.
Как понять, что передача завершена?
Есть владелец, реестр зависимостей, документация по критичным процессам, принятые тесты, закрытые старые доступы и понятный канал поддержки.
Результат для бизнеса
Успешная смена интегратора возвращает компании контроль над порталом. Владелец знает, кто имеет доступ, где находятся зависимости, какие процессы критичны и как проверить их после изменения.