Как подготовить данные к миграции из Excel или старой CRM?

Начните с неизменяемой копии исходных данных и перечня всех мест, где компания их хранит. Затем определите, что нужно переносить, как однозначно распознавать клиентов и контакты, какие поля соответствуют друг другу и что делать с пропусками и дубликатами. Планировать окончательное переключение стоит только после проверки тестового импорта.

Выгрузка в CSV не подтверждает полноту и готовность данных. Список клиентов может не содержать связей с контактными лицами, заметками, файлами, историей, задачами или правами доступа. Поэтому миграция не сводится к переносу строк из одной таблицы в другую.

CSV-файл является только одним из источников

CSV часто используется для обмена данными между таблицами и системами. Но даже его базовая структура требует правильной обработки заголовков, разделителей, переводов строк и значений с запятыми или кавычками. Разные программы могут формировать такие файлы по-разному.

Ещё важнее деловой смысл. Поле `Клиент` в одном источнике может обозначать компанию, а в другом конкретного человека. `Статус` может быть этапом продажи, состоянием оплаты или признаком активности контакта. Похожее название не гарантирует одинакового значения.

Также проверьте данные, которые находятся вне основной таблицы:

• контакты, связанные с компаниями;
• заметки и историю общения;
• задачи, сроки и напоминания;
• документы и вложения;
• заказы, обращения или сделки;
• согласия, источники контакта и ответственных сотрудников;
• значения, хранящиеся только в дополнительных листах или файлах.

Если новая система должна использовать эти сведения, для каждой группы нужен отдельный план переноса. Нельзя считать, что данные попадут в экспорт только потому, что они были видны в старой CRM.

1. Сохраните данные до начала очистки

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

Не очищайте единственную копию. Создайте рабочую версию и фиксируйте изменения. Это позволит вернуться к источнику, сравнить значения и объяснить принятое решение.

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

Способ резервирования зависит от системы и доступных прав. Экспорт из панели управления не всегда включает базу, файлы и полную историю, поэтому фактический объём нужно проверить для конкретного решения.

2. Перечислите источники и определите, каким значениям доверять

Во многих компаниях часть данных находится в CRM, часть в таблицах, а последние договорённости в почте или личных заметках. Назовите эти источники, их пользователей и человека, который будет разрешать противоречия.

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

3. Решите, что переносить, а что архивировать

Перенос всей истории может увеличить стоимость и сделать новую систему менее удобной. Разделите данные на:

• активные записи, нужные в текущей работе;
• исторические записи, которые должны оставаться доступными;
• записи, требующие решения из-за неясного владельца, статуса или назначения;
• дубликаты, тестовые и устаревшие технические записи, которые не следует копировать автоматически.

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

4. Подготовьте карту полей

Карта полей показывает, как каждое важное значение источника будет представлено в целевой системе.

Карта должна описывать смысл, формат, обязательность, допустимые значения и обработку пропусков. В ней также указывается, кто утверждает правило. Разработчик может реализовать преобразование, но не должен самостоятельно решать, что означает противоречивый статус для бизнеса.

5. Сохраните идентификаторы и связи

Совпадение количества записей ещё не доказывает успешную миграцию. Компания может присутствовать в новой CRM, но её контакты, заметки или открытые обращения будут связаны с другой учётной записью.

Проверьте устойчивые идентификаторы. Названия, адреса электронной почты и телефоны могут меняться или использоваться несколькими людьми. Внутренние ID обычно надёжнее, если они уникальны и стабильно выгружаются.

Необходимо сохранить связи:

• компания и её контакты;
• клиент и заказы или обращения;
• обращение и заметки или вложения;
• запись и ответственный сотрудник;
• головная компания и филиалы.

Если целевая система создаёт новые ID, сохраните таблицу соответствия старых и новых идентификаторов. Она пригодится при поиске расхождений и повторном тестовом импорте.

6. Задайте правила для дубликатов и пропусков

Дубликаты следует искать по нескольким признакам. Одна компания может быть записана под сокращённым и полным названием, а разные сотрудники могут использовать общий офисный адрес. Совпадающий e-mail или телефон является полезным признаком, но не всегда достаточен для автоматического объединения.

Разделите правила для:

• подтверждённых дубликатов, которые можно объединить автоматически;
• вероятных дубликатов, требующих ручной проверки;
• похожих записей, которые должны остаться отдельными;
• пропусков, допустимых в целевой системе;
• пропусков, блокирующих импорт;
• противоречий, требующих решения владельца процесса.

При миграции нельзя придумывать недостающие сведения. Если значение не подтверждено, его следует оставить пустым или отметить для проверки согласно утверждённому правилу.

7. Проведите тестовый импорт на репрезентативных данных

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

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

8. Проверьте результат на нескольких уровнях

После тестового импорта проверьте:

1. количество записей каждого типа;
2. обязательные и важные для бизнеса поля;
3. связи между записями;
4. справочники, статусы и ответственных сотрудников;
5. даты, телефоны, e-mail и кодировку символов;
6. заметки, файлы и историю, входящие в согласованный объём;
7. репрезентативные случаи, выбранные владельцами процессов;
8. могут ли пользователи выполнять реальную работу с перенесёнными данными.

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

9. Спланируйте переключение и возможность остановки

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

• когда прекращается редактирование старой CRM;
• нужно ли отдельно перенести изменения после теста;
• сколько времени отводится на проверку;
• кто разрешает начать работу в новой системе;
• что делать, если критерии приёмки не выполнены;
• как долго и в каком виде будет доступен старый источник или архив.

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

10. Что подготовить перед разговором с исполнителем?

На первом этапе не нужно отправлять всю базу. Подготовьте:

1. список систем, таблиц и дополнительных источников;
2. описание значения данных в ежедневной работе;
3. важные поля, статусы и связи;
4. примерное количество записей, файлов и вложений;
5. разделение активных и архивных данных;
6. известные проблемы с пропусками, форматами и дубликатами;
7. желаемый срок и допустимые ограничения работы;
8. человека, имеющего право принимать решения о данных;
9. критерии приёмки тестовой и окончательной миграции;
10. анонимный или синтетический пример структуры.

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

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

Что показывают предыдущие проекты Domin Software?

В историческом проекте HUB.ITM.PL мы создали систему, которая читала данные из разных бухгалтерских программ и преобразовывала их в формат EDI++, используемый Subiekt GT и Subiekt nexo. Она сократила ручной ввод большого количества счетов в бухгалтерском бюро. Проект больше не работает в продуктивной среде, поскольку форматы и условия обмена изменились. Этот пример подтверждает опыт сопоставления нескольких источников, но не обещает совместимости с текущими версиями программ.

В проекте HUB-2-API система импортировала большой список товаров из таблицы и использовала его для предложений eBay.de, заказов и API для трёх клиентов из Франции. Это был поток товаров и заказов, а не миграция клиентов из старой CRM. Пример всё же показывает, почему перед автоматизацией необходимо знать структуру источника и правила целевой системы.

В обоих случаях значение данных и способ проверки были важнее самого формата файла.

Частые вопросы

Достаточно ли экспорта из Excel или CSV?

Обычно нет. Он может содержать основные поля, но связи, заметки, историю, вложения, справочники и идентификаторы нужно проверять отдельно.

Нужно ли переносить все данные из старой CRM?

Не всегда. Часть сведений может остаться в согласованном архиве, а в новую систему переходят данные для текущей работы. Решение утверждают владельцы данных и процесса.

Как находить дубликаты клиентов и контактов?

Сначала определите признаки, которые подтверждают дубликат, и способ сохранения истории. Похожее название, общий e-mail или телефон не всегда позволяют автоматически объединить записи.

Что делать с пропущенными или противоречивыми значениями?

Для каждого важного поля задайте правило. Значение можно отметить для проверки, оставить пустым или преобразовать по утверждённому справочнику. Система не должна придумывать сведения.

Можно ли сохранить заметки, историю и вложения?

Иногда да, но это зависит от экспорта, API, структуры файлов и возможностей импорта целевой системы. Возможность нужно проверить до согласования объёма.

Как проверить тестовый импорт?

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

Можно ли выполнить миграцию без остановки компании?

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

Как безопасно передать пример для оценки?

Начните с описания структуры и синтетического или анонимизированного примера. Не отправляйте через обычную форму пароли, ключи, полную базу или реальные данные клиентов.

Выберите следующий шаг

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

Если процесс уже известен и требуется решение под компанию, посмотрите CRM- и ERP-системы на заказ. Объём и стоимость миграции определяются после проверки источников, связей, количества данных и возможностей целевой системы.

Если старая и новая системы должны работать параллельно или регулярно обмениваться данными, используйте планировщик интеграции систем и ознакомьтесь с услугой интеграции систем и API. Разовая миграция и постоянная интеграция являются разными проектами.

Источники

• RFC 4180: Common Format and MIME Type for Comma-Separated Values (CSV) Files, RFC Editor, дата проверки 30.10.2026.