Краткий ответ
Перенос данных в CRM начинается с определения сущностей и правил сопоставления, затем проходит через очистку, пробный импорт и сверку связей. До переключения нужно решить, как учитываются изменения в старой системе и что делать при ошибке. Количество импортированных строк не доказывает корректность переноса.
Определите состав переноса
Сначала перечислите сущности: контакты, компании, сделки, задачи, комментарии, документы и история изменений. Для каждой решите, нужна ли она в рабочей системе или достаточно доступного архива. Перенос всего без оценки может усложнить поиск и закрепить старые ошибки.
Укажите владельца данных и основание доступа. Техническая возможность выгрузки не означает, что любому участнику проекта нужен полный набор контактов. Для разработки и пробных проверок используйте минимально необходимый набор и подходящее обезличивание.
Согласуйте модель до импорта
Старая и новая CRM могут по-разному описывать компанию, контакт и сделку. Одно поле в старой системе иногда содержит сразу несколько смыслов. Не начинайте перенос с механического сопоставления одинаковых названий: сначала уточните рабочие процессы и назначение сущностей.
Определите стабильные внешние идентификаторы. По ним можно повторить импорт и сверить связи. Если использовать только отображаемое название, одинаковые компании или переименованные записи легко перепутать.
Таблица сопоставления
| Исходные данные | Целевое поле | Правило | Проверка |
|---|---|---|---|
| Идентификатор записи | Внешний идентификатор | Сохранить однозначную связь | Нет неожиданных повторов |
| Статус сделки | Этап нового процесса | Явная таблица соответствий | Неизвестные статусы вынесены отдельно |
| Ответственный | Пользователь или архивная роль | Согласованное назначение | Нет потерянного владельца |
| Дата | Поле с определённой зоной | Сохранить смысл времени | Порядок событий не изменился |
| Вложение | Файл и связь с записью | Проверить доступность | Документ открывается у нужной роли |
Таблица должна содержать правило для пустого, неизвестного и некорректного значения. Молчаливая замена всех неизвестных статусов на «новый» может исказить работу и отчётность.
Разберите дубли отдельно
Совпадение телефона или почты — признак для проверки, а не универсальное разрешение объединять записи. Общий номер компании может принадлежать нескольким контактам. При объединении нужно решить, что происходит с историей, задачами и ответственными.
Подготовьте отчёт кандидатов и согласуйте правила. Сложные случаи оставьте на ручной разбор. Полезно сохранять связь исходных идентификаторов с итоговой записью, чтобы можно было объяснить результат и исправить ошибочное объединение.
Проведите пробный импорт
Возьмите разнообразную выборку: обычные записи, несколько связанных сделок, закрытые контакты, отсутствующих сотрудников, документы и нестандартные символы. Перенесите её в тестовый контур и проверьте не только экран списка, но и рабочие действия пользователей.
Сверьте количество по типам, распределение статусов, связи и выборочные значения. Одинаковое общее число строк не исключает переставленные поля или потерянные вложения. Ошибки импорта должны иметь журнал с причиной и исходным идентификатором, без лишнего раскрытия содержимого.
Подготовьте переключение
Решите, когда прекращаются изменения в старой системе и как переносятся обновления после первой выгрузки. Возможны короткое окно остановки или перенос изменений по согласованной схеме. Выбор зависит от доступных интерфейсов и допустимого перерыва, а не от предпочтения инструмента импорта.
Перед переключением подготовьте проверяемую резервную копию и критерии возврата. Если после запуска в новой CRM уже созданы записи, простое включение старой системы потеряет часть работы. План возврата должен учитывать новые данные и допустимый объём потери изменений.
Условия завершения
- Сопоставление полей и исключения согласованы владельцем данных.
- Ошибочные записи перечислены и имеют решение.
- Связи, документы и права проверены на выборке.
- Новые изменения учтены при переключении.
- Пользователи знают рабочую систему и порядок обращения за помощью.
- Сохранён отчёт сверки и путь к разрешённому архиву.
Перенос заканчивается подтверждением пригодности данных для процесса. Успешный ответ API или сообщение импортера — лишь технический этап. Настоящий результат виден, когда сотрудник находит правильную запись, понимает её историю и может продолжить работу.
Контрольный лист сопоставления связей
Выберите компанию с несколькими контактами и сделками. Сохраните исходные идентификаторы, ответственных, статусы и перечень вложений. После пробного импорта проверьте не только наличие компании, но и принадлежность каждого связанного объекта. Ошибочная связь может быть незаметной в общем счётчике записей.
Затем добавьте сложный случай: ответственного больше нет в новой системе. Правило переноса должно назначить согласованного владельца или архивное состояние, сохранив исторический смысл. Нельзя молча приписывать все такие записи текущему администратору и затем использовать его имя в отчёте как фактического исполнителя.
Проверьте повтор импорта той же выборки. Он должен обновлять или пропускать записи по принятому контракту, сохраняя понятный отчёт. Если при каждом запуске появляются новые контакты, дальнейшая сверка станет ненадёжной. Отдельно протестируйте изменение исходной записи между запусками.
В протоколе переключения укажите момент последней синхронизации и способ обработки новых действий пользователей. Если возврат потребуется после начала работы в новой CRM, ответственный должен понимать, какие изменения сохранить и как исключить двойной учёт. Этот план готовят до переключения, пока можно спокойно проверить его на тестовых данных.
Пример отчёта сверки после пробного переноса
Возьмём вымышленную выгрузку из 100 контактов и 60 сделок. В этой проверке объединение дублей ещё не выполняется, поэтому каждой перенесённой записи соответствует один исходный идентификатор. Заранее согласовано исключение одного тестового контакта; записи с неразрешёнными ошибками остаются на разборе.
| Объект | В выгрузке | Перенесено | На разборе | Согласованно исключено |
|---|---|---|---|---|
| Контакты | 100 | 96 | 3 | 1 |
| Сделки | 60 | 58 | 2 | 0 |
Баланс контактов: 100 = 96 + 3 + 1. Баланс сделок: 60 = 58 + 2. Две сделки на разборе ссылаются на контакты, которые пока не прошли проверку. Они не назначаются случайному клиенту только ради совпадения общего счётчика. Все категории результата в этой таблице взаимоисключающие; один исходный объект учитывается ровно один раз.
Далее проверьте связи всех 58 перенесённых сделок: каждая должна указывать на ожидаемый итоговый контакт по таблице соответствий. Наличие любого существующего контакта недостаточно. Для повторного импорта этих же данных ожидается ноль новых контактов и сделок, если источник не изменился. Отдельно сохраните число обновлённых записей и ошибок, чтобы не смешивать обновление с созданием.
После согласованного объединения дублей равенство числа исходных и итоговых контактов может исчезнуть. Тогда нужен дополнительный реестр «исходный ID → итоговый ID» и отчёт о слияниях. Нельзя исправлять расхождение ручным удалением строк из исходной выгрузки.
Такой протокол дополняют сверкой статусов, ответственных и вложений. Итог «импорт выполнен» оставляют технической отметкой, а разрешение на переключение дают после разбора исключений и проверки отчётов CRM. Таблица выше показывает метод проверки, а не результаты переноса реальной клиентской базы.
Термины из материала
Источники и документация
У каждого документа указана дата последней проверки. Состав функций и интерфейсы сервисов могут меняться. Ссылки открываются в новой вкладке.
Применить к вашему проекту
Поможем подготовить карту переноса CRM и протокол проверки данных до переключения.
Обсудить задачу