Перенос CRM: как сохранить базу клиентов и историю работы

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

Допустим, компания продаёт оборудование, а затем обслуживает его. У одного клиента несколько закупок, разные контактные лица и действующий договор на обслуживание. Объединение всего этого в одну карточку с общим комментарием затруднит работу. Это условный пример: для вашего бизнеса критичными могут быть другие связи — объект, филиал, абонемент или заказ.

Составьте перечень данных до выбора способа переноса

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

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

Не принимайте обещание «перенесём всё» без перечня исключений. В официальной справке Битрикс24 указано, что штатный импорт и экспорт дел недоступен. Это не запрещает обсуждать другие способы миграции, но показывает, почему перенос таблицы не равен переносу всей истории. Возможности конкретного инструмента нужно подтвердить пробной загрузкой.

Подготовьте таблицу соответствий

Для каждого поля старой базы определите место в новой: название, тип, допустимые значения, правило обработки пустоты. Например, текст «Иван Петров» не должен автоматически становиться ответственным сотрудником, если в новой системе два человека с таким именем. Нужны устойчивые идентификаторы и явное сопоставление пользователей.

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

Сохраните соответствие старого и нового ID для каждой записи. Оно помогает находить ошибки, восстанавливать связи и переносить изменения повторно. В amoCRM обновление существующих записей при импорте связано с настройками обновления и идентификаторами; правила описаны в инструкции по дублям. Не заменяйте их предположением, что совпавшего названия компании всегда достаточно.

Проверьте перенос на сложных карточках

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

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

• Запишите исходный ID, новый ID, ожидаемый результат и фактический результат.
• Отметьте пропущенные поля, нарушенные связи и лишние записи.
• Исправьте правило преобразования, затем повторите тест на той же выборке.
• Проверьте, что повторная загрузка не создаёт новые копии уже перенесённых объектов.

Согласуйте момент переключения

Пока команда работает в старой системе, данные меняются. Нужно определить время основной выгрузки, способ переноса изменений после неё и момент, когда новые обращения начинают поступать в новую CRM. У каждого канала — формы, телефонии, почты — должен быть ответственный за переключение и контрольная проверка.

На период переноса договоритесь, где сотрудники фиксируют новые договорённости. Одновременная работа без правил в двух CRM создаёт расходящиеся версии карточек. Если требуется временная пауза, предупредите команду и организуйте отдельный учёт входящих обращений с последующим занесением. Саму паузу и порядок восстановления согласуйте до начала работ.

Подготовьте возврат и приёмку

До переключения сохраните проверенную копию исходных данных и инструкции, как вернуться к прежнему приёму заявок. Назовите условия остановки: например, массовая потеря связей или невозможность принимать обращения. Возврат тоже требует плана для заявок, которые уже появились в новой CRM. Простое включение старой системы их туда не перенесёт.

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

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