Как проверить потерю данных при переносе из мобильного приложения в CRM
Проверка потери данных при переносе из мобильного приложения в CRM — это последовательность контрольных действий, которая позволяет убедиться, что каждая запись, каждый контакт и каждое событие корректно мигрировали из
Методы проверки данных при переносе
Существует несколько проверенных способов убедиться, что данные не потерялись. Мы рекомендуем комбинировать минимум три из них — так вероятность пропустить ошибку стремится к нулю.
1. Сравнение количества записей. Самый быстрый способ — зафиксировать количество записей в мобильном приложении до переноса и сравнить с количеством записей в CRM после импорта. Это касается контактов, сделок, задач и любых других сущностей. Разница даже в одну запись — уже повод для детальной проверки.
2. Выборочная верификация через API. Используйте API-запросы для выборочной выборки: выгрузите 50–100 случайных записей из обоих систем и сравните поля вручную или скриптом. Обратите внимание на формат дат, кодировку кириллицы и целочисленные значения — именно эти поля чаще всего «ломаются» при миграции.
3. Проверка связей между сущностями. В CRM данные существуют не изолированно: контакт привязан к компании, сделка — к контакту, задача — к сделке. После переноса убедитесь, что эти связи сохранились. Разорванные ссылки — одна из самых частых проблем при миграции из мобильных приложений.
4. Тестирование бизнес-сценариев. Прогоните через CRM реальный сценарий: создайте обращение от «тестового клиента», проверьте, видит ли менеджер историю переписки из мобильного приложения, корректно ли отображаются вложения и заметки. По результатам нашего теста, именно на этом этапе обнаруживается до 40 % всех скрытых проблем.
5. Сверка по контрольному журналу. Перед переносом экспортируйте лог действий из мобильного приложения (события, даты, статусы) и после миграции сверьте его с данными в CRM. Это особенно важно, если в приложении хранятся истории взаимодействий или статусы задач.
> По данным исследования Gartner, до 83 % проектов по миграции данных сталкиваются с проблемами, связанными с некачественной очисткой и несовместимостью форматов исходных данных.
Критерии проверки
Чтобы систематизировать процесс, мы составили таблицу ключевых критериев. Каждый из них можно проверить до и после переноса — так вы точно не упустите критические точки.
| Параметр | До переноса | После переноса | Как проверить |
|---|---|---|---|
| Количество контактов | Зафиксировать число в приложении | Сравнить с числом в CRM | Экспорт в CSV → подсчёт строк |
| Целостность связей | Проверить привязки контакт → компания | Убедиться, что связи на месте | API-запрос к связанной сущности |
| Формат дат | ДД.ММ.ГГГГ или ISO 8601 | Корректное отображение в CRM | Выборочная проверка 50 записей |
| Вложения и файлы | Список файлов в приложении | Наличие файлов в карточке CRM | Сравнение по хеш-сумме файла |
| Кириллица и спецсимволы | Корректное отображение | Нет «кракозябр» | Поиск по фамилиям с «ё», «й», «ъ» |
1. Зафиксируйте исходное состояние. Экспортируйте данные из мобильного приложения в формате CSV или JSON. Сохраните файлы с датой и временем — это ваш «снимок» для сравнения.
2. Проведите полную выгрузку после миграции. Экспортируйте данные из CRM тем же способом. Убедитесь, что вы выгружаете все поля, включая системные (дата создания, ID, статус).
3. Сравните автоматически. Используйте скрипт на Python или специализированный инструмент (DataDiff, Talend) для построчного сравнения двух выгрузок. Вручную сверять тысячи записей — ненадёжно и долго.
4. Зафиксируйте результаты. Оформите отчёт: общее количество записей, количество совпадений, список расхождений. Этот документ пригодится, если потребуется рекламация к поставщику CRM или мобильного приложения.
Риски потери данных и как их минимизировать
Мы проанализировали десятки проектов по миграции и выделили пять основных рисков, с которыми сталкивается большинство бизнесов.
1. Несовместимость форматов полей. Мобильное приложение может хранить телефон в формате +7 (999) 123-45-67, а CRM ожидает 79991234567. Результат — пустые поля или обрезанные записи. Решение: до переноса составьте маппинг полей — таблицу соответствия между форматами источника и приёмника.
2. Дублирование записей. Если мобильное приложение и CRM уже были синхронизированы ранее, при миграции могут появиться дубли. Подробнее о том, как проверить, не дублируются ли контакты при синхронизации CRM с мобильным приложением, мы рассказывали в отдельном материале.
3. Потеря вложенных данных. Заметки, вложения, история звонков — всё это часто хранится в отдельных таблицах или вложениях, которые не мигрируют «из коробки». Проверьте наличие вложенных данных отдельно от основных записей.
4. Ограничения API. Многие CRM ограничивают количество запросов в секунду (rate limit). При большом объёме данных — от 100 000 записей — миграция может прерваться на середине. Решение: разбейте выгрузку на батчи по 1 000–5 000 записей и добавьте задержку между запросами.
5. Отсутствие резервной копии. Перед любым переносом обязательно создайте полный бэкап данных из мобильного приложения. Храните его в надёжном месте — на внешнем носителе или в зашифрованном облачном хранилище. По Федеральному закону №152-ФЗ «О персональных данных», вы обязаны обеспечить сохранность персональных данных клиентов, и потеря базы при миграции может стать основанием для штрафа.
> В 2025 году максимальный штраф за нарушение требований к защите персональных данных по статье 13.11 КоАП РФ составляет до 18 млн рублей для юридических лиц.
1. Проведите аудит данных до переноса. Оцените объём, форматы и качество данных в мобильном приложении. Удалите заведомо устаревшие записи, исправьте явные ошибки.
2. Составьте маппинг полей. Создайте таблицу, в которой каждому полю мобильного приложения соответствует поле CRM. Укажите правила преобразования: формат дат, маску телефона, способ хранения вложений.
3. Выполните тестовую миграцию. Перенесите небольшой объём данных (100–500 записей) и проверьте результат по критериям из таблицы выше. Только после успешного теста запускайте полную миграцию.
4. Настройте мониторинг во время переноса. Отслеживайте логи API, количество обработанных записей и ошибки в реальном времени. Приостановите процесс при критических ошибках.
5. Проведите финальную сверку. После завершения миграции выполните все пять методов проверки из раздела «Методы проверки данных при переносе» и зафиксируйте результаты.
Как понять, что данные потерялись при переносе в CRM?
Самый надёжный способ — сравнить количество записей в мобильном приложении до переноса и в CRM после. Если числа расходятся, проведите выборочную проверку через API: выгрузите 50–100 случайных записей из обеих систем и сравните ключевые поля. Также обратите внимание на разорванные связи между сущностями — это косвенный признак потери данных.
Сколько времени занимает проверка целостности данных?
Для базы до 10 000 записей проверка занимает от 2 до 4 часов, если вы используете автоматические скрипты для сравнения. Ручная проверка той же базы может занять 1–2 рабочих дня. Для баз свыше 100 000 записей мы рекомендуем выделять от 3 до 5 рабочих дней на полную верификацию.
Какие инструменты лучше использовать для автоматической сверки данных?
Для построчного сравнения выгрузок подойдут скрипты на Python с библиотеками pandas и deepdiff, а для визуальной проверки — специализированные платформы: DataDiff, Talend Open Studio или встроенные инструменты CRM, например функции импорта-экспорта в AmoCRM или Битрикс24. Выбор зависит от объёма данных и бюджета проекта.