Выгрузка данных из Битрикс24 перед переездом на другую CRM - отдельный проект, который я всегда закладываю минимум за 2-3 недели до отключения старого аккаунта. На практике это не «нажал кнопку экспорт и получил файл», а работа с REST API, лимитами запросов и кастомными полями, которые в интерфейсе выглядят понятно, а в выгрузке превращаются в наборы кодов вида UF_CRM_1589452130.
В этой статье прохожусь по всем сущностям, которые обычно нужно вытащить: сделки, контакты, компании, файлы, звонки, переписку, и показываю, где именно теряются данные, если делать выгрузку наспех.
Что нужно выгрузить из Битрикс24 перед миграцией
Перед тем как писать скрипты, я составляю список сущностей, которые реально используются в компании, потому что тащить все подряд бессмысленно и долго. Обычно в список попадают:
- Лиды, сделки, контакты, компании - основные CRM-сущности со всеми полями, включая пользовательские
- Воронки и стадии (crm.dealcategory.list, статусы по каждой воронке отдельно)
- Задачи и дела (звонки, встречи, письма из таймлайна)
- Файлы на Диске, прикреплённые к сделкам и лидам
- История звонков через модуль Телефония, включая записи разговоров
- Реквизиты компаний и контактов, если есть интеграция со счетами
- Права доступа и привязка сделок к менеджерам
Если в компании настроена интеграция со СДЭК для расчёта доставки, отдельно фиксирую, какие поля сделки отвечают за адрес и статус отправления - при переезде на новую CRM эту логику придётся собирать заново, и без выгрузки исходных значений её нечем будет проверить.
Экспорт данных через REST API Битрикс24
Для полной выгрузки я всегда иду через REST API, а не через ручной экспорт в интерфейсе. Создаю входящий вебхук в разделе «Разработчикам» с правами crm, telephony, disk, user - этого достаточно для 90% задач миграции.
Главное ограничение, с которым сталкиваешься сразу: Битрикс24 держит лимит в 2 запроса в секунду на пользователя, а списочные методы вроде crm.deal.list или crm.contact.list возвращают по 50 записей за раз. Для аккаунта с 5000 сделками и 12000 контактами это уже сотни запросов, и без пагинации через параметр start скрипт просто не соберёт всё до конца.
Я обычно использую метод batch, который позволяет объединить до 50 команд в один вызов и заметно сократить время выгрузки. При этом фильтрую записи не по номеру страницы, а по условию ID>последний_полученный_ID - если во время выгрузки кто-то из менеджеров создаёт новые сделки, постраничная выборка может пропустить часть данных или задвоить их.
Ручной экспорт CRM-сущностей через интерфейс
Экспорт в CSV через списки CRM подходит для быстрой сверки, но не для полноценного переноса. У него есть конкретные ограничения, которые я проверяю в каждом проекте:
| Способ выгрузки | Что получаем | Ограничение |
|---|---|---|
| Экспорт из списка CRM | CSV/Excel с видимыми в списке колонками | Кастомные поля идут кодами, а не названиями |
| REST API (crm.*.list) | Полный набор полей, включая UF_CRM_* | Лимит 2 запроса/сек, нужна пагинация |
| Выгрузка через Диск | Файлы, привязанные к сделкам | Ссылки на файлы временные, нужно скачивать сразу |
| Телефония (список звонков) | История звонков, записи разговоров | Записи хранятся ограниченный срок по тарифу |
Кроме того, ручной экспорт не тянет связи между сущностями: если сделка привязана к трём контактам и двум компаниям, в CSV это часто схлопывается до одной строки. Для новой CRM такие связи придётся восстанавливать вручную, что при паре тысяч записей превращается в отдельную задачу на несколько дней.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Перенос файлов и истории коммуникаций
Файлы, прикреплённые к сделкам, лежат на Диске Битрикс24 и достаются через поле FILE_ID в связке с методами disk.attachedObject.get и disk.file.get. Ссылка на скачивание временная, поэтому в скрипте выгрузки я сразу качаю файл на сервер, а не сохраняю ссылку на потом - через сутки она уже недействительна.
С историей звонков сложнее: список звонков отдаёт метод voximplant.statistic.get, а сами аудиозаписи нужно скачивать по отдельной ссылке из каждой записи статистики. На одном из проектов у клиента накопилось около 40 тысяч звонков за два года, и скачивание записей заняло почти сутки из-за ограничения на параллельные запросы к API.
Переписку из встроенной почты и таймлайна сделки вытаскиваю через crm.timeline.comment.list - там же лежат комментарии менеджеров, которые часто важнее самих полей сделки для понимания истории клиента.
Важный момент по закону: контакты клиентов при выгрузке храню на сервере в России, а не в Google Таблицах или зарубежных сервисах - это требование 152-ФЗ о локализации персональных данных, и я соблюдаю его на всех проектах с миграцией CRM.
Автоматизация выгрузки с помощью n8n и Python
Для разовой миграции пишу Python-скрипт на requests: он проходит по всем сущностям пачками, обрабатывает ошибку QUERY_LIMIT_EXCEEDED повторной попыткой с задержкой и складывает результат в локальную базу PostgreSQL. На аккаунт среднего размера (5-7 тысяч сделок, 10-15 тысяч контактов) разработка такого скрипта занимает 1-2 дня, а сама выгрузка с учётом лимитов API - от 30 до 50 минут.
Если нужно не разово выгрузить данные, а держать синхронизацию между Битрикс24 и новой CRM во время переходного периода (когда часть менеджеров ещё работает в старой системе), я собираю пайплайн в n8n: нода HTTP Request дергает вебхук по расписанию, дальше идёт нормализация полей и запись в целевую систему через её API. Это удобнее скрипта, когда процесс должен работать не один раз, а неделями, пока идёт постепенный переход команды.
Подробнее про то, как я собираю такие связки между CRM и внешними сервисами, можно посмотреть в разделе автоматизации на n8n - туда же попадают кейсы с миграцией данных между системами.
Типичные проблемы при выгрузке данных из Битрикс24
За несколько проектов миграции с Битрикс24 накопился список вещей, которые обычно всплывают не сразу:
Кастомные поля без расшифровки
Поля вида UF_CRM_1589452130 ничего не говорят о своём содержимом. Перед выгрузкой обязательно вызываю crm.deal.userfield.list и crm.contact.userfield.list, чтобы получить соответствие кодов человекочитаемым названиям и типам (список, дата, привязка к другой сущности).
Разные воронки и статусы
Если в аккаунте несколько воронок продаж, у каждой свой набор STATUS_ID, и одна и та же стадия «Переговоры» в разных воронках может иметь разные коды. Без явного маппинга по каждой воронке часть сделок при переносе попадает не на ту стадию.
Права доступа и видимость сделок
Вебхук от обычного пользователя видит только те сделки, к которым у него есть доступ. Для полной выгрузки нужен вебхук от администратора или пользователя с правом «Все сделки компании», иначе часть записей просто не попадёт в выгрузку без явной ошибки.
Архивные и удалённые записи
Списочные методы по умолчанию не показывают сделки в корзине. Если бизнесу важна история отменённых сделок, фильтр по удалённым записям нужно настраивать отдельно, и не для всех сущностей это вообще возможно через API.
Разобраться перед стартом
Консультация
от 3 000 ₽
Подробнее →Частые вопросы
Сколько времени занимает выгрузка данных из Битрикс24?
Зависит от объёма: для аккаунта на 5-10 тысяч сделок и контактов сама выгрузка через API с учётом лимита в 2 запроса в секунду занимает от 30 минут до пары часов. Разработка и тестирование скрипта под конкретную структуру данных клиента добавляет ещё 1-3 дня.
Можно ли выгрузить историю звонков и переписку вместе с записями разговоров?
Да, через метод voximplant.statistic.get для списка звонков и отдельное скачивание аудиозаписей по ссылкам из каждой записи. Переписку и комментарии менеджеров вытаскиваю через crm.timeline.comment.list. Стоит проверить тарифный план: срок хранения записей звонков в Битрикс24 ограничен, и часть старых разговоров может быть уже недоступна.
Что делать с кастомными полями при переносе в другую CRM?
Сначала получаю список всех пользовательских полей через crm.deal.userfield.list и crm.contact.userfield.list, чтобы понять их реальное название и тип данных. Дальше строю таблицу соответствия между полями Битрикс24 и полями новой CRM - без этого шага данные переносятся, но теряют смысл, потому что коды полей ничего не говорят новой системе.
Нужно ли уведомлять клиентов о переносе их данных в другую CRM?
Если контакты клиентов и их персональные данные (телефон, email, адрес) переносятся между информационными системами одного оператора данных, отдельного согласия обычно не требуется, но стоит убедиться, что новая CRM хранит данные на серверах в России - это требование 152-ФЗ о локализации персональных данных, и я всегда проверяю это перед стартом миграции.