Решение о переезде принято, и почти сразу возникает главный страх: потерять базу. Не всю целиком — такое случается редко. Гораздо чаще теряется то, что делает базу рабочей: история переписки, привязка файлов к сделкам, комментарии менеджеров, даты касаний. Формально данные перенесены, а работать с ними невозможно.
Переход с amoCRM на Битрикс24 — это не выгрузка одного файла и загрузка его в другую систему. Это проект с подготовкой, порядком действий и обязательной сверкой. Ниже разбираем, что переносится технически, что переносить бессмысленно, в какой последовательности вести миграцию CRM и как проверить результат до того, как старую систему отключат.
Главное заблуждение: перенести структуру «как было»
Самый частый запрос при миграции звучит так: «сделайте всё точно так же, как у нас в amoCRM». Логика понятна — команда привыкла, не хочется переучиваться. Но это решение почти всегда приводит к переделке через несколько месяцев.
Причина в том, что структура amoCRM отражает ограничения amoCRM. Если в системе не было отдельной сущности под монтажи, компания вела их дополнительными полями в сделке или отдельной воронкой с искусственными стадиями. Перенеся эту схему в Битрикс24, вы переносите вместе с ней и костыль, хотя в новой системе для этого есть смарт-процесс.
Практическое правило: данные переносим, структуру проектируем заново. Клиенты, сделки и история — это факты, они должны сохраниться. Воронки, поля и автоматизация — это решения, и они пересматриваются под возможности новой платформы.
Что переносится, а что нет
| Данные | Переносится | Комментарий |
|---|---|---|
| Контакты и компании | Да | Базовые поля переносятся штатно, пользовательские — с сопоставлением вручную |
| Сделки с суммами и датами | Да | Требуется сопоставление этапов старой и новой воронки |
| Связи между сущностями | Да, при правильном порядке | Ключевой риск: при неверной последовательности сделки теряют привязку к клиентам |
| Примечания и комментарии | Да, через API | Через файловую выгрузку обычно не выгружаются |
| Файлы и вложения | Да, через API | Самый трудоёмкий этап при большом объёме |
| История переписки в мессенджерах | Частично | Зависит от сервиса-коннектора; уточняется у вендора до старта |
| Записи звонков | Частично | Часто хранятся у оператора телефонии, а не в CRM |
| Задачи | Открытые — да | Закрытые обычно переносить нецелесообразно |
| Теги и сегменты | Да | Хороший момент для чистки: часть тегов утратила смысл |
| Настройки Digital Pipeline | Нет | Автоматизация проектируется заново на роботах и триггерах |
| Виджеты и интеграции | Нет | Подключаются штатными средствами новой системы |
| Отчёты и аналитика | Нет | Строятся заново; исторические данные при этом сохраняются |
| Системные ID записей | Нет | Сохраняются в отдельном поле как ссылка на старую систему |
Последний пункт недооценивают, а он экономит недели споров. Записав старый идентификатор в пользовательское поле, вы получаете возможность в любой момент сверить запись с архивом amoCRM и ответить на вопрос «а куда делась эта сделка».
Этап 1. Аудит и чистка базы до переноса
Переносить базу в текущем виде — почти всегда ошибка. Миграция не улучшает качество данных, она его тиражирует, а заодно и легитимизирует: в новой системе мусор выглядит как достоверная информация.
До начала работ имеет смысл пройти пять шагов.
- Оценить объём. Сколько контактов, компаний, сделок, сколько из них закрыто и как давно. Часто выясняется, что 60% базы — сделки трёхлетней давности без перспектив.
- Найти дубли. Один клиент с тремя карточками, созданными разными менеджерами из разных каналов. В новой системе это превратится в три конфликтующие записи и три истории общения.
- Проверить обязательные данные. Записи без телефона и почты не подлежат обработке и не имеют ценности — их место в архиве, а не в рабочей базе.
- Ревизовать пользовательские поля. Практически в любой системе, проработавшей два-три года, накапливаются поля, заполненные у 5% записей. Переносить их не нужно.
- Решить судьбу архива. Определите горизонт: активные сделки и клиенты последних двух лет переносятся в рабочую базу, остальное — отдельным архивным массивом или остаётся в выгрузке.
Подходы к нормализации данных мы подробно описывали в материале о том, как перенести клиентскую базу из Excel в Битрикс24 — техника чистки в обоих случаях одна и та же, различается только источник.
Этап 2. Проектирование структуры в Битрикс24
Прежде чем что-то загружать, в новой системе должно существовать место, куда данные лягут.
Пользователи и права доступа
Создаются первыми. Если ответственных сотрудников нет в системе, сделки приедут либо на администратора, либо вообще без владельца — и потом придётся переназначать вручную по нескольку сотен записей.
Воронки и сопоставление этапов
Составляется таблица соответствия: каждый статус amoCRM получает стадию в новой воронке. Здесь же принимаются решения о пересмотре: если в старой системе было двенадцать стадий, из которых четыре означали одно и то же, объединяем.
Пользовательские поля
Создаются с нужными типами данных. Типичная ошибка — перенести число или дату в текстовое поле: данные встанут, а фильтры и отчёты по ним работать не будут.
Смарт-процессы
Если часть работы велась в виде «фиктивных» воронок или полей — монтаж, сервис, согласование, реестр счетов, — под них создаются отдельные сущности. Именно на этом шаге переезд начинает давать эффект, а не просто меняет интерфейс.
Этап 3. Порядок переноса
Последовательность здесь не рекомендация, а требование: связи между записями создаются в момент загрузки, и нарушение порядка означает потерю привязок.
- Пользователи. Все ответственные сотрудники уже в системе.
- Компании. Юридические лица, к которым потом привяжутся контакты и сделки.
- Контакты. С привязкой к компаниям.
- Сделки. С привязкой к контактам, компаниям, ответственным и с сохранением исходных дат создания и закрытия.
- Примечания и комментарии. Привязываются к уже существующим записям.
- Файлы. Самый долгий шаг; при большом объёме выполняется пакетами.
- Открытые задачи. С сохранением сроков и ответственных.
- Переписка и звонки. В том объёме, который технически доступен.
Отдельно про даты: если при загрузке не передать исходные даты создания, все сделки получат сегодняшнее число. Формально база на месте, но вся аналитика по динамике продаж, длительности цикла и сезонности обнулена. Восстановить это потом можно только повторной миграцией.
Технические способы миграции
| Способ | Когда подходит | Ограничения |
|---|---|---|
| Выгрузка в файл и импорт | Небольшая база, простая структура, нет требований к истории | Не переносит примечания, файлы, переписку; связи создаются вручную |
| Перенос через API обеих систем | Большинство проектов: нужна история, файлы, сохранение связей и дат | Требует разработки и тестирования на выборке |
| Готовые решения для миграции | Типовая структура без кастомизации | Плохо справляются с нестандартными полями и логикой виджетов |
| Комбинированный подход | Практика большинства реальных проектов | Основной массив через API, справочники и мелкие сущности файлами |
Независимо от способа действует одно правило: сначала тестовая миграция на выборке из 50–100 записей. Проверяются типы полей, кодировка, формат телефонов, привязки, даты. Только после успешной проверки запускается полный перенос.
Этап 4. Параллельный период
Отключать старую систему в день запуска новой не нужно. Разумная схема выглядит так.
- Неделя 1. Новые сделки создаются только в Битрикс24. Старые активные сделки продолжают вестись в amoCRM до закрытия либо переносятся вручную небольшими партиями.
- Недели 2–3. Вся работа в новой системе. amoCRM доступна в режиме чтения — для сверки и поиска старой информации.
- Неделя 4. Финальная сверка, выгрузка полного архива в файлы, отключение подписки.
Ключевое условие: параллельный период — это не работа в двух системах одновременно. Как только менеджеры получают возможность вести сделки там, где привычнее, появляются два источника правды, и данные расходятся необратимо. Старая система нужна только для чтения.
И до отключения обязательно сделайте полную выгрузку архива в файлы. После прекращения подписки доступ к данным исчезает, а необходимость что-то уточнить возникает ещё месяцами.
Чек-лист сверки после переноса
Проверка по количеству записей — недостаточная проверка. Совпадение цифр не означает корректность данных.
- Количество контактов, компаний и сделок совпадает с ожидаемым после чистки.
- Сумма по открытым сделкам в новой системе равна сумме в старой.
- Распределение сделок по стадиям соответствует таблице сопоставления.
- У всех сделок есть ответственный, и это тот же сотрудник, что и раньше.
- Даты создания и закрытия сохранены — проверьте выборочно самые старые записи.
- Выборочно по 10–15 карточкам: контакт связан с компанией, сделка связана с контактом.
- Файлы открываются, а не просто присутствуют в виде ссылок.
- Примечания сохранили авторство и хронологию.
- Телефоны в едином формате, работает поиск по номеру.
- Дубли не появились повторно при загрузке.
- Пользовательские поля имеют правильный тип: фильтры и сортировка работают.
- Отчёты по историческим данным строятся и дают осмысленные цифры.
Пункт 12 — финальная проверка качества миграции. Если отчёт за прошлый год строится и совпадает с тем, что компания знала о своих продажах, перенос выполнен корректно.
Пять ошибок, которые обходятся дороже всего
- Начать с загрузки, а не с проектирования. Данные приезжают в неподготовленную структуру, поля создаются на ходу, через месяц систему пересобирают.
- Перенести всё без разбора. Пятилетний архив мёртвых сделок и дубли переезжают вместе с рабочей базой и мешают ей.
- Не сохранить старые идентификаторы. Любой спор о судьбе конкретной сделки превращается в ручное расследование.
- Забыть про даты. Самая обидная ошибка: восстановление требует повторной миграции.
- Пропустить обучение команды. Данные перенесены идеально, но менеджеры продолжают работать в блокнотах, потому что им не показали, как работать в новой системе. О причинах такого сопротивления мы писали в статье «Почему менеджеры не работают в CRM».
Как это выглядит на практике
В проекте переезда из amoCRM в Битрикс24 для компании Barte Gold задача не сводилась к переносу данных. Компания изготавливает корпоративные ювелирные изделия на заказ, и в прежней системе не хватало автоматизации: продажи велись в CRM, а производственный цикл — за её пределами.
Поэтому работа шла в два слоя: миграция базы с сохранением истории и одновременное проектирование новой структуры под связку продаж и производства — воронки, карточки, телефония, мессенджеры. Результат переезда измеряется не тем, что данные доехали, а тем, что процессы, ранее жившие в файлах, оказались внутри системы.
Частые вопросы
Сколько времени занимает миграция?
Технический перенос базы среднего размера — от нескольких часов до двух-трёх дней с учётом файлов. Но сам перенос занимает меньшую часть проекта: основное время уходит на аудит, чистку, проектирование структуры и сверку. В сумме переезд с настройкой новой системы обычно укладывается в три-шесть недель.
Остановятся ли продажи на время переноса?
Нет, если соблюдён порядок: настройка и тестовая миграция выполняются, пока команда работает в старой системе, а переключение происходит в один день. Параллельный период страхует от потерь.
Можно ли перенести переписку из WhatsApp и Telegram?
Зависит от сервиса, через который подключены мессенджеры. В части случаев история привязана к номеру и подтягивается после подключения канала к новой CRM, в части — остаётся в интерфейсе сервиса. Это нужно выяснить у вендора до начала переезда, а не после.
Что делать с записями звонков?
Чаще всего они хранятся на стороне оператора телефонии, а в CRM лежат только ссылки. При смене системы имеет смысл выгрузить архив записей отдельно и договориться с оператором о сроках хранения.
Стоит ли переносить закрытые сделки?
Да, но осознанно. Закрытые сделки — это основа исторической аналитики: конверсия, длительность цикла, сезонность, повторные продажи. Без них новая система первые месяцы будет «слепой». Разумный горизонт — два-три года, остальное в архив.
Можно ли сделать миграцию самостоятельно?
Файловый импорт небольшой базы — вполне. Перенос с историей, файлами и сохранением связей требует работы с API обеих систем и тестирования: цена ошибки здесь измеряется не часами, а потерянными данными, которые не всегда можно восстановить.
Что делать дальше
Переезд с amoCRM оправдан только тогда, когда вместе с данными в новую систему переходят процессы, которые раньше в неё не помещались. Иначе меняется интерфейс, а не управляемость.
Поэтому мы начинаем не с выгрузки базы, а с диагностики: смотрим, что происходит после закрытия сделки, где данные живут вне CRM и какие связи важно сохранить. Только после этого проектируем структуру и планируем миграцию — так система работает и через год, а не только в день переключения.
Посмотрите, как устроено комплексное внедрение Битрикс24, изучите наши кейсы или запишитесь на консультацию — оценим объём вашей базы и составим план переезда.
