Когда компания решает сменить CRM или учётную систему, всё внимание обычно приковано к новым возможностям: удобный интерфейс, автоматизация, отчёты. О данных вспоминают ближе к концу: «а, ну и перенести всё из старой системы». И именно здесь проекты чаще всего застревают. Выясняется, что данные хранятся в непонятном формате, половина полей заполнена как попало, а связи между сущностями держались на договорённостях сотрудников, а не на структуре базы.
История клиентов, сделок, заказов и платежей — это актив, который копился годами. Потерять его или перенести в искажённом виде — значит лишить менеджеров контекста, а руководителя — аналитики. В этой статье рассказываем, как мы подходим к миграции данных, чтобы новая система с первого дня была наполнена корректной и полезной информацией.
Почему миграция сложнее, чем кажется
На первый взгляд всё просто: выгрузить таблицы из старой системы, загрузить в новую. Но на практике возникает множество проблем:
- Разные модели данных. В старой системе контакт и компания — одна запись, в новой — две связанные сущности. Сделка в одной системе — это заказ в другой, а статусы вообще не совпадают.
- Грязные данные. Дубли, опечатки, телефоны в произвольном формате, пустые обязательные поля, устаревшие записи.
- Скрытая логика. Сотрудники годами использовали поле «Комментарий» для хранения важной информации, а поле «Тип клиента» понимали каждый по-своему.
- Объём. Сотни тысяч записей, миллионы событий истории, гигабайты вложений.
- Ограниченный доступ. У старой системы может не быть удобного API, а вендор не торопится помогать с выгрузкой.
- Работающий бизнес. Пока идёт миграция, в старой системе продолжают появляться новые данные.
Миграция данных — это отдельный проект внутри проекта внедрения. Если планировать её как одну задачу на последнюю неделю, сроки сорвутся почти гарантированно.
Этап 1. Аудит источников данных
Первое, что нужно сделать, — составить полную карту того, где и какие данные живут. Почти всегда оказывается, что источников больше, чем кажется:
- Основная старая система — CRM, учётная программа, самописная база.
- Таблицы, которые ведут отдельные сотрудники или отделы.
- Почтовые ящики с перепиской и вложениями.
- Файловые хранилища с договорами, спецификациями, фотографиями.
- Внешние сервисы — телефония, рассылки, сервис доставки, онлайн-касса.
Для каждого источника фиксируем: какие сущности там хранятся, в каком объёме, насколько они актуальны, кто их владелец и как их можно выгрузить. Отдельно отмечаем, какие данные нужны в новой системе обязательно, какие — желательно, а какие можно оставить в архиве.
Этап 2. Решить, что переносить
Не всё, что накопилось в старой системе, нужно в новой. Перенос мусора увеличивает сроки и стоимость, а заодно засоряет новую систему. Поэтому стоит заранее договориться о правилах.
Типичные решения:
- Справочники — переносятся полностью после очистки.
- Активные клиенты — переносятся со всей историей.
- Неактивные клиенты — переносятся только основные данные, либо остаются в архиве с возможностью поиска.
- Открытые сделки и заказы — переносятся обязательно, со всеми деталями.
- Закрытые сделки — переносятся за определённый период, нужный для аналитики, остальное уходит в архив.
- История событий — звонки, письма, комментарии переносятся как лента событий в карточке клиента.
- Вложения — переносятся выборочно или остаются в файловом хранилище со ссылками из новой системы.
Важно: архив не должен быть «чёрной дырой». Если старую систему планируется отключить, нужно обеспечить доступ к архивным данным в режиме чтения — хотя бы через простую выгрузку с поиском.
Этап 3. Очистка данных
Очистка — самая трудоёмкая часть. Её нельзя полностью автоматизировать, потому что многие решения требуют знания бизнеса.
Что обычно входит в очистку:
- Нормализация форматов. Телефоны к единому виду, адреса почты в нижний регистр, даты в единый формат, названия компаний без лишних кавычек и пробелов.
- Поиск и объединение дублей. Автоматический поиск по телефону, почте, ИНН, названию, затем ручная проверка спорных случаев.
- Заполнение пропусков. Где возможно — автоматически из других источников, где нет — силами сотрудников или с пометкой «требует уточнения».
- Исправление некорректных значений. Например, скидка в сто пятьдесят процентов или дата рождения в будущем.
- Разбор «свободных» полей. Информацию из комментариев, которая на самом деле структурированная, переносим в отдельные поля.
Хорошая практика — выделить владельцев данных со стороны бизнеса. Руководитель продаж решает спорные случаи по клиентам, главный бухгалтер — по контрагентам и финансовым данным, руководитель склада — по номенклатуре.
Этап 4. Маппинг: сопоставление старого и нового
Маппинг — это документ, который описывает, как каждое поле старой системы превращается в поле новой. Он кажется бюрократией, но без него миграция превращается в бесконечную серию ручных исправлений.
В маппинге фиксируются:
- соответствие сущностей: что в старой системе было «клиентом», становится «компанией» и «контактом»;
- соответствие полей с указанием типов данных;
- правила преобразования: как старые статусы превращаются в новые этапы воронки;
- значения по умолчанию для обязательных полей, которых не было в старой системе;
- правила для связей: как восстанавливаются ссылки между клиентами, сделками, документами;
- что делать с записями, которые не проходят проверку.
Особое внимание — статусам и справочникам
Самая частая проблема маппинга — статусы и значения списков. В старой системе у сделки могло быть пятнадцать статусов, из которых половина не использовалась, а в новой — семь этапов воронки. Сопоставление должно быть согласовано с теми, кто будет работать с этими данными, иначе отчёты по воронке сразу после запуска покажут ерунду.
Этап 5. Пробные прогоны
Никогда не делайте миграцию с первого раза в боевую систему. Правильный подход — несколько пробных загрузок в тестовую среду с проверкой результатов.
Как организовать пробные прогоны:
- Первый прогон — технический. Проверяем, что скрипты работают, данные загружаются без ошибок, связи восстанавливаются.
- Второй прогон — содержательный. Ключевые пользователи проверяют выборку записей: открывают карточки знакомых клиентов, сверяют историю, суммы, статусы.
- Третий прогон — генеральная репетиция. Полная загрузка с замером времени, чтобы понять, сколько займёт финальная миграция и уложится ли она в окно переключения.
После каждого прогона фиксируем ошибки, исправляем скрипты или исходные данные и повторяем. Обычно нужно три–пять итераций, чтобы результат устроил всех.
Этап 6. Проверка качества
Как понять, что миграция прошла успешно? Нужны объективные критерии, о которых договорились заранее.
- Количественная сверка. Число клиентов, сделок, заказов в старой и новой системе совпадает с учётом осознанно отфильтрованных записей.
- Финансовая сверка. Суммы открытых сделок, задолженности клиентов, остатки на складе совпадают до копейки и до единицы.
- Выборочная проверка. Пользователи проверяют случайную выборку записей и несколько десятков «эталонных» клиентов, которых хорошо знают.
- Проверка отчётов. Ключевые отчёты в новой системе показывают те же цифры, что и в старой, за одинаковые периоды.
- Проверка связей. У каждого заказа есть клиент, у каждой сделки — ответственный, у каждого документа — правильная привязка.
Этап 7. Переключение
Финальная миграция проводится в заранее согласованное окно, чаще всего в выходные. Чтобы она прошла спокойно:
- заранее объявите сотрудникам, когда старая система переходит в режим только для чтения;
- проведите финальную выгрузку после того, как ввод данных остановлен;
- загрузите данные по отработанному на репетициях сценарию;
- выполните сверку по согласованным критериям;
- только после успешной сверки откройте новую систему для работы.
Если переключение в выходные невозможно, используется инкрементальная миграция: основной массив переносится заранее, а в момент переключения догружаются только изменения за последние дни. Это требует более сложных скриптов, но сокращает окно простоя до нескольких часов.
Обязательно подготовьте план отката: что делать, если сверка показала критические расхождения. Старая система должна оставаться работоспособной до тех пор, пока новая не подтвердила корректность данных.
Что делать после переноса
Первые недели после переключения пользователи будут находить мелкие неточности. Это нормально, если есть понятный канал для сообщений об ошибках и команда, которая быстро их исправляет. Не спешите отключать старую систему: держите её в режиме чтения хотя бы несколько месяцев, пока не закроется отчётный период и не станет ясно, что ничего не потеряно.
Используйте миграцию как повод установить правила качества данных в новой системе: обязательные поля, проверку формата, автоматический поиск дублей при создании записи. Иначе через несколько лет придётся снова наводить порядок.
Вывод
Миграция данных — это не техническая формальность, а самостоятельный проект с собственными этапами: аудит, отбор, очистка, маппинг, пробные прогоны, проверка и переключение. Если пройти их последовательно и вовлечь владельцев данных со стороны бизнеса, история клиентов перейдёт в новую систему целиком и в лучшем виде, чем была.
Если вы планируете смену CRM или учётной системы и хотите перенести данные без потерь, мы поможем спланировать и провести миграцию в рамках разработки CRM или настроить обмен между системами через интеграцию по API.