Миграция из другой CRM

Не только Битрикс24 и amoCRM. В RetailCRM переезжают с Мегаплана, Kommo, самописных систем, 1С и обычных таблиц Excel. Модель источника всегда разная, но алгоритм миграции — один. Разберём универсальный сценарий, который работает для любой исходной CRM.

Аудит исходных данных

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

• Инвентаризация сущностей: клиенты, заказы/сделки, товары, история, задачи.
• Оценка качества: дубли, пустые поля, кривые телефоны, битые кодировки.
• Отсечение балласта: устаревшие лиды, тестовые записи, ненужные поля.

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

Способы выгрузки из источника

Каким бы ни был источник, данные достают одним из трёх путей. Выбор зависит от объёма и наличия API.

Для 1С и учётных систем часто используют промежуточную выгрузку в CSV или обмен через типовые механизмы. Главное — получить данные в структурированном виде, пригодном для маппинга.

Маппинг сущностей и статусов

Ядро миграции — таблица соответствия полей источника полям RetailCRM. Её составляют до переноса и согласовывают с заказчиком.

1. Сущности: контакт → клиент, компания → корпоративный клиент, сделка/заказ → заказ.
2. Статусы: этапы источника → группы статусов RetailCRM (новый, согласование, доставка, выполнен, отменён).
3. Поля: телефон, email, суммы, даты, ответственные, пользовательские поля.

Порядок и слои переноса

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

1. Настройка RetailCRM: статусы, поля, источники, права.
2. Каталог товаров.
3. Клиенты и компании.
4. Заказы со ссылками на клиентов и товары.
5. История, задачи, коммуникации.

Нарушение порядка — частая причина «висящих» заказов без клиента и позиций без товара. Каждый слой проверяют перед переходом к следующему.

Тестовый и боевой перенос

Миграцию делают в два прохода. Сначала тестовый — на демо-аккаунте или копии, чтобы поймать ошибки маппinga и кодировки. Затем боевой — с фиксацией даты среза, после которой в старой системе новые данные не заводят.

• На тесте проверяют выборку записей «руками» и сверяют контрольные суммы.
• Между тестом и боем правят маппинг и чистят данные.
• Боевой перенос проводят в согласованное окно, желательно в нерабочее время.

Приёмка и критерии успеха

Успех миграции нужно уметь измерить. Договоритесь о критериях заранее и проверьте их после боевого переноса.

• Совпадение количества клиентов, заказов и товаров с исходником.
• Сходимость сумм выручки за контрольный период (допуск 1–2%).
• Целостность связей: заказ → клиент, позиция → товар.
• Наличие истории и ответственных у выборочных записей.

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

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

Итог

Откуда бы вы ни переезжали, сценарий один: аудит данных, выгрузка, таблица маппинга сущностей и статусов, перенос слоями «справочники → клиенты → заказы → история», тест и боевой прогон с приёмкой по чётким критериям. Ключ externalId связывает старое и новое и защищает от дублей.

Мы переносили в RetailCRM данные из самых разных систем и таблиц. Проведём аудит, согласуем маппинг и выполним миграцию без потерь — с тестовым прогоном и проверкой целостности.