Миграция из PipeDrive в amoCRM с настройкой сложных процессов

Перед нами была поставлена задача провести импорт данных об организациях, людях, задачах и примечаниях по ним из Pipedrive в amoCRM. Первым делом мы провели анализ аккаунтов клиента в Pipedrive и amoCRM. В целом, сущности Pipedrive соответствуют их аналогам в amoCRM. Так, организации соответствовали компаниям, персоны — контактам, заметки — примечаниям, активности — задачам.

Сергей Лебедев хотел, чтобы мы не просто идеально перенесли базу, но:

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

Например, заполняя Pipedrive, менеджеры часто писали в одно и то же поле разную информацию. Так, в организации N некое поле заполнялось электронной почтой организации, а в организации Z аналогичное было заполнено web-адресом организации. В amoCRM мы должны были добавить электронный адрес организации в поле email, а web-адрес — в соответствующее поле компании.

В Pipedrive информация о контактах была представлена как в персонах, привязанных к организации, так и в группе полей этой организации. Все это привело нас к необходимости сопоставления не только полей (телефон-телефон), но и типа данных в поле Pipedrive и поля в amoCRM. То есть, если в любом поле указать email, то он добавится в соответствующее поле. Мы сопоставляли группы полей в Pipedrive и сущности в amoCRM (контактное лицо из поля в сущность «Добавить контакт»), комбинации значений в нескольких текстовых полях сущности в Pipedrive и значений полей типа «список» и «мультисписок» в amoCRM.
Благодаря такому сочетанию импорта и одновременной коррекции данных было произведено несколько десятков тестовых импортов (обычно брались 50 организаций). Мы с клиентом анализировали корректность их результатов.

Когда все моменты были окончательно согласованы, мы приступили к итоговому импорту. Импорт проходил в нерабочее время клиента, чтобы не вносить дополнительных трудностей в работу и добиться актуальности данных в аккаунте amoCRM.

Логика работы скрипта заключалась в следующей последовательности действий:

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

1. импортируем 300 организаций
2. этим добавленным в amoCRM компаниям добавляем связанные с ними контакты, задачи и примечания;
3. если остались неимпортированные компании, то возвращаемся на шаг 1;
4. импортируем по 300 штук те персоны и связанную с ними информацию, которые не относятся ни к одной организации.

Естественно, и контакты, и компании, и примечания, и задачи добавлялись в amoCRM пакетами, в количестве 450 штук за один раз, иначе импорт занял бы слишком много времени. Для этого мы добавили 300 организаций — получили их уникальные идентификаторы в amoCRM. Далее выбрали задачи, которые относились к этим организациям, установили им соответствующие element_id. Если задач было больше 450, то разбивали их на порции по 450 и добавляли их в amoCRM. С другими сущностями мы проводили аналогичные операции.

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

Проблема усложнялась тем, что возможность получить информацию об определенном количестве элементов определялась объемом содержащейся информации по этим элементам. Например, если у группы организаций кастомные поля были не заполнены, то за один запрос можно было получить и 400, и 500 таких организаций. Однако если большая часть кастомных полей была заполнена, тогда в ответ на запрос информации по 300 организациям приходила ошибка серии 5xx. Поэтому мы пришли к выводу, что за один раз можно получать не более 100 персон или организаций, а примечаний и задач — по 300.

При загрузке данных в amoCRM скрипт «запоминал» номера порций данных по каждому типу сущностей, которые были успешно добавлены в amoCRM. Если бы при добавлении данных возникли технические проблемы, то после их устранения нам было достаточно еще раз запустить скрипт импорта. При этом не пришлось беспокоиться, что какая-то информация будет продублирована в amoCRM. Потому что при каждом последующем запуске скрипт начинал с того места, на котором он остановился в последний раз.

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

В итоге импорт нескольких десятков тысяч контрагентов прошел успешно. Клиент уже на следующий день приступил к работе в аккаунте amoCRM.