Миграция 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 и получение писем