Перенос данных между CRM: связи, проверка полноты и переключение

Перенос данных между CRM нельзя принимать только по числу загруженных строк. До переключения нужно подтвердить состав записей, связи между ними, историю, вложения, владельцев и права. Для этого команда составляет реестр данных, фиксирует mapping полей и ID, выполняет пробный перенос, загружает изменения после контрольного момента и проверяет возможность отката.

Ниже — рабочий план для руководителя продаж или администратора CRM. Он не предполагает, что все системы поддерживают одинаковый экспорт, импорт или API: доступные способы, тариф, права и ограничения проверяют отдельно для исходной и целевой CRM.

Чем миграция CRM отличается от обычного импорта

Обычный импорт отвечает на узкий вопрос: появились ли строки в целевой системе. Миграция должна сохранить рабочий контекст каждой записи. Компания связана с контактами, контакты — со сделками, а у сделок могут быть события, комментарии, файлы, ответственные сотрудники и ограничения доступа.

Поэтому 1 000 созданных карточек ещё не означают 1 000 корректно перенесённых записей. Сделка может существовать, но вести к другой компании; событие может потерять автора или дату; вложение — не открываться; бывший сотрудник — остаться владельцем активной сделки. Эти ошибки обнаруживаются не общим счётчиком, а отдельной проверкой сущностей и связей.

У миграции есть как минимум четыре результата:

1. Записи перенесены в согласованном составе.
2. Старые идентификаторы сопоставлены с новыми.
3. Связи, история, вложения, владельцы и права проверены отдельно.
4. Зафиксированы переключение и способ возврата к контрольной точке.

Очистка повторов может быть подготовительным этапом, но это отдельная задача. Правила поиска и объединения повторных контактов разобраны в материале о дублях в CRM. Здесь предмет другой: перенос исторических связанных записей и контроль полноты.

Как описать состав данных и ограничения систем

Начните не с кнопки экспорта, а с реестра. В него входят все типы данных, которые нужны сотрудникам после переключения. Для каждого типа укажите количество в источнике, обязательные поля, старый ID, зависимости и доступный путь переноса.

Добавьте к каждой строке статус: «способ подтверждён», «нужна проверка» или «не переносится выбранным способом». Один CSV не следует считать доказательством переноса истории, файлов и прав. Если целевая система не принимает отдельный тип данных, владелец процесса должен выбрать решение: другой поддерживаемый способ, хранение доступного архива или осознанное исключение из объёма.

Отдельно зафиксируйте границу выгрузки: какие воронки, периоды, закрытые записи и удалённые пользователи входят в перенос. Тогда одинаковые числа у источника и назначения будут относиться к одному набору, а не к разным фильтрам.

Как сопоставить поля и идентификаторы

Mapping — это явное правило, по которому поле источника превращается в поле назначения. Для каждого обязательного поля укажите тип сущности, исходное и целевое поле, преобразование и статус проверки.

Даты лучше нормализовать в один согласованный формат, например 2026-10-06T09:30:00Z, и сохранить исходный часовой пояс в правилах преобразования. Для статусов, типов обращений и источников заявки составьте таблицы кодов: old_stage_won → new_stage_success. Не заменяйте неизвестное значение похожим по смыслу без решения владельца процесса.

Старый ID нужен даже тогда, когда целевая CRM создаёт собственный новый ID. После загрузки компании сохраните пару C-101 → NC-501; затем используйте NC-501 при подготовке контактов и сделок. Название остаётся отображаемым полем, а не основным ключом миграции.

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

В каком порядке переносить связанные записи

Порядок определяется зависимостями. Дочернюю запись нельзя надёжно связать, пока неизвестен новый ID родителя.

1. Подготовьте справочники, пользовательские поля и пользователей.
2. Загрузите компании и сохраните пары старых и новых ID.
3. Замените внешние ключи в рабочей копии контактов и загрузите контакты.
4. Подставьте новые ID компаний и контактов в сделки, затем загрузите сделки.
5. Перенесите события и историю, если выбранный способ это поддерживает.
6. Перенесите вложения и проверьте их родительские записи.
7. Назначьте владельцев и права, затем проверьте доступ контрольных ролей.

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

Исходную выгрузку храните неизменной. Нормализацию, замену ID и исправления выполняйте в рабочей копии. Журнал переноса должен содержать номер запуска, тип сущности, старый ID, действие, новый ID или текст ошибки. Такой журнал позволяет отличить ещё не обработанную запись от уже созданной.

Для повтора используйте устойчивый ключ — например, старый ID во внешнем поле или отдельной таблице соответствий. Сначала найдите результат прошлого запуска, затем обновите или повторите только отклонённую операцию поддерживаемым способом. Если конкретный импорт не умеет обновлять сделки, не загружайте успешные строки повторно: сформируйте файл только из записей, для которых подтверждено отсутствие созданной сделки.

Как спланировать пробный перенос и переключение

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

План переключения удобно привязать к моменту T0:

1. До T0 сделайте резервную неизменяемую выгрузку и зафиксируйте её состав.
2. В T0 получите основную выгрузку и включите согласованное окно ограничений на изменения.
3. Перенесите основной набор и ведите таблицу старых и новых ID.
4. Отдельно получите дельту — записи, созданные или изменённые после T0.
5. Перед переключением проверьте контрольную точку: количества, связи, актуальные сделки, историю, вложения и права.
6. Если критерии выполнены, переключите пользователей; если нет — запустите согласованный откат.

Критерий готовности формулируют до начала работ. Например: все строки объяснены итоговыми статусами, отклонённые записи разобраны, контрольные связи корректны, выбранные файлы открываются, владельцы и права совпадают с матрицей, дельта обработана. Нулевое количество ошибок нельзя объявлять заранее.

Не обещайте перенос без простоя, пока не проверены объём дельты, скорость доступного импорта или API, права, тарифные ограничения и допустимое окно изменений. Иногда достаточно запретить редактирование на короткий согласованный период. В другом проекте понадобится поэтапное переключение или повторная синхронизация — это определяется после проверки систем.

Откат тоже репетируют до переключения. Минимальный комплект включает резервную выгрузку, перечень созданных новых ID, точку возврата, ответственного и проверенную процедуру отключения или удаления импортированного набора без затрагивания других записей.

Учебный пример переноса двух похожих компаний

Ниже — синтетический учебный пример. Это не клиентский файл, не результат внедрения Switch On AI и не отчёт о запуске CRM.

Исходный набор содержит две компании с похожими названиями:

• C-101 — «Альфа Север»;
• C-102 — «Альфа-Север».

Контакты P-201 и P-202 принадлежат C-101, а P-203 — компании C-102. Сделки распределены так: D-301 связана с C-101 и P-201; D-302 — с C-101 и P-202; D-303 и D-304 — с C-102 и P-203.

Контрольные суммы воспроизводимы:

• основные записи: 2 компании + 3 контакта + 4 сделки = 9;
• контакты по компаниям: 2 + 1 = 3;
• сделки по компаниям: 2 + 2 = 4;
• сделки по контактам: 1 + 1 + 2 = 4.

Историю, вложения и права считают отдельно: это самостоятельные объекты проверки, и их нельзя прибавлять к девяти основным записям без заранее определённой модели подсчёта.

Ошибка при связи по похожему названию

Предположим, в строке D-303 вместо названия компании «Альфа-Север» указали «Альфа Север». В документированном CSV-импорте Битрикс24 связь создаётся по точному совпадению названия. В этом учебном наборе ошибочное значение совпадает с названием другой компании, поэтому предварительная проверка должна отклонить строку: иначе сделка получит неверную связь. Это ограничение относится к описанному CSV-импорту Битрикс24, а не ко всем способам миграции и не к API.

Безопасный учебный повтор выглядит так:

1. До загрузки сделок сверить название компании в каждой строке с old_company_id и таблицей mapping.
2. Исключить D-303 из первой загрузки; загрузить только три проверенные сделки.
3. По old_company_id=C-102 найти «Альфа-Север» и соответствие C-102 → NC-502.
4. Исправить строку D-303 и убедиться по журналу, что сделка с old_deal_id=D-303 ещё не создана.
5. Загрузить только исправленную строку и повторно сверить количества и связи.

Ожидаемый результат синтетического примера: после первой загрузки есть три сделки, после отдельной загрузки D-303 — четыре. Второго экземпляра D-303 нет; у каждой компании по две сделки. Если ошибочную сделку уже создали, не следует загружать её повторно: документация Битрикс24 указывает, что этот CSV-импорт не обновляет существующие сделки. Способ исправления или удаления такой записи нужно отдельно подтвердить для целевой CRM и включить в процедуру отката.

Как принять результат и обсудить миграцию

Начните приёмку с баланса по каждому типу данных:

успешно + отклонено + пропущено по правилу = строк в исходной выгрузке

Для обработанных записей используйте дополнительный баланс:

создано + обновлено = успешно обработано

Для проверенной выборки связей:

корректные + ошибочные + отсутствующие = проверенные связи

Эти формулы находят необъяснённые строки, но не заменяют содержательную проверку. Откройте выборку актуальных и закрытых сделок, перейдите к связанным компаниям и контактам, сравните владельцев, стадии и даты. Отдельно проверьте последовательность истории, доступность вложений и права нескольких ролей. Зафиксируйте фактический результат и причину каждого расхождения.

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

Switch On AI может помочь инвентаризировать системы, составить обезличенную схему данных и разобрать одну операцию переноса. После проверки данных, API, прав и ограничений можно согласовать прототип подходящей интеграции. Прототип не равен полноценной миграции и не подтверждает совместимость с конкретной CRM до проверки.

Описание форматов работы находится на странице услуг Switch On AI. Для предметного обсуждения передайте через контакты перечень исходной и целевой CRM, типы сущностей, критичные связи, допустимое окно изменений и требования к откату.