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

В три часа ночи мне позвонил директор логистической компании. Голос был хриплый — то ли от недосыпа, то ли от нервов. «Мы запустили новую CRM, а половины клиентов нет. Просто исчезли. Говорят, что-то с миграцией, но никто не может объяснить, что именно».

К утру мы нашли проблему. При переносе данных скрипт «склеил» 847 компаний с похожими названиями. ТОО «Алматы Логистик» и ТОО «Алматы-Логистик» — для алгоритма это был один и тот же клиент. Контакты перемешались, история заказов превратилась в кашу, менеджеры не понимали, кому звонить.

Эта история — не исключение. По нашей статистике, около 60% проектов внедрения CRM сталкиваются с серьёзными проблемами именно на этапе миграции данных. Не потому что технология сложная — технически перенести таблицы из одной базы в другую несложно. Проблема в том, что данные в старых системах обычно находятся в состоянии, которое вежливо называют «историческим наследием», а честно — бардаком.

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

Почему миграцию все недооценивают

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

А потом начинается реальность. И она выглядит примерно так:

В старой системе (или, что чаще, в десяти Excel-файлах на разных компьютерах) хранится информация о клиентах, которую копили годами. Кто-то вводил данные аккуратно, кто-то — как придётся. Один менеджер писал «Алматы», другой — «г. Алматы», третий — «Almaty». Телефоны записаны то с «+7», то с «8», то вообще без кода. Электронные адреса — иногда корректные, иногда с опечатками, иногда просто текст «уточнить».

И всё это богатство нужно перенести в новую CRM, где есть обязательные поля, справочники, валидация. Система ждёт, что город будет выбран из списка, а вы пытаетесь запихнуть туда «Алмата (рядом с MEGA)».

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

Подробнее о том, как в принципе подойти к вопросу качества данных, мы писали в статье Качество данных в CRM: как построить «единый источник правды». А сейчас сосредоточимся на практике миграции.

Этап 1: Разберитесь, что у вас есть

Прежде чем что-то переносить, нужно понять, что переносить. Звучит банально, но на практике это часто пропускают. «Да у нас всё в Excel, там понятно» — а потом выясняется, что есть ещё база в Access, записи в блокноте директора и «очень важная табличка на флешке у Гульнары, которая в декрете».

Шаг 1: Составьте карту источников данных

Пройдитесь по всем отделам и соберите информацию: кто где хранит данные о клиентах. Не только официальные системы, но и личные файлы, Google-таблицы, заметки. Часто самая ценная информация — именно там.

Вот что нужно выяснить для каждого источника:

• Где физически находятся данные (файл, система, облако)?
• Кто владелец и кто имеет доступ?
• Сколько примерно записей?
• Когда последний раз обновлялись данные?
• Есть ли пересечения с другими источниками?

Шаг 2: Определите, что переносить, а что — нет

Не все данные одинаково полезны. Клиент, с которым последний раз общались в 2015 году и который не отвечает на звонки — нужен ли он в новой CRM? Может, лучше оставить его в архиве?

Мы обычно делим данные на три категории:

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

Шаг 3: Оцените объём работы

Посчитайте количество записей в каждой категории. Это поможет спланировать ресурсы и сроки. Грубая формула: на очистку и перенос 1000 записей уходит примерно 1-2 рабочих дня (при ручной проверке) или несколько часов (при автоматизации с выборочной проверкой).

Если у вас 50 000 клиентов — это уже серьёзный проект, который требует автоматизации и чётких процессов. Если 500 — можно справиться почти вручную.

Этап 2: Война с дублями

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

Почему дубли — это плохо? Не только потому, что база выглядит неаккуратно. Реальные последствия:

• Менеджеры звонят одному клиенту несколько раз — клиент раздражается
• История коммуникаций разбросана по разным карточкам — менеджер не видит полную картину
• Отчёты показывают неверные цифры — кажется, что клиентов больше, чем есть
• Email-рассылки уходят на один адрес несколько раз — спам-фильтры блокируют

Как искать дубли: ключи сопоставления

Дубль — это когда две записи относятся к одному и тому же реальному объекту (клиенту, компании, сделке). Проблема в том, что записи редко совпадают полностью. «Иванов Иван» и «Иван Иванов» — это один человек? А «ТОО Алматы Логистик» и «Алматы Логистик ТОО»?

Для поиска дублей используют ключи сопоставления — поля или комбинации полей, которые с высокой вероятностью уникальны для каждой записи:

Автоматизация vs ручная проверка

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

Автоматически объединяем записи с высокой степенью уверенности: точное совпадение БИН, телефона, email. Здесь ошибка маловероятна.

На ручную проверку отправляем записи с частичным совпадением: похожие названия, один телефон, но разные адреса. Человек смотрит и решает.

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

Что делать при объединении дублей

Когда вы нашли дубль, возникает вопрос: какую информацию оставить? Вот правила, которые мы используем:

• Для уникальных полей (название, БИН) — берём из более «свежей» записи или из более достоверного источника
• Для контактных данных — объединяем (у клиента может быть несколько телефонов и email)
• Для истории — сохраняем всё из всех записей, сортируем по дате
• Для связей (контакты, сделки) — переносим все связи на объединённую запись

Важно: при объединении фиксируйте, какие записи были объединены. Это поможет, если что-то пойдёт не так и нужно будет «откатить» изменения.

Этап 3: Чистим и причёсываем данные

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

Валидация телефонов

Телефон — один из главных способов связи с клиентом. Если он неверный, менеджер не дозвонится. Что проверяем:

• Количество цифр (для Казахстана — 11 цифр с кодом страны)
• Код оператора или региона (реально существующий)
• Нет явно фейковых номеров (111-11-11, 123-45-67)

Нормализация телефонов — приведение к единому формату. Мы рекомендуем международный формат: +7 XXX XXX XX XX. Все входящие номера — будь то «8 701 123 45 67», «87011234567» или «701-123-45-67» — должны превращаться в один формат.

Валидация email

С email проще проверить формат (есть @, домен существует), но сложнее проверить актуальность. Базовые проверки:

• Синтаксис корректный (user@domain.com)
• Домен существует и принимает почту (проверка MX-записей)
• Нет временных почтовых сервисов (mailinator, 10minutemail)

Для массовой проверки используйте специализированные сервисы валидации email — они проверят, что адрес реально существует, без отправки писем.

Нормализация адресов и городов

Адреса — отдельная головная боль. Один и тот же адрес может быть записан десятком способов. Для Казахстана типичные проблемы:

• «Алматы» vs «Алма-Ата» vs «Almaty» vs «г. Алматы»
• Улицы с переименованиями (старые и новые названия)
• Разные форматы: «ул. Абая 1» vs «Абая улица, дом 1»

Решение — справочник городов и адресов. Лучше всего использовать официальные справочники (КАТО для Казахстана) и маппить входящие данные на стандартные значения.

Обработка пустых и некорректных значений

Что делать, если у клиента нет телефона? Или email невалидный? Варианты:

• Оставить пустым — если поле необязательное в новой CRM
• Пометить для уточнения — создать задачу менеджеру «уточнить контакты у клиента»
• Не переносить запись — если без этого поля запись бесполезна

Главное — не подставляйте фейковые значения типа «нет данных» или «уточнить». Они засоряют базу и искажают отчёты.

Этап 4: Маппинг — куда что переносить

У вас есть чистые данные. Теперь нужно понять, как они ложатся в структуру новой CRM. Это называется маппинг (mapping) — сопоставление полей источника и приёмника.

Кажется, что это просто: поле «Телефон» переносим в поле «Телефон». Но на практике возникают нюансы:

• В старой системе одно поле «Адрес», в новой — отдельно город, улица, дом
• Статусы сделок называются по-разному: «В работе» vs «Переговоры»
• В источнике свободный текст, в приёмнике — справочник
• Некоторых полей в новой системе нет — куда их девать?

Создайте таблицу маппинга

Документируйте каждое соответствие. Это поможет при отладке и при обучении команды. Пример:

Что делать с полями, которых нет в новой системе

Иногда в старой системе есть поля, которые не предусмотрены в новой. Три варианта:

Создать кастомное поле — если информация действительно нужна для работы. Но не увлекайтесь: каждое дополнительное поле усложняет систему.

Перенести в заметки/комментарии — если информация может пригодиться, но не требует структурированного хранения.

Не переносить — если поле устарело или дублирует другую информацию. Иногда миграция — хороший повод избавиться от лишнего.

Связи между сущностями

Компании связаны с контактами, контакты — со сделками, сделки — с задачами. При миграции важно сохранить эти связи. Проблема: в старой и новой системе идентификаторы разные.

Решение — таблица соответствия ID. При переносе каждой записи сохраняйте пару «старый ID — новый ID». Потом используйте эту таблицу для восстановления связей.

Этап 5: Прогон на тесте

Вы подготовили данные, настроили маппинг. Теперь хочется нажать кнопку и перенести всё в боевую систему. Стоп. Сначала — тестовая миграция.

Тестовая (или пилотная) миграция — это перенос данных в изолированную среду для проверки. Вы увидите результат, не рискуя боевыми данными.

Что проверять после тестовой миграции

• Количество записей — сколько было в источнике, сколько появилось в приёмнике. Если расхождение — разбираемся, куда делись записи
• Полнота данных — выборочно открываем карточки клиентов, проверяем, что все поля заполнены корректно
• Связи — контакты привязаны к компаниям, сделки — к контактам, задачи — к сделкам
• История — комментарии, звонки, письма — всё на месте и в правильном порядке
• Справочники — статусы, источники, ответственные — корректные значения

Привлеките пользователей

Технический специалист проверит структуру и количество. Но реальную пользу видят те, кто будет работать в системе. Попросите 2-3 менеджеров посмотреть своих клиентов в тестовой среде:

• Находят ли они своих ключевых клиентов?
• Вся ли история на месте?
• Корректные ли контакты?
• Есть ли что-то странное или непонятное?

Их обратная связь бесценна. Они заметят то, что пропустит скрипт.

Итерации

Редко всё получается с первого раза. Нашли ошибки — исправили скрипт — повторили тестовую миграцию. Две-три итерации — это норма. Пять и больше — повод задуматься, не упустили ли что-то на этапе подготовки.

Этап 6: Боевой запуск

Тестовая миграция прошла успешно, пользователи довольны, ошибки исправлены. Пора переносить данные в боевую систему. Как сделать это максимально безболезненно?

Выбор времени

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

Предупредите команду заранее. Они должны знать:

• Когда старая система будет недоступна (если будет)
• Когда можно начинать работать в новой
• К кому обращаться, если что-то не так

Подготовка отката

Надейтесь на лучшее, готовьтесь к худшему. Перед миграцией сделайте:

• Полный бэкап старой системы — чтобы можно было вернуться
• Снапшот новой системы до миграции — чтобы можно было очистить и начать заново
• План отката — что делать, если миграция провалилась критически

Инкрементальная vs полная миграция

Есть два подхода к боевой миграции:

Полная миграция (Big Bang) — переносите всё за один раз. Простой, понятный, но рискованный. Если что-то пойдёт не так — проблемы будут масштабными.

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

Для баз до 10 000 записей обычно подходит Big Bang. Для больших объёмов рекомендуем инкрементальный подход.

Параллельная работа

Иногда компании хотят «поработать в двух системах параллельно, чтобы убедиться, что всё нормально». Это ловушка. При параллельной работе данные расходятся уже в первый день. Кто-то вносит изменения в старую систему, кто-то — в новую. Через неделю у вас два разных источника правды.

Рекомендация: чёткий переход. Определяете дату, после которой старая система — только для чтения (а лучше — закрыта). Все работают в новой.

Этап 7: Первые дни после переезда

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

Мониторинг и поддержка

Будьте на связи. В первые дни пользователи будут находить проблемы, которые не поймали на тестировании. Это нормально — 100% качество на большом объёме данных недостижимо.

Что обычно всплывает:

• «А где клиент Х?» — оказывается, был отфильтрован как дубль
• «Почему у этой сделки неправильный статус?» — ошибка маппинга
• «История переписки исчезла» — не перенесли вложения или комментарии

Создайте канал для сбора обратной связи (чат, форма, ответственный человек). Быстро реагируйте на критичные проблемы.

Дочистка данных

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

Создайте задачи на дочистку и распределите по менеджерам. Каждый проверяет и дополняет «своих» клиентов. Так база постепенно придёт в идеальное состояние.

Документация и ретроспектива

Пока всё свежо в памяти — задокументируйте:

• Что было сделано (источники, маппинг, скрипты)
• Какие проблемы возникли и как решились
• Что сделать по-другому в следующий раз

Это пригодится при следующей миграции (а она будет — бизнес растёт, системы меняются) и при обучении новых сотрудников.

10 граблей, на которые все наступают

За годы работы мы участвовали в десятках миграций. Вот ошибки, которые повторяются раз за разом:

1. «Перенесём как есть, потом разберёмся» — нет, не разберётесь. Бардак в данных — бардак в работе. Чистить нужно до миграции.

2. Игнорирование тестовой миграции — «и так всё понятно, зачем тратить время». А потом в понедельник утром менеджеры не находят клиентов.

3. Миграция без бэкапа — надеются, что всё пройдёт гладко. Иногда проходит. Иногда нет. Бэкап делается всегда.

4. Недооценка времени — «там же просто таблицы перенести». Реальная миграция занимает в 2-3 раза больше, чем кажется.

5. Один человек отвечает за всё — и за скрипты, и за проверку, и за поддержку пользователей. Он не справится. Нужна команда.

6. Параллельная работа в двух системах — об этом уже говорили. Не делайте так.

7. Перенос всего подряд — включая мусор, тестовые данные и клиентов десятилетней давности. Меньше данных = меньше проблем.

8. Игнорирование связей — перенесли контакты, забыли привязать к компаниям. Теперь 5000 «бесхозных» контактов.

9. Отсутствие документации маппинга — через месяц никто не помнит, почему статус «Новый» превратился в «Квалификация».

10. Нет плана отката — когда всё сломалось, выясняется, что откатиться некуда. Бэкап есть, но как его восстановить — никто не знает.

Чек-лист: не забудьте

Сохраните этот чек-лист и используйте при планировании миграции:

Вместо заключения

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

Это требует времени, сил и терпения. Придётся возиться с неприятными деталями: разбирать дубли, выискивать правильные телефоны, объяснять менеджерам, почему нельзя «просто скопировать всё и разобраться потом».

Но результат того стоит. Чистая база данных — это:

• Менеджеры находят нужного клиента за секунды, а не минуты
• Отчёты показывают реальную картину, а не «где-то тут дубли»
• Автоматизация работает предсказуемо
• Клиенты не получают три одинаковых письма

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