Хотели перейти на другую CRM, но там 4000 контактов и сделки с 2021 года. Пришлось писать мигратор
Есть одна проблема, с которой мы постоянно сталкивались при разработке нашей системы Fluxs.
Приходит компания, смотрит возможности, пробует работать. Вроде всё устраивает. А потом выясняется, что у них в Битрикс24 несколько тысяч контактов, сделки за последние пять лет, задачи, проекты и куча другой информации.
И возникает вполне логичный вопрос:
— А всё это как переносить?
— Ну, можно выгрузить в Excel, подготовить таблицы, сопоставить поля, загрузить...
— Понятно, спасибо.
На этом разговор часто заканчивался.
И дело даже не в том, что людям не хотелось менять CRM. Просто перспектива потратить неделю на перенос данных, а потом ещё неделю исправлять ошибки, мало кого радует.
В какой-то момент решили: хватит объяснять, как правильно подготовить Excel. Надо сделать нормальный мигратор.
Что в итоге получилось
Сделали модуль, который переносит данные из Битрикс24, amoCRM, Jira, Яндекс Трекера и Confluence.
Если система другая, можно загрузить CSV, Excel или JSON.
На первый взгляд ничего особенного. Импорт из таблиц существует примерно везде.
Но интересное началось, когда стали разбираться, как люди на самом деле хранят данные.
Проблема №1. Excel — это отдельная форма жизни
В одной таблице колонка называется «Телефон».
В другой — «Мобильный».
В третьей — «Тел».
В четвёртой — «Контакт_2».
А в пятой вообще «Доп1», и попробуй догадайся, что там лежит.
Поэтому сделали автоматическое сопоставление полей. Сначала система смотрит названия колонок и синонимы. Если название непонятное, анализирует содержимое. Например, если в колонке лежат адреса электронной почты, скорее всего, это email. Даже если колонка называется «Поле 17». Для совсем странных случаев добавили кнопку «Подобрать остальное ИИ». Но тут обнаружилась другая проблема.
Проблема №2. Автоматизация тоже умеет ошибаться
Представьте: система уверенно определила все поля. Пользователь нажал «Импортировать».
Через пять минут у него три тысячи контактов, у которых вместо телефона записан ИНН.
Технически импорт прошёл успешно. Практически — поздравляем, у вас теперь новая проблема.
Поэтому добавили проверку сопоставлений. Перед переносом модуль анализирует первые 15 строк и показывает, где всё нормально, а где есть сомнения. Если больше половины значений не соответствуют формату поля, появляется ошибка. Пока критические ошибки не исправлены, полный перенос не запускается.
При этом оставили возможность принудительно перенести данные как есть. Иногда пользователь лучше системы знает, что хранится в его таблице.
Проблема №3. А если мы сейчас перенесём 10 тысяч записей и всё сломаем?
Справедливый вопрос.
Поэтому сделали пробный перенос.
Берём 20 записей, выполняем настоящий импорт, показываем результат и откатываем изменения.
В базе ничего не остаётся.
Можно посмотреть, какие карточки создались бы, как определились статусы и где возникли ошибки.
Если всё устраивает — запускаем полный перенос.
А если проблема обнаружилась уже после него, есть отдельная кнопка отката. Правда, тут без магии. Откат удаляет записи, созданные конкретным импортом, но не восстанавливает старые значения обновлённых карточек.
И созданные разделы тоже не удаляет. В них уже могут находиться другие данные.
Решили честно показывать эти ограничения, а не делать вид, что кнопка «Отменить» способна повернуть время вспять.
Проблема №4. Пока вы переезжаете, люди продолжают работать
Допустим, в понедельник перенесли все контакты и сделки.
Во вторник начали настраивать новую систему.
В среду менеджеры создали ещё 30 контактов и закрыли несколько сделок в старой CRM.
В четверг кто-то поменял статусы задач.
А в пятницу пора окончательно переезжать.
Что делать? Переносить всё заново? Для этого сделали доимпорт.
Система запоминает идентификаторы записей и при повторном переносе не создаёт дубли. А для Битрикс24, amoCRM, Jira и Яндекс Трекера можно отдельно загрузить изменения, произошедшие после предыдущего импорта. Получается, что основную базу можно перенести заранее, а в день перехода догрузить изменения.
Отдельное приключение — Confluence
Казалось бы, что сложного в переносе статей? Берём текст, картинки, заголовки и переносим.
Но у Confluence собственная разметка и макросы. И некоторые из них просто некуда переносить.
Например, встроенные задачи Jira, отдельные схемы или оглавления.
Можно было молча удалять неподдерживаемые элементы. Но тогда человек откроет статью через полгода и будет гадать, куда пропала половина инструкции.
Поэтому сделали иначе.
Если элемент не удалось перенести, оставляем заметную пометку:
«[В Confluence здесь было: оглавление страницы]»
Не идеально, зато понятно, что именно нужно восстановить.
Что пока не получилось
Чтобы пост не выглядел как рекламный буклет, сразу расскажу об ограничениях. Вложения и файлы пока не переносим.
Комментарии из таймлайна Битрикс24 и задач Jira — тоже. Историю смены этапов сделок пока не сохраняем. Переносится только текущий этап. Это довольно большой объём работы, который ещё предстоит сделать.
И ещё один момент
Импорт из Excel, CSV и JSON решили оставить бесплатным, в том числе на бесплатном тарифе.
Прямые подключения через API доступны на платных тарифах.
И сделали обратный экспорт данных из Fluxs.
Потому что было бы довольно странно написать инструмент для освобождения людей из чужих CRM, а потом не дать им нормально выгрузить данные из нашей.
В общем, начинали с задачи «сделать импорт контактов», а в итоге получили отдельный модуль с проверками, пробным переносом, откатом, ИИ и доимпортом.
Теперь интересно мнение тех, кто реально переезжал между CRM.
Какая самая неприятная проблема встречалась вам при переносе данных?
У нас пока лидируют таблицы, в которых название колонки вообще никак не связано с её содержимым.
Кто-нибудь вообще встречал CRM, из которой можно нормально выгрузить все данные с первого раза? Или это уже из области фантастики?










