Переезд с Битрикс24 без потерь: чек-лист миграции

Переезд с Битрикс24 страшен не объёмом данных, а риском их потерять или задвоить. На практике всё решается картой полей, тестовой миграцией и контролем сумм. Ниже — порядок, по которому провожу миграцию.

Что переносится

• Сделки — со стадиями, суммами, датами, ответственным.
• Контакты и компании — с реквизитами и связями.
• Каталог и позиции — товары, номенклатура, цены.
• История — комментарии, переписка, задачи.
• Файлы — вложения к сделкам и контактам.

В одном проекте это составило 136 тыс. позиций, 14 384 сообщения и около 1,4 ГБ файлов — перенос занял несколько итераций без остановки работы компании.

Чек-лист миграции

1. Инвентаризация. Собрать список сущностей и полей в Битрикс24 и сопоставить с полями новой системы (карта полей).
2. Правила соответствия. Определить, как стадии воронки, типы и статусы ложатся на новую модель.
3. Тестовая миграция. Перенести часть данных и сверить вручную: суммы, даты, связи.
4. Контроль сумм. Посчитать итоги по обеим системам и добиться расхождения Δ = 0.
5. Идемпотентность. Повторный запуск синхронизации не должен создавать дубли.
6. Финальный прогон. Перенести полный объём, зафиксировать результат.
7. Отключение тарифа. Убедиться, что данные на месте, и только потом гасить подписку Битрикс24.

Контроль качества

Главный критерий приёмки — суммы совпадают. Если после миграции итог по сделкам отличается хотя бы на рубль, ищем причину до переключения. В одном из проектов переехали 26 сущностей и 2 793 сделки с Δ = 0 по суммам.

Связи между сущностями — главный риск

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

Поэтому связи я разбираю не глазами, а по коду системы. LLM-модель анализирует структуру и взаимосвязи сущностей и даёт карту соответствий, которая учитывает около 90% всех взаимосвязей в системе. Оставшиеся 10% — редкие и нестандартные случаи, которых не видно на старте. Их закрывает итеративный подход: тестовая миграция, сверка, правки, повторный прогон. Итерация за итерацией — и мы приходим к нулевому расхождению данных в двух системах (Δ = 0).

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

Кейс: amoCRM → Битрикс24, 2022

В 2022 году я переносил компанию из amoCRM в Битрикс24 — и не смог решить задачу ни штатными скриптами Битрикс24, ни собственным кодом. Сотрудники просто не смогли начать работать в новой системе: им всё было непривычно, а организация оказалась не готова терять деньги на простое. Проект остановили.

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

Частые ошибки

• переносить данные «одним скриптом» без тестового прогона;
• недооценивать связи между сущностями: ручной перенос почти всегда даёт ошибки и «сироты»;
• отключать Битрикс24 до сверки;
• терять вложения и историю переписки.

Пошаговую услугу смотрите на странице «Переезд с Битрикс24». Если хотите оценить переезд с amoCRM — там логика та же: «Переезд с amoCRM». А если сомневаетесь, стоит ли вообще уходить с коробки — начните с калькулятора стоимости за 10 лет.