Смена подрядчика по CRM почти никогда не бывает плановой. Обычно решение созревает после того, как задачи месяцами висят без ответа, доработки ломают то, что работало, а на вопрос «что именно вы нам настроили» приходит ответ в духе «всё в системе». И в этот момент собственник впервые задумывается: а данные-то чьи? Кто может выгрузить историю сделок, где лежит резервная копия портала, что произойдёт с интеграциями, если подрядчик просто перестанет отвечать. Коробочный Битрикс24 в этом смысле проще облака — сервер ваш, база ваша, файлы ваши. Но «ваши» они только тогда, когда у вас есть доступы и понимание, как из этого хозяйства достать данные в переносимом виде.
Почему смена подрядчика — это в первую очередь вопрос данных, а не эмоций
Технически коробочный Битрикс24 живёт на вашем сервере: файлы портала лежат в файловой системе, все записи — в базе данных, документы и вложения — на диске. Формально это означает, что подрядчик ничего не может «унести с собой». Практически же бывает иначе: доступ к серверу оформлен на почту сотрудника агентства, панель хостинга привязана к их аккаунту, лицензионный ключ куплен через их партнёрский кабинет, а бизнес-процессы собраны так, что понять логику без автора невозможно.
Поэтому передача проекта — это не одна кнопка «экспорт данных Битрикс24», а последовательность из четырёх слоёв. Первый — инфраструктура: сервер, хостинг, домен, SSL, доступы. Второй — сама система: полная резервная копия портала, из которой его можно поднять заново. Третий — прикладные данные: CRM, задачи, документы, база знаний. Четвёртый — знание: описание того, что и зачем настроено. Если забрать только третий слой, вы получите таблицы, но не работающую систему. Если забрать только второй — получите систему, которую некому объяснить.
Ниже эти четыре слоя разобраны по отдельности, в том порядке, в котором действовать разумно при реальной смене подрядчика.
Инвентаризация: что вообще считается «вашими данными»
Прежде чем что-то выгружать, полезно составить список того, что вообще должно оказаться у вас на руках. В коробочном портале это обычно:
- Полная резервная копия портала — архив файлов и дамп базы данных.
- Выгрузки CRM — лиды, сделки, контакты, компании, счета, предложения, смарт-процессы, товары.
- Выгрузки задач и проектов — список задач с полями.
- Шаблоны бизнес-процессов — в формате BPT, отдельными файлами.
- Настройки CRM — пользовательские поля, стадии, воронки, роботы.
- Файлы Диска — общие папки, документы, шаблоны договоров.
- Реестр интеграций — какие вебхуки и приложения созданы, куда они ходят и что делают.
- Доступы — к серверу, панели хостинга, домену, кабинету, где оформлена лицензия.
Отдельно стоит зафиксировать список пользователей с ролью администратора портала и администратора сервера. Классическая ситуация при смене подрядчика в CRM: у клиента формально есть учётка администратора, но реальный административный доступ к серверу — только у уходящей команды, и без их участия ничего не выгрузить. Проверить это лучше заранее, а не в день расставания.
Полная резервная копия портала — базовый актив, который нужно получить
Коробочный Битрикс24 построен на платформе 1С-Битрикс, и у него есть штатный механизм резервного копирования. Он находится в административной части в разделе Настройки → Инструменты → Резервное копирование. Механизм умеет создавать архивную копию файлов портала в формате *.tar.gz и дамп базы данных.
Настройки, на которые стоит обратить внимание при создании копии для передачи:
- Исключение папки с ядром продукта. Ядро можно не архивировать — оно ставится заново из дистрибутива. Но если вы забираете копию «на всякий случай» и не уверены в версии, безопаснее взять архив с ядром.
- Исключение таблиц статистики и поискового индекса. Это заметно уменьшает размер дампа и почти никогда не влияет на бизнес-данные.
- Ограничение по размеру файлов. Можно исключить из архива файлы больше заданного объёма в килобайтах. Удобно, чтобы бэкап не раздувался, но опасно при передаче: крупные вложения и документы Диска могут просто не попасть в копию. Для передаточного бэкапа этот лимит лучше не занижать.
- Исключение по маскам. Из архива можно убрать файлы по шаблонам вида
*.zipили отдельные каталоги. Проверьте, что подрядчик не исключил что-то принципиальное. - Шифрование архива и проверка целостности. Если копия шифруется, пароль обязательно должен быть передан вам вместе с архивом, иначе файл бесполезен.
Восстанавливается такая копия скриптом restore.php: его скачивают со страницы со списком резервных копий, кладут в корень сайта и открывают в браузере по адресу вида ваш_сайт/restore.php. Скрипт распаковывает архив, при необходимости запрашивает пароль от зашифрованной копии, затем настройки подключения к базе данных. После успешного восстановления служебные скрипты и локальную копию удаляют с сервера — оставлять их в открытом доступе нельзя.
Практический совет: не принимайте бэкап «на слово». Разверните его на тестовом сервере или в отдельной виртуальной машине и убедитесь, что портал поднимается, сделки на месте, документы открываются. Копия, которую никто ни разу не разворачивал, — это не резервная копия, а файл неизвестного содержания.
Экспорт данных CRM: как это работает в интерфейсе
Резервная копия решает задачу «поднять портал целиком». Но при смене подрядчика часто нужен второй сценарий: получить данные в читаемом, переносимом виде — чтобы проанализировать их в Excel, отдать новой команде на аудит или перенести на другой портал.
Экспорт в CRM работает так: откройте нужный раздел (лиды, сделки, контакты, компании, счета, предложения или смарт-процессы) и переключитесь в режим просмотра Список — экспорт доступен только из него. Затем в меню Настройки (⚙️) выберите Экспорт в CSV или Экспорт в Excel, нажмите Выполнить и дождитесь готовности файла.
Выбор формата не косметический:
- CSV — если данные планируется импортировать в другой Битрикс24.
- Excel — если файл нужен для анализа и отчётности.
Полезные опции, которые стоит включать при передаче дел:
- Экспортировать все поля — в файл попадут все поля карточки, даже те, что не выведены в текущем списке. При передаче подрядчику это почти всегда правильный выбор: вы не знаете заранее, какое кастомное поле окажется важным.
- Экспортировать поля контактов и компаний — подтягивает данные связанных элементов.
- Экспортировать реквизиты — для контактов и компаний это отдельная опция, без неё юридические реквизиты в файл не попадут.
- Экспортировать с детализацией по товарным позициям — при её включении одна сделка может занять несколько строк файла, по строке на позицию. Это важно учитывать при последующей обработке.
Два нюанса, о которых спотыкаются чаще всего. Первый: поле ID выгружается всегда, даже если вы не отметили его в настройках списка — и это хорошо, потому что именно по ID потом сопоставляют данные. Второй: составные поля вроде телефона или связи с лидом выгружаются в отдельные колонки, поэтому структура файла может отличаться от того, как поля выглядят в карточке.
Право на экспорт настраивается отдельно для каждого типа элементов CRM. То есть сотрудник может видеть сделки, но не иметь возможности их выгрузить. Перед передачей проекта проверьте, что у вашего собственного администратора это право включено везде, где нужно, — иначе выгрузку придётся просить у уходящей команды.
Импорт в новый портал: чего ждать и где будут потери
Обратная операция выполняется там же: CRM → нужный раздел → Настройки (⚙️) → Импорт. Битрикс24 предлагает скачать шаблон CSV-файла, чтобы структура колонок совпала, затем загрузить заполненный файл и пройти шаг сопоставления полей — в левой колонке поля CRM, в правой колонки вашего файла, соответствие можно поправить вручную.
Что важно знать заранее:
- Импорт доступен администратору или сотруднику с соответствующими правами.
- Формат — CSV. Excel-выгрузки перед импортом придётся конвертировать.
- Есть блок контроля дубликатов с режимом замены — это спасает, когда часть данных уже загружена.
- Импортировать можно только новые сделки: обновить данные в уже существующих через импорт нельзя. Если нужно именно обновление, задача решается через API, а не через файл.
Один нюанс по переносу настроек CRM между порталами легко упустить: при переносе настроек на новом портале лиды и сделки удаляются. Поэтому порядок действий имеет значение — сначала настройки и структура полей, потом данные, а не наоборот. Если сделать наоборот, вы потеряете уже залитые записи.
Задачи, бизнес-процессы и настройки: отдельные ветки выгрузки
CRM — не единственное, что накапливает ценность. Задачи выгружаются из раздела Задачи в режиме Список: Настройки (⚙️) → Экспорт списка → в Excel. Формат — xls, при экспорте можно выбрать «только поля из списка» или «все поля». Право на экспорт задач по умолчанию есть у сотрудников, но администратор может его ограничить.
Важное ограничение: комментарии к задачам при переносе между порталами не переносятся. Для многих компаний это болезненно — вся история согласований и решений живёт именно в комментариях. Если эта переписка критична, её нужно либо сохранить отдельно (полная резервная копия портала её содержит), либо сознательно принять как потерю. Из выгрузки в Excel вы получите поля карточки, но не обсуждение.
Шаблоны бизнес-процессов выгружаются в формате BPT — это отдельные файлы шаблонов, которые затем загружаются на другой портал. Именно бизнес-процессы обычно оказываются самой «авторской» частью работы подрядчика: сложные ветвления, условия, автоматические уведомления. Забирайте эти файлы обязательно, даже если не планируете переносить портал. Они же служат документацией того, как была устроена автоматизация.
Настройки CRM — пользовательские поля, стадии, роботы, привязанные бизнес-процессы — тоже выгружаются отдельным блоком. Не поленитесь дополнительно снять скриншоты воронок и стадий: это тридцать минут работы, которые потом экономят дни на восстановление логики.
Интеграции, вебхуки и доступы: самая недооценённая часть
Данные вы заберёте. А вот интеграции чаще всего оказываются чёрным ящиком: сайт отправляет заявки в CRM, телефония пишет звонки в карточки, мессенджеры подтягиваются в открытые линии, 1С обменивается номенклатурой. Каждое такое соединение живёт на вебхуке или приложении, созданном подрядчиком, и завязано на конкретный ключ.
Перед сменой команды соберите реестр интеграций в простой таблице: что именно интегрировано, в какую сторону идёт обмен, где физически лежит принимающий скрипт, кто владелец аккаунта на стороне внешнего сервиса. Отметьте также, какие вебхуки были созданы под учётной записью сотрудника уходящего подрядчика — при отключении этого пользователя такие интеграции перестанут работать, и разбираться придётся уже в аварийном режиме.
И обязательно смените ключи и пароли после завершения передачи: доступ к серверу, к панели хостинга, к базе данных, к внешним сервисам. Это не про недоверие, а про гигиену — у уходящей команды не должно оставаться технической возможности что-то изменить в вашей системе, хотя бы для того, чтобы при любом сбое не возникало вопросов, кто это сделал.
Если внутри компании нет человека, готового вести эту инвентаризацию, разумно подключить нового партнёра ещё до расставания со старым. Мы в таких проектах обычно начинаем именно с аудита: снимаем полную карту портала, проверяем бэкапы и только потом принимаем систему. Посмотреть, как устроены наши услуги по Битрикс24, можно на странице направления — сопровождение коробочных порталов и приём проектов от других подрядчиков входят в стандартный набор задач.
Как проверить, что вы действительно получили данные
Передача считается состоявшейся не тогда, когда вам прислали архив, а когда вы убедились в его пригодности. Минимальный чек-лист приёмки:
- Бэкап развёрнут. Копия поднята на отдельном сервере, портал открывается, вход администратора работает.
- Количество записей сходится. Сравните число сделок, контактов и компаний в развёрнутой копии и в боевом портале. Расхождение — повод задать вопрос до, а не после отключения доступов.
- Файлы на месте. Откройте несколько сделок с вложениями и документы на Диске. Если вложения не открываются, значит, в архив не попал каталог загрузок.
- Выгрузки CRM читаются. Откройте CSV и Excel-файлы, проверьте кодировку и наличие кастомных полей.
- Шаблоны бизнес-процессов получены. Файлы BPT есть, их количество совпадает со списком процессов на портале.
- Доступы переоформлены. Сервер, хостинг, домен, кабинет с лицензией — на ваших учётных записях и вашей корпоративной почте.
- Реестр интеграций заполнен. Каждое соединение описано, ответственный назначен.
Пока не закрыты все семь пунктов, не спешите прекращать оплату старому подрядчику. Технический выход из проекта стоит дешевле, чем аварийное восстановление после него.
Пример: как выглядит передача коробки на практике
Показательный сценарий — торговая компания из Алматы, около шестидесяти сотрудников, коробочный портал третий год, подрядчик перестал отвечать в разумные сроки. Компания решает уйти, но боится «сломать всё».
Разумный порядок действий выглядит примерно так. Первая неделя: инвентаризация. Составляется список доступов, выясняется, что сервер арендован на юрлицо клиента (хорошая новость), а панель хостинга привязана к почте сотрудника подрядчика (плохая). Параллельно снимается полная резервная копия и разворачивается на тестовом сервере — становится видно, что бэкап делался с ограничением по размеру файлов, и часть вложений в него не попала. Настройки бэкапа правятся, копия снимается заново.
Вторая неделя: выгрузки. Из CRM забираются сделки, контакты, компании и смарт-процессы в CSV с включённой опцией всех полей и реквизитов, задачи — в xls, шаблоны бизнес-процессов — в BPT. Собирается реестр интеграций, и там обнаруживается вебхук, отправляющий заявки с сайта, созданный под учётной записью сотрудника подрядчика. Его пересоздают под сервисной учётной записью клиента и перепроверяют приём заявок.
Третья неделя: приёмка и смена ключей. Панель хостинга переоформляется на корпоративную почту клиента, пароли меняются, доступы старой команды отзываются. Только после этого договор закрывается.
Ничего героического в этом сценарии нет — вся сложность в дисциплине и последовательности. Проблемы возникают там, где пытаются сэкономить неделю и отключают подрядчика раньше, чем проверили бэкап.
Что зафиксировать заранее, чтобы следующая смена прошла спокойно
Самый дешёвый способ пережить смену подрядчика — подготовиться к ней в тот момент, когда отношения ещё хорошие. Несколько пунктов, которые имеет смысл прописать в договоре или регламенте с любым партнёром по Битрикс24:
- Все доступы оформляются на юридическое лицо заказчика и корпоративные почты, а не на личные аккаунты исполнителей.
- Резервные копии создаются по расписанию и хранятся в месте, доступном заказчику, а не только подрядчику.
- Каждая интеграция описывается в реестре: назначение, направление обмена, владелец, точка отказа.
- Каждое изменение бизнес-процессов сопровождается коротким описанием логики — двух абзацев достаточно.
- При расторжении подрядчик передаёт полный комплект: бэкап, выгрузки, шаблоны BPT, реестр интеграций и доступы, в согласованный срок.
Эти пять строк в договоре превращают потенциально болезненный разрыв в обычную процедуру на две-три недели. И одновременно они хорошо показывают качество самого подрядчика: команда, которая спокойно соглашается на такие условия, обычно и работает прозрачно, потому что ей нечего прятать в чужой системе.
Частые вопросы
Можно ли выгрузить из коробочного Битрикс24 сразу всё одним файлом?
Единой кнопки «выгрузить весь портал в один файл в читаемом виде» нет. Полный слепок системы — это резервная копия (архив файлов плюс дамп базы данных), из неё портал восстанавливается целиком. А человекочитаемые выгрузки делаются по разделам: CRM отдельно, задачи отдельно, шаблоны бизнес-процессов отдельно.
Переносятся ли комментарии к задачам при переходе на другой портал?
Нет, комментарии к задачам между порталами не переносятся. Они остаются в исходной системе и в её резервной копии. Если история обсуждений важна, сохраняйте бэкап исходного портала и не удаляйте его сразу после миграции.
Почему при экспорте сделок одна сделка занимает несколько строк?
Так работает опция экспорта с детализацией по товарным позициям: на каждую позицию создаётся отдельная строка. Если вам нужен файл «одна сделка — одна строка», эту опцию нужно отключить.
Можно ли через импорт обновить уже существующие сделки?
Нет. Импорт создаёт новые элементы; обновить данные в уже существующих сделках через загрузку файла нельзя. Для массового обновления используют REST API — это отдельная задача, которую обычно решает разработчик.
Что делать, если у подрядчика остались единственные доступы к серверу?
Действовать через владельца инфраструктуры: если сервер и домен оформлены на вашу компанию, доступ восстанавливается через поддержку хостинг-провайдера и регистратора по документам юрлица. Если оформлено на подрядчика, восстановление возможно только с его участием — поэтому этот пункт и стоит проверять в первую очередь, до начала любых разговоров о расставании.
