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

Пошаговое руководство для компаний, которые меняют CRM-систему

Перенос данных из одной CRM в другую — это не выгрузка базы в Excel и загрузка её в новую систему, а отдельный проект с аудитом, маппингом полей, тестовым переносом и проверкой результата. Некачественная миграция — одна из главных причин провала при переходе на новую CRM: часть данных теряется, клиенты задваиваются, а связи между сделками, контактами и историей общения ломаются[1][2]. Если компания переходит с зарубежной CRM (Salesforce, HubSpot, Zendesk) на российскую, добавляется юридический слой: с 1 июля 2025 года первичный сбор, запись и хранение персональных данных граждан РФ должны вестись на серверах, физически расположенных в России[3][4]. Ниже — как спланировать перенос, какие есть технические способы сделать это и на что обратить внимание именно в российских реалиях.

Зачем компании вообще переносят данные между CRM

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

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

Что вообще нужно перенести

В CRM хранятся два типа данных — статические и динамические. Статические — это, по сути, справочник: контакты, компании, карточки клиентов. Динамические — это история: переписка, звонки, задачи по сделкам, отправленные документы, комментарии менеджеров[6]. Контакты перенести относительно легко: экспорт в таблицу и импорт в новую систему справляется с этим почти всегда[6]. А вот динамические данные — самая сложная часть переноса, потому что у них есть связи (какая переписка к какой сделке относится, кто и когда менял статус) и часто нет прямого аналога полей в новой системе.

Прежде чем планировать техническую часть, стоит явно ответить на вопрос: что из этого действительно нужно бизнесу дальше. Миграция — удобный повод избавиться от архивных и нерелевантных записей, а не тащить в новую систему весь накопленный «информационный мусор»[7].

Как устроен процесс миграции: 6 этапов

1. Аудит текущих данных

Прежде чем что-либо переносить, нужно понять объём, качество и актуальность базы: сколько записей, где дубликаты, какие поля заполнены некорректно (неправильный формат телефона, битые email, устаревшие статусы)[8]. Источники данных для аудита — не только сама CRM, это могут быть Excel-таблицы, 1С, почтовые ящики, история звонков от телефонии[1].

2. Очистка данных

После аудита — «генеральная уборка»: удаление дублей, исправление опечаток, приведение форматов дат, телефонов и адресов к единому виду[7]. Дедупликацию проще делать на этом этапе, чем после переноса — искать дубли можно вручную через условное форматирование в Excel по телефону или email, либо специализированными инструментами[1]. Если пропустить этот шаг, дубли переедут в новую CRM и будут размножаться дальше[8].

3. Проектирование целевой модели данных и маппинг полей

Это самый важный технический этап, от которого зависит корректность всего переноса. Сначала стоит спроектировать модель данных под реальные бизнес-процессы новой CRM, а уже потом сопоставлять с ней поля старой системы, а не наоборот[8]. Маппинг — это таблица соответствия: поле старой CRM → тип → длина → обязательность → поле новой CRM → комментарий[8][1]. Если в старой системе есть поля, которых нет в новой (нестандартные статусы, специфичные атрибуты сделки), для них заранее создают кастомные поля — до начала импорта, а не по ходу[1].

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

4. Тестовый перенос

Перед полной миграцией переносят ограниченный набор данных и фиксируют все ошибки[8]. Это позволяет поймать проблемы маппинга и форматов до того, как они затронут всю базу, а заодно подготовить план отката и определить окно технических работ.

5. Полный перенос и верификация

После успешного теста запускают перенос всей базы. Здесь частая ошибка — проверять только общее количество перенесённых записей. Этого недостаточно: нужен выборочный просмотр карточек и прогон реальных рабочих сценариев менеджеров, а также проверка интеграций — с телефонией, почтой, мессенджерами, сайтом, чтобы новые заявки и звонки действительно попадали в правильные сущности[8].

6. Подключение сотрудников и настройка правил на будущее

Полезная практика — попросить каждого менеджера проверить 10–20 «своих» клиентов после переноса: люди быстро замечают ошибки, которые не видны при автоматической проверке[1]. И сразу настроить в новой CRM правила, которые не дадут базе снова «замусориться»: обязательные поля, валидацию форматов, автоматический поиск дублей при создании новой записи[1].

Технические способы переноса

Ручной перенос

Подходит только для очень маленьких баз — компании часто выгружают контакты старой CRM в Excel и вручную заносят их в новую[6]. Метод медленный и подвержен ошибкам, для баз даже среднего размера не годится[7].

Импорт через файлы (CSV/XLS)

Большинство CRM поддерживают импорт-экспорт через файлы. Обычно процесс такой: выгрузить данные из старой системы (через её базу знаний или поддержку выясняют, как это сделать корректно), затем импортировать через встроенный инструмент новой CRM, где система сопоставляет поля файла с полями системы, например по уникальному идентификатору вроде ИНН[9]. Если сущности разнесены по отдельным файлам (компании, контакты, сделки), аналогичные шаги повторяют для каждой сущности[9].

Интеграция и перенос через API

Для сложных случаев — когда данных много, связи между объектами важны, а миграцию нужно повторить несколько раз (например, для финальной синхронизации перед переключением) — используют API. У большинства современных CRM (Битрикс24, amoCRM, Salesforce, Dynamics 365) похожая структура сущностей: контакт, компания, лид, сделка — это упрощает построение типовых интеграционных сценариев[10].

Здесь важно учитывать технические ограничения конкретной системы:

• У Битрикс24 списки сделок, комментариев и задач возвращаются пакетами по 50 элементов, а права на методы API регулируются через скоупы[11].
• У amoCRM действует лимит запросов к API — стандартно до 50 запросов в секунду на аккаунт, с возможностью расширения до 100–200 запросов в секунду за отдельную плату[12][13]. При превышении лимита система возвращает ошибку и может временно заблокировать доступ по IP[14].
• В обеих системах при разработке интеграции нужно закладывать защиту от дублей и повторных запросов — например, использовать уникальный ключ запроса и логику «сначала обновить, потом создать», чтобы сетевые сбои и автоповторы не плодили дубликаты[15].

ETL-инструменты и подрядчик на миграцию

Для сложных или крупных баз, где нужна многоступенчатая трансформация данных перед загрузкой, применяют специализированные ETL-инструменты, либо привлекают подрядчика, который берёт на себя миграцию под ключ[8].

Что предлагают сами CRM

Часть российских CRM заявляет встроенные инструменты миграции из конкретных систем — например, по данным на 2026 год такая функция официально заявлена у одной из российских CRM для переноса из amoCRM и Битрикс24, но перенос именно из Salesforce на официальных страницах не упоминается[16]. Это значит, что наличие встроенного инструмента миграции именно из вашей текущей системы нужно уточнять у вендора целевой CRM напрямую, а не считать само собой разумеющимся[16].

Российская специфика: локализация персональных данных

Если перенос данных связан с переходом с зарубежной CRM (или с любого зарубежного облачного хранилища) на систему с размещением в России, стоит учитывать требования 152-ФЗ «О персональных данных».

С 1 июля 2025 года действует обновлённая редакция части 5 статьи 18 152-ФЗ: первичный сбор, запись, систематизация, накопление и хранение персональных данных граждан РФ должны производиться с использованием баз данных, физически расположенных на территории России[3][4]. Формулировка закона: оператор обязан обеспечить запись, систематизацию, накопление, хранение, уточнение и извлечение персональных данных граждан РФ с использованием баз данных, находящихся на территории РФ[4]. Ключевое слово здесь — «первичная» обработка: закон касается именно первого сбора данных, а не любого их последующего использования[4].

Что это означает на практике:

• Использование зарубежной облачной CRM для первичного сбора и хранения персональных данных клиентов из РФ образует длящееся административное правонарушение по части 8 статьи 13.11 КоАП РФ[17].
• Штрафы по статье 13.11 КоАП существенно выросли: по нарушениям, связанным с локализацией и другими составами статьи, суммы для юридических лиц могут доходить до нескольких миллионов рублей, а в отдельных прецедентах — до 17 млн рублей за нарушение требований о локализации[18][19].
• Компании, обрабатывающие персональные данные клиентов через CRM, сайт или форму обратной связи, обязаны подать уведомление в Роскомнадзор об обработке персональных данных — это отдельное требование, не связанное напрямую с выбором CRM, но актуальное при любом сборе данных о клиентах[21][22].

Для бизнеса это означает, что миграция с иностранной CRM на российскую — часто не вопрос удобства, а вопрос соответствия закону. При этом нужно понимать разницу между «CRM размещена в России» и «CRM российского происхождения»: важен именно факт физического расположения серверов первичного сбора данных на территории РФ, а не страна регистрации вендора.

Типичные ошибки и риски при переносе

• Перенос без предварительного аудита и очистки. Это главная причина неудачных миграций: данные теряются или искажаются, а новая CRM с самого начала работает на грязной базе[2][7].
• Проверка только количества записей. Совпадение числа строк не гарантирует, что связи между сделками, контактами и историей общения перенеслись корректно[8].
• Игнорирование дублей после переноса. Без запуска дедупликации и правил на будущее дубли продолжают размножаться в новой системе[8].
• Не протестированные интеграции. Если не проверить связки с телефонией, почтой, мессенджерами и сайтом после миграции, заявки и звонки могут не долетать до нужных карточек или создавать новые дубли вместо привязки к существующим клиентам[8].
• Отсутствие плана отката. Миграция — необратимая по сути операция для боевой базы; без резервных копий и плана возврата к старой системе ошибка на проде обходится дорого[7][8].
• Недооценка лимитов API. При переносе через API легко упереться в ограничения по количеству запросов в секунду — это нужно закладывать в план миграции заранее, а не выяснять по ходу дела[14][12].

Как выбрать способ переноса

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

• Небольшая база (до нескольких сотен записей), простая структура — ручной перенос или импорт через CSV/Excel обычно достаточен.
• Средняя и крупная база со сложными связями между сделками, контактами и историей — импорт через файлы с тщательным маппингом, либо перенос через API.
• Постоянная синхронизация на переходный период (обе системы работают параллельно) — только через API или ETL-инструмент, файловый импорт для этого не подходит.
• Переход с зарубежной CRM без официального инструмента миграции, множество кастомных полей, нестандартная логика воронки — здесь обычно нужна разработка отдельного сценария миграции, а не использование готового импорта.

Как может помочь «Пятый фактор»

Перенос данных между CRM редко сводится к одной выгрузке-загрузке — сложность обычно в сопоставлении полей, обработке нестандартных сущностей, лимитах API и необходимости не потерять связи между сделками, контактами и историей коммуникаций. Команда «Пятого фактора» может изучить текущую структуру данных и бизнес-процессы, предложить архитектуру миграции с учётом лимитов и особенностей конкретных CRM, а также помочь с разработкой интеграции или переносом данных под ключ — включая случаи, когда переход связан с требованиями законодательства о локализации персональных данных.

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

Вывод

Перенос данных между CRM — это управляемый процесс, если относиться к нему как к проекту, а не к разовой операции «выгрузить-загрузить». Аудит и очистка данных до переноса, продуманный маппинг полей, тестовый прогон на ограниченной выборке и проверка связей и интеграций после миграции — то, что отличает успешный переход от базы, заваленной дублями и битыми записями. Для компаний, переходящих с зарубежных CRM, добавляется требование законодательства о локализации персональных данных — это стоит учитывать на этапе выбора целевой системы, а не постфактум.

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

Источники

[1] d7-crm.ru — Как перенести данные в CRM — миграция без потерь — https://d7-crm.ru/migratsiya-dannyh-v-crm/

[2] convertmonster.ru — Ошибки внедрения CRM: как избежать провала проекта — https://convertmonster.ru/blog/marketing-blog/tipichnye-oshibki-pri-vnedrenii-crm-sistem-kak-izbezhat-provala-proekta/

[3] consultant.ru — Локализация персональных данных — https://www.consultant.ru/law/podborki/lokalizaciya_personalnyh_dannyh/

[4] wcr-consulting.com — Локализация персональных данных по 152-ФЗ: требования — https://wcr-consulting.com/blog/2026/03/13/lokalizaciya-baz-dannyh-personalnyh-dannyh/

[5] kultura101.com — Salesforce в России: доступ, риски и реальные альтернативы — https://kultura101.com/blog/salesforce-v-rossii/

[6] okocrm.com — Как переехать в другую CRM с минимальными потерями времени и данных — https://okocrm.com/blog/pereezd-v-novuyu-crm/

[7] clientbase.ru — Миграция данных в новую CRM: как перенести клиентов без потерь — https://clientbase.ru/blog/all_about_crm/migraciya_dannih_v_novuyu_crm_kak_perenesti_kliento/

[8] crm64.ru — Методы миграции данных в CRM: безопасный перенос и сохранность информации — https://crm64.ru/bezopasnost-dannyh/metody-migraczii-dannyh-v-crm-bezopasnyj-perenos-i-sohrannost-informaczii/

[9] salesap.ru — Пошаговая инструкция по переезду из одной CRM-системы в другую — https://salesap.ru/blog/poshagovaya-instruktsiya-po-pereezdu-iz-odnoj-crm-sistemy-v-druguyu

[10] kt-team.ru — Интеграция CRM через API – принципы, сценарии и лучшие практики — https://www.kt-team.ru/blog/api-integration-crm-automation

[11] habr.com — REST API Битрикс24: как работает интеграция CRM — https://habr.com/ru/articles/1048762/

[12] sensei.plus — Как работают расширенные лимиты на запуск процессов и API — https://sensei.plus/extended-api-limits

[13] alarmcrm.ru — Изменение лимитов и условий тарифов amoCRM с 1 июня 2021 года — https://alarmcrm.ru/blog/price-change

[14] habr.com — комментарий пользователя kivill об ограничениях API amoCRM — https://habr.com/en/users/kivill/comments

[15] intervolga.ru — REST API Битрикс24: интеграция CRM с сайтом и сервисами — полный гайд — https://www.intervolga.ru/faq/bitrix24/rest-api-bitriks24-polnyy-gayd/

[16] admetric.pro — Альтернативы Salesforce в России в 2026 — https://admetric.pro/ru/blog/alternativy-salesforce/

[17] inmarlegal.ru — Сбор персональных данных: требования 152-ФЗ и штрафы — https://inmarlegal.ru/press/publications/pdn/sbor-personalnyh-dannyh-lokalizaciya/

[18] habr.com — Штрафы «за персональные данные»: как все устроено на самом деле — https://habr.com/ru/articles/1033666/

[19] consultant.ru — КоАП РФ Статья 13.11. Нарушение законодательства РФ в области персональных данных — https://www.consultant.ru/document/cons_doc_LAW_34661/1f421640c6775ff67079ebde06a7d2f6d17b96db/

[21] companies.rbc.ru — Новые требования к обработке персональных данных: полный гайд на 2026 год — https://companies.rbc.ru/news/SZRjtRsMIn/novyie-trebovaniya-k-obrabotke-personalnyih-dannyih-polnyij-gajd-na-2026-god/

[22] vseadvokaty.ru — Иностранная CRM-система и реестр операторов персональных данных: требуется ли регистрация? — https://vseadvokaty.ru/questions/tamozhennoe-pravo/66698