Миграция Битрикс24 из облака в коробку — этапы, риски и ограничения | NJ Soft

Миграция Битрикс24 из облака в коробку: как перенести данные без потерь

Когда компания решает сменить CRM, корпоративный портал или другую ключевую систему, задача часто звучит deceptively просто:

«Нужно перенести все данные из старой системы в новую».

Иногда к этому добавляется оптимистичное: «Давайте сделаем на выходных, чтобы в понедельник сотрудники уже работали».

Если речь идёт о нескольких сотнях клиентов и одном Excel-файле, такой сценарий действительно возможен. Но для живой корпоративной системы с десятками типов данных, пользовательскими полями, файлами, историей, интеграциями и сотнями тысяч объектов миграция — это отдельный ИТ-проект.

В этой статье разберём процесс на примере реального класса задач, с которыми мы работаем в NJ Soft: перенос Битрикс24 из облачной версии в коробочную.

Конкретные технологии у разных систем будут отличаться, но основные проблемы практически всегда одинаковы — независимо от того, переносите вы Битрикс24, CRM другого вендора или данные из самописной системы.

Содержание

Почему нельзя просто «выгрузить и загрузить»
Порядок переноса определяется зависимостями
До написания скриптов нужен аудит
Ограничения API могут определить весь проект
Миграционный скрипт обязательно должен уметь падать
API показывает не всё, что сотрудники видят в интерфейсе
Почему импорт через REST тоже может оказаться ошибкой
Повторный импорт не должен создавать дубли
Что действительно нельзя перенести один в один
«Вроде всё перенеслось» — не этап приёмки
Один процент — это не «небольшая погрешность»
Нужно ли останавливать работу компании на неделю
Как выглядит само переключение
Сколько занимает реальная миграция
Где можно сократить бюджет, а где нельзя
Как понять, что подрядчик правильно подходит к миграции
Главный принцип миграции

Почему нельзя просто «выгрузить и загрузить»

Представим CRM, в которой есть сделка.

На первый взгляд это одна запись: название, сумма, дата, статус.

В реальности сделка может быть связана:

с контактом;
с компанией;
с ответственным сотрудником;
с определённой воронкой и стадией;
с товарами;
с задачами;
со звонками и письмами;
с комментариями;
с пользовательскими полями;
с файлами;
с другими объектами CRM.

При обычном экспорте в таблицу значительная часть этой структуры либо вообще исчезает, либо превращается в набор идентификаторов, которые в новой системе уже ничего не значат.

Например, в старом портале сотрудник имел ID 173, компания — ID 8412, а сделка — ID 19534.

После создания сотрудников и компаний в новой системе их идентификаторы станут другими. Если просто импортировать сделку со старым COMPANY_ID=8412, она окажется без компании или, что хуже, будет привязана совсем не к той записи.

Поэтому нормальная миграция выглядит не так:

старая система → новая система

а так:

источник → промежуточное хранилище → преобразование → приёмник

Мы сначала выгружаем данные в собственное промежуточное хранилище — staging. Там они становятся независимыми от доступности исходной системы и её API.

Отдельно формируется таблица соответствий идентификаторов.

Условно:

Тип объекта	Старый ID	Новый ID
Пользователь	173	48
Компания	8412	12604
Сделка	19534	28711

И уже через эту таблицу восстанавливаются связи.

Это одна из фундаментальных частей любой сложной миграции.

Порядок переноса определяется зависимостями

Данные нельзя переносить в произвольном порядке.

Нельзя корректно создать сделку с ответственным сотрудником, если сотрудники ещё не перенесены. Нельзя назначить ей стадию, если воронки и стадии ещё не созданы. Нельзя восстановить связь с компанией, если компания ещё не существует в новой системе.

Поэтому миграция обычно идёт слоями.

Например:

пользователи и структура компании;
справочники, пользовательские поля, воронки и стадии;
компании и контакты;
лиды, сделки и другие CRM-сущности;
товары;
связи между объектами;
задачи, активности и история;
файлы;
автоматизация и интеграции.

В конкретной системе порядок будет другим, но общий принцип сохраняется:

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

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

До написания скриптов нужен аудит

Одна из самых дорогих ошибок в миграции — сразу начать программировать.

До разработки нужно ответить на гораздо более скучные вопросы:

какие сущности вообще есть в системе;
сколько объектов каждого типа;
какие используются пользовательские поля;
какие поля действительно заполнены;
какие бизнес-процессы работают;
какие приложения установлены;
какие внешние системы подключены;
где хранятся файлы;
какие данные доступны через API;
какие данные через API получить невозможно.

Результатом должен стать не список задач разработчику, а карта миграции.

Для каждой категории данных в ней фиксируется:

что переносим → откуда получаем → куда записываем → как преобразуем → как проверяем результат.

Не менее важна отдельная колонка:

«Не переносится».

Её наличие — хороший признак, а не плохой.

У сложной корпоративной системы почти всегда есть данные, которые технически невозможно автоматически перенести один в один.

Гораздо опаснее обещание:

«Не волнуйтесь, перенесём вообще всё».

Вопрос обычно не в том, существуют ли ограничения, а в том, когда заказчик о них узнает: во время аудита или за два дня до запуска.

Ограничения API могут определить весь проект

При миграции из SaaS-системы мы контролируем только одну сторону.

Мы не можем зайти непосредственно в её базу данных. Данные можно получать тем способом, который разрешил разработчик платформы.

В случае облачного Битрикс24 основной инструмент для подобных задач — REST API.

И здесь начинается инженерная часть миграции.

API не работает с бесконечной скоростью

У API есть ограничения по интенсивности запросов и ресурсоёмкости методов.

Поэтому скрипт в стиле:

получить запись
получить следующую запись
получить следующую запись
...

на больших объёмах работает неприемлемо долго.

У Битрикс24 существуют пакетные запросы batch, позволяющие выполнить до 50 команд в рамках одного HTTP-запроса.

Но даже пакетные запросы сами по себе проблему не решают.

Для больших списков важна и правильная пагинация.

Обычный подход со смещением:

start=0
start=50
start=100
start=150
...

по мере роста массива может создавать лишнюю нагрузку.

Для больших выгрузок Битрикс24 рекомендует идти по стабильному идентификатору: запрашивать записи с ID больше последнего полученного и отключать расчёт общего количества записей через start=-1.

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

Для сотен тысяч — уже принципиальна.

Миграционный скрипт обязательно должен уметь падать

Звучит странно, но надёжный инструмент миграции проектируется с предположением, что он обязательно когда-нибудь упадёт.

Причиной может стать:

временная ошибка API;
потеря соединения;
перезапуск сервера;
rate limit;
повреждённая запись;
неожиданное значение поля;
недоступный файл.

Если экспорт 300 000 объектов выполнялся несколько часов и на объекте №287 416 произошла ошибка, начинать всё заново — плохая архитектура.

Поэтому миграционные инструменты должны иметь:

чекпоинты;
журнал операций;
повторные попытки;
обработку временных ошибок;
возможность продолжить работу с последнего успешно обработанного объекта.

То же самое касается импорта.

Это не дополнительная «перестраховка». На больших объёмах это базовое требование.

API показывает не всё, что сотрудники видят в интерфейсе

Ещё одна распространённая ошибка — посмотреть документацию API, увидеть нужное название сущности и решить, что вопрос закрыт.

На практике доступность данных нужно проверять экспериментально.

Мы берём тестовую выборку реальных объектов и для каждого типа данных отвечаем на три вопроса:

Что сотрудник видит в интерфейсе?
Что реально возвращает API?
Можно ли создать эквивалентный объект в новой системе?

Это особенно важно для истории, чатов, служебных полей, автоматизации и интеграций.

Причём ограничения меняются.

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

Почему импорт через REST тоже может оказаться ошибкой

Предположим, данные успешно выгружены.

Возникает естественное решение: раз получили их через REST API, через REST же загрузим обратно.

Для миграции CRM это иногда приводит к неприятному результату.

Типичный публичный API позволяет создать сделку, но не позволяет полностью воспроизвести её внутреннюю историю.

В результате сделка, реально созданная сотрудником в 2021 году, после миграции может оказаться объектом:

«Создан сегодня пользователем Migration Bot».

Если таких объектов 100 тысяч, это уже не косметическая проблема.

Меняется аналитика по периодам, история работы сотрудников и часть управленческой отчётности.

Коробочная версия даёт другое преимущество

При переходе на систему, расположенную на собственном сервере, у нас появляется доступ к внутренним механизмам платформы.

В случае коробочного Битрикс24 часть данных целесообразнее импортировать через внутренний API ядра, а не через внешний REST.

Это позволяет значительно точнее восстанавливать:

исходные даты;
авторов;
ответственных;
служебные параметры;
связи между сущностями.

Именно поэтому архитектура импорта не обязана зеркально повторять архитектуру экспорта.

Получать данные можно одним способом, а создавать их — другим.

Повторный импорт не должен создавать дубли

Есть ещё одно важное свойство хорошей миграционной системы — идемпотентность.

Если импорт был остановлен после 80 000 сделок и запущен повторно, система не должна создать вторые 80 000.

Перед созданием объекта импортёр проверяет таблицу соответствий:

объект со старым ID уже перенесён?

Если да — он либо пропускается, либо обновляется.

Это позволяет безопасно:

перезапускать импорт;
переносить отдельные сущности повторно;
исправлять алгоритм и догружать данные;
выполнять финальную дельта-синхронизацию.

Без этого каждый сбой превращается в ручной поиск дублей.

Что действительно нельзя перенести один в один

Хорошая миграция — это не проект, в котором подрядчик каким-то чудом перенёс абсолютно всё.

Хорошая миграция — это проект, в котором до начала работ известно, что переносим автоматически, что переносим вручную, что настраиваем заново, а что оставляем в архиве.

На примере Битрикс24 есть несколько характерных категорий.

Личные переписки сотрудников

История личных чатов имеет ограничения доступа. Администратор системы не превращается автоматически в участника всех личных переписок сотрудников.

Если необходимые сообщения невозможно получить через доступные интерфейсы, разумный вариант — не имитировать перенос, а сохранить старый портал как архив с доступом только для чтения.

Подключённые почтовые ящики

Пароли, OAuth-токены и другие секреты интеграций обычно намеренно не выдаются через API.

Это вопрос безопасности.

Поэтому почтовые ящики после миграции подключаются заново.

При этом сами письма не исчезают: если почта работает через внешний почтовый сервер, оригиналы сообщений продолжают храниться там.

Запущенные бизнес-процессы

Шаблон процесса и конкретный запущенный экземпляр — разные вещи.

Перенести описание процесса зачастую можно. «Телепортировать» процесс, который сейчас находится между третьим и четвёртым шагом согласования, значительно сложнее или невозможно.

Поэтому перед переключением активные процессы желательно завершить либо отдельно определить, как с ними поступать.

Приложения, телефония и внешние коннекторы

Marketplace-приложение — это не только запись в базе данных.

У него могут быть собственные:

OAuth-ключи;
серверы;
вебхуки;
настройки;
права;
внешние аккаунты.

Поэтому подобные интеграции обычно переустанавливаются и настраиваются заново.

То же касается телефонии, социальных сетей и части внешних сервисов.

«Вроде всё перенеслось» — не этап приёмки

После импорта начинается одна из самых важных частей проекта — сверка.

Недостаточно открыть несколько сделок и убедиться, что интерфейс выглядит знакомо.

Первый уровень контроля — количественный.

Например:

Показатель	Источник	Приёмник
Компании	47 821	47 821
Контакты	82 416	82 416
Сделки, воронка №1	63 102	63 102
Сделки, воронка №2	18 934	18 934

Но одних счётчиков тоже мало.

Если одна сделка потерялась, а вместо неё случайно появился дубль другой, количество совпадёт.

Поэтому добавляются контрольные показатели:

сумма сделок по воронкам;
количество объектов по стадиям;
распределение по годам;
количество файлов;
количество связей определённых типов.

После этого выполняется выборочная ручная проверка.

Например, выбираются сделки разных лет и разных воронок и проверяются:

контакт;
компания;
ответственный;
дата;
пользовательские поля;
товары;
активности;
файлы.

Так обнаруживаются ошибки, которые невозможно заметить по общему счётчику.

Один процент — это не «небольшая погрешность»

Когда объектов мало, фраза «перенеслось 99%» звучит неплохо.

На корпоративных объёмах математика другая.

Если было 100 000 объектов, 1% — это 1 000 потерянных записей.

Среди них вполне могут оказаться:

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

Поэтому «почти всё перенеслось» не является критерием успешной миграции.

Все расхождения должны либо исправляться, либо иметь документированное объяснение.

Нужно ли останавливать работу компании на неделю

Нет.

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

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

Допустим, основной прогон был выполнен в воскресенье, а переключение запланировано на следующую субботу.

За неделю сотрудники успели:

создать новые сделки;
изменить старые;
добавить контакты;
выполнить задачи;
загрузить файлы.

В день переключения нет смысла снова переносить весь портал.

Выполняется дельта-синхронизация — переносятся новые и изменённые после предыдущего запуска объекты.

Для этого ещё при проектировании экспорта нужно хранить идентификаторы и даты модификации.

Тогда окно, в течение которого сотрудников действительно нужно попросить ничего не менять, сокращается с нескольких дней до нескольких часов.

Как выглядит само переключение

Cutover — это отдельный сценарий проекта, а не сообщение разработчика в чате «вроде закончили, можете заходить».

Заранее фиксируется:

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

После запуска старую систему обычно имеет смысл некоторое время сохранять доступной в режиме чтения.

Это даёт сотрудникам возможность проверить старые данные и снижает риски первых дней эксплуатации.

Сколько занимает реальная миграция

Здесь особенно легко получить нереалистичную оценку.

В нашем опыте полный проект миграции корпоративного портала такого класса может занимать 200 и более часов командной работы и около 2–2,5 месяца календарного времени.

Это не означает, что разработчик два с половиной месяца непрерывно копирует данные.

Примерное распределение трудозатрат выглядит так:

около 50% — разработка и отладка экспорта и импорта;
около 20% — аудит, тестирование и сверка;
оставшееся время — инфраструктура, подготовка коробочной системы, ручная настройка, интеграции, тестовые прогоны и запуск.

В проекте при этом участвует не только программист.

Обычно нужны как минимум:

разработчик;
аналитик;
менеджер проекта;
представители заказчика, которые знают реальные бизнес-процессы компании.

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

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

Где можно сократить бюджет, а где нельзя

Можно отказаться от переноса давно неиспользуемых сущностей.

Можно не автоматизировать одноразовый перенос нескольких десятков настроек и сделать его вручную.

Можно оставить часть исторических данных в архивной системе.

Но есть два этапа, экономия на которых чаще всего приводит к переделке всей миграции.

Нельзя выкидывать аудит

Если оценивать проект до изучения реальной системы, смета превращается в гадание.

«Стандартного Битрикс24» после нескольких лет эксплуатации практически не бывает.

Нельзя выкидывать сверку

Успешное выполнение скрипта ещё не означает успешную миграцию.

Программа вполне способна вывести:

Import completed successfully

после того как аккуратно импортировала неправильные данные.

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

Как понять, что подрядчик правильно подходит к миграции

До подписания договора стоит проверить несколько вещей.

Подрядчик просит доступ к системе до финальной оценки. Оценить сложную миграцию только по словам «у нас Битрикс24 на 150 сотрудников» невозможно.
До разработки появляется карта миграции. Должно быть понятно, какие сущности переносятся, куда они попадут и каким способом.
Есть письменный список ограничений. Подрядчик может объяснить не только что перенесёт, но и что перенести невозможно или нецелесообразно.
Используется промежуточное хранилище. Для большой миграции прямой скрипт «источник → приёмник» создаёт лишние риски и усложняет повторные запуски.
Предусмотрена таблица соответствий ID. Без неё сложно надёжно восстановить связи между объектами.
В смете есть тестовый прогон и сверка. Не только «загрузка данных», но и доказательство того, что они загрузились правильно.
Есть сценарий переключения и отката. Должно быть заранее понятно, что произойдёт в день запуска и что команда будет делать при критической ошибке.
Предусмотрена дельта-синхронизация. Пользователи не должны прекращать работу на неделю только потому, что идёт перенос базы.

Если вместо этого весь план состоит из фразы «напишем скрипт, выгрузим всё ночью и утром проверим», риски стоит оценить ещё раз.

Главный принцип миграции

Миграция данных — это не соревнование за максимальное количество скопированных таблиц.

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

Поэтому результат хорошей миграции выглядит не как:

«Мы перенесли 100% всего».

А скорее так:

«Мы заранее определили, что переносим автоматически, что переносим вручную, что настраиваем заново и что сохраняем в архиве. После тестового прогона данные сверены, расхождения объяснены, а переключение выполнено по заранее согласованному сценарию».

Это менее эффектное обещание.

Зато именно так обычно выглядят миграции, которые не приходится переделывать.

NJ Soft проектирует и проводит миграции данных между корпоративными системами — от первичного аудита и карты миграции до разработки инструментов переноса, тестовых прогонов, сверки и боевого переключения.

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