Миграция CRM: как не потерять данные клиентов при переходе на новую систему

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

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

В этой статье — практический процесс от старта до «гиперкэра» после запуска. Без лишней воды, только шаги и нюансы.

Что на самом деле входит в миграцию CRM

Часто думают: «Выгрузим CSV, загрузим в новую систему — готово». Это не миграция. Это перенос таблицы. А таблица — только верхушка айсберга.

Полноценная миграция данных CRM включает несколько слоёв:

• Сущности — контакты, компании, сделки, обращения, кастомные объекты
• Связи — кто с кем связан: контакт → компания → сделка → активность
• История — письма, звонки, заметки, задачи, встречи, вложения
• Права доступа — роли пользователей, командные структуры, доступ к полям
• Зависимости — автоматизации, последовательности писем, интеграции, отчёты

Каждый слой добавляет сложность. Один контакт — это не строка в таблице. Это запись, связанная с компанией, открытыми сделками, цепочкой писем и автоматизацией. Если порвать одну связь — получаете «осиротевшие» записи, сломанные воронки и дыры в аналитике прямо на старте.

Важное разграничение: миграция и интеграция — разные вещи. Интеграция держит две системы синхронизированными на постоянной основе. Миграция — это разовое (или поэтапное) перемещение данных, после которого новая CRM становится единственным источником правды. Оба процесса могут идти параллельно, но у них разные задачи и разные ответственные.

Планирование: документ, который спасёт месяцы

Две-три недели на планирование экономят месяцы на исправление ошибок. Это не метафора — это практическое наблюдение.

Хороший план миграции отвечает на три вопроса: кто за что отвечает, что происходит пошагово и что будем делать, если что-то пойдёт не так.

Роли в команде. Для миграции нужны четыре функции:

1. Лид миграции — владеет планом, последовательностью и финальной проверкой
2. Владелец данных — отвечает за очистку, правила дедупликации и «выживаемость» полей
3. Бизнес-стейкхолдеры — продажи, маркетинг, сервис — согласуют, что переносить, а что архивировать
4. Технический исполнитель — строит скрипты трансформации полей, запускает API-миграцию, сверяет счётчики

Самая частая точка провала — непонятно, кто принимает решение «стартуем или нет». Определите это до начала.

Восемь фаз процесса: аудит → очистка → маппинг → тест в sandbox → миграция → валидация → переключение → гиперкэр (2–4 недели поддержки после запуска).

Тут есть нюанс: sandbox-тест нужно прогонять минимум дважды. Первый прогон покажет дыры в маппинге полей. Второй — уже после исправлений — даёт базу для валидации.

Очистка данных: делать до, не после

Это правило я считаю самым важным во всём процессе. Грязные данные в новой системе чистить в разы сложнее, чем в старой. Не переносите мусор — сначала разберитесь с ним.

Аудит перед стартом. По каждому типу объектов (контакты, компании, сделки) зафиксируйте:

• Общее количество записей
• Процент записей без ключевых полей (email, название компании, сумма сделки)
• Процент дублей — по точному совпадению email, по нечёткому совпадению имени, по домену компании
• Устаревшие записи — без активности 18–24 месяца или с явно невалидными данными
• Несогласованные значения в выпадающих списках (например, «Москва», «москва», «Мск» в одном поле)

Этот аудит даёт вам точку отсчёта: от чего идёте, к чему хотите прийти.

Дедупликация и нормализация. Начинайте дедупликацию с самого безопасного критерия — точного совпадения email. Дальше можно добавлять нечёткое совпадение имени + компании или дедупликацию по домену для компаний.

Нормализация — это стандарты: форматы телефонов, коды стран, значения в списках, определения этапов воронки. Зафиксируйте их в словаре данных. Эти же стандарты станут правилами управления данными в новой CRM.

Правила «выживаемости» при слиянии. Когда два дубля объединяются — какое значение остаётся? Например: из двух телефонных номеров оставляем более свежий. Из двух email-адресов делаем структуру «основной + дополнительный». Пропишите эти правила до начала дедупликации — иначе получите тысячи несогласованных решений и новые проблемы с качеством данных.

Кстати, о том, как правильно хранить данные клиентов и не нарваться на проблемы с доверием, есть отдельный разбор — CRM и данные клиентов: как не потерять доверие и не нарваться на штраф.

Маппинг полей и последовательность переноса

Маппинг — это соответствие полей старой CRM полям новой. Звучит просто. На практике — это первое место, где проекты встают.

Инвентаризация полей источника. Прежде чем маппить — соберите полный список всех полей: кастомные, устаревшие, неиспользуемые. Для каждого поля: тип данных, значения выпадающего списка, связи-ссылки (например, «ответственный за сделку» → запись пользователя).

Сделайте таблицу маппинга с колонками: поле-источник → тип → значения списка → поле-назначение → тип → нужна ли трансформация → статус.

Три типа конфликтов, которые встречаются почти всегда:

• Несоответствие типов — в источнике текстовое поле, в новой системе требуется выпадающий список. Нужна нормализация перед переносом.
• Отсутствие поля — в источнике есть поле, в новой системе аналога нет. Создать кастомное свойство, смапить в ближайшее или архивировать.
• Разные названия — в источнике «Владелец аккаунта», в новой системе «Ответственный менеджер».

Последовательность переноса — критически важна. Правило одно: сначала родительские объекты, потом дочерние. Если перенести контакты до компаний — привязать их будет не к чему. Рекомендуемый порядок:

1. Пользователи (нужны, чтобы назначить ответственных на все остальные записи)
2. Компании / аккаунты
3. Контакты (с привязкой к компаниям)
4. Сделки / возможности (с привязкой к контактам и компаниям)
5. Обращения / тикеты
6. Кастомные объекты (после родительских)
7. Активности: заметки, звонки, письма, задачи, встречи
8. Вложения и документы (самыми последними)

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

Историческая активность: что переносить, а что нет

Типичная ловушка: команда решает перенести вообще всю историю. И именно это часто срывает сроки и бюджет.

Перед тем как включать историческую активность в объём миграции, оцените её по четырём критериям:

• Юридические требования — есть ли в вашей сфере обязательства по хранению данных? На какой срок и в какой форме?
• Операционная ценность — команда продаж реально открывает активности старше двух лет при работе с клиентом? Если нет — ценность низкая.
• Аналитика — используется ли история в отчётах, моделях атрибуции, прогнозировании? Если да — переносить. Если нет — архивировать.
• Объём хранилища — большие библиотеки вложений (предложения, договоры, записи звонков) сильно увеличивают время и стоимость. Им, возможно, место в отдельной системе документооборота, а не в CRM.

Практическая рекомендация: переносите 12–18 месяцев активности. Всё старше — архивируйте в read-only хранилище (отдельный облачный бакет, старая CRM в режиме чтения или дата-вархаус). Задокументируйте это решение и сообщите стейкхолдерам до запуска.

Отдельный момент — история писем. Большинство современных CRM логируют новые письма автоматически через подключение почты. Перенос исторической переписки — это, как правило, самая трудозатратная и наименее ценная часть миграции. Трезво оцените, стоит ли игра свеч.

Кстати, о том, как выстроить работу с email как инструментом продаж — есть хороший материал: Анатомия письма, которое читают: что делает email рабочим инструментом продаж.

Валидация и запуск: как убедиться, что всё в порядке

Давайте по шагам — что нужно проверить перед тем, как выключить старую систему и переключиться на новую.

Валидация в три уровня:

• Счётчики записей — количество контактов, компаний, сделок в новой системе должно совпасть с исходным (с учётом намеренно исключённых записей). Расхождение — стоп-сигнал.
• Точечные проверки — выборочно откройте 20–30 записей разных типов и сверьте поля вручную. Особенно кастомные поля и связи.
• Пользовательское приёмочное тестирование (UAT) — попросите реальных пользователей из команды продаж и маркетинга проверить свои рабочие процессы в новой системе до официального запуска.

Гиперкэр после запуска. Первые 2–4 недели после переключения — самые уязвимые. В этот период нужен выделенный мониторинг: кто-то ежедневно проверяет ошибки, отвечает на вопросы пользователей и разрешает краевые случаи.

И обязательно: до запуска определите триггер отката. Если X% записей битые или Y критических процессов сломаны — откатываемся. Без заранее прописанного порога решение принимается в панике, и это ведёт к ещё большим потерям.

Коммуникация с командой. Пользователи должны знать, что меняется, когда и почему — ещё до того, как они первый раз зайдут в новую систему. Хаотичный запуск без объяснений гарантирует сопротивление и саботаж нового инструмента. Это недооцениваемая, но критически важная часть всей миграции.

Если вы работаете с данными и хотите понять, как аналитика помогает принимать следующие шаги — посмотрите на подход к аналитике для экспертов, там есть полезная логика применительно к принятию решений на основе данных.

Итого: миграция CRM — это не техническая задача

Если коротко — это бизнес-изменение. С целями, ограничениями и критериями успеха. Технически переезд — лишь середина процесса. Большая часть работы — до и после.

Три принципа, которые решают исход:

1. Чистите данные до переноса, не после. Грязные данные в новой системе — это дорогостоящий хаос.
2. Соблюдайте последовательность объектов. Родительские сущности — первые. Всегда.
3. Не переносите всё подряд. 12–18 месяцев активной истории — обычно достаточно. Остальное — в архив.

Миграция — это возможность навести порядок в данных раз и навсегда. Многие команды потом говорят, что это лучшее, что они сделали для своей операционной системы. Главное — не спешить и не пропускать этапы.

Если хотите разобраться, как выстроить систему работы с клиентскими данными без лишних сложностей — заходите в мой Telegram-канал. Там разборы, практика и живые примеры без инфобизнес-шума.

По мотивам материала HubSpot Marketing «CRM data migration: A practical process overview».

100 нейросетей
для экспертов

Подборка, которой реально пользуются — пришлю на почту. Без спама, отписка в один клик.

Для решения
любых задач

Для роста
и эффективности

Для бизнеса
и карьеры

🎁 Заберите 100 нейросетей для экспертов

Получить подборку Соглашаюсь на обработку email и получение писем