Переезд с облачного Битрикс24 на коробку: как мы перенесли 2 ТБ данных и не остановили работу компании
Алексей Мартынов
Когда к нам обратился клиент с запросом на миграцию с облачного Битрикс24 на коробочную версию, мы восприняли это как интересный профессиональный вызов. Наша команда имеет многолетний опыт работы с Битрикс24, но такой проект нам предстояло выполнить впервые.
Запрос клиента
К нам пришла растущая компания на 800+ сотрудников с сильной внутренней IT–командой и понятной задачей: перейти с облачного Битрикс24 на коробочную версию так, чтобы:
- cохранить ключевые процессы и историю;
- не потерять данные и связи между сущностями;
- получить свободу кастомизации и интеграций;
- сделать переход управляемым, а не "героическим".
Коробка Энтерпрайз как следующий этап развития системы
Облако Энтерпрайз несколько лет закрывало потребности нашего клиента. Но в какой–то момент приоритеты меняются, и Коробка Энтерпрайз становится логичным шагом, когда нужны:
- глубокая кастомизация под уникальные процессы;
- полный контроль над безопасностью и хранением данных;
- интеграции с внутренними системами на уровне API и базы;
- предсказуемость изменений (обновления и доработки по вашему графику).
Важно: мы не противопоставляем Облако и Коробку. Это два корректных сценария под разные этапы роста.
Облако замечательно подходит для быстрого старта и компаний, где важна скорость получения новых фич вместе с обновлениями. Коробка для тех, кто готов взять на себя больше ответственности ради полной свободы действий.
Что нужно понимать "на берегу": профессиональный подход
Первое и самое важное: не существует волшебной кнопки "Перенести все". 1С–Битрикс предоставляет инструменты для миграции, но они покрывают не все сценарии: например, REST API не позволяет перенести чаты. Это нужно принять как данность.
Наши ключевые рекомендации перед стартом:
1. Проведите детальный аудит облачного портала:
- Составьте полную карту сущностей (пользователи, сделки, задачи, чаты, файлы);
- Определите взаимосвязи между сущностями – кто от кого зависит;
- Выявите неиспользуемый функционал – его можно не мигрировать, это сэкономит до 30% времени;
- Оцените объем данных, особенно файлового хранилища (умножьте на 2–3 для запаса). Мы столкнулись с тем, что клиент не осознавал, сколько всего накопилось за годы работы – оказалось почти 2 ТБ!
2. Реалистичные ожидания вместе с клиентом – основа успешной работы:
- Заранее проговорите технические ограничения и допустимые отклонения;
- Определите вместе, что является критически важным для бизнеса здесь и сейчас;
- Согласуйте план поэтапной миграции и тестирования. Нарисуйте диаграмму, покажите этапы.
3. Запланируйте необходимые ресурсы – не только временные:
- Временной буфер на непредвиденные сложности (мы закладывали +30%);
- Инфраструктура Test, Dev стенд для отработки миграции – это обязательно;
- Резервные копии на каждом этапе – однажды это спасло нас от потери нескольких дней работы.
Техническая реализация: наш рабочий процесс
Чтобы проект был предсказуемым, мы построили собственный "движок миграции":
- консольное PHP–приложение на официальной библиотеке bitrix24/b24phpsdk;
- единая точка управления процессом (что уже перенесено, что в очереди, что упало);
- детальное логирование (ошибки, длительность этапов, статистика);
- возможность безопасно останавливать и продолжать миграцию;
- быстрые доработки под специфику клиента (например, обработка BB–кодов в задачах).
Почему это важно клиенту: когда данные большие и зависимостей много, успех определяется не только "сильным программистом", а управляемостью процесса.
Главное правило миграции: порядок решает все. В Битрикс24 сущности связаны между собой. Если переносить "как получится", вы получаете некорректные назначения, битые ссылки на файлы, потеря связи и хаос в правах.
Основные технические открытия и рекомендации – что мы узнали на практике
1. Последовательность миграции – железное правило, а не рекомендация
Мы переносили в строгой логике зависимостей, кратко по цепочке:
- пользователи и структура компании,
- файлы Диска (потому что на них ссылаются почти все: задачи, комментарии, таймлайн),
- типы смарт–процессов (как каркас),
- CRM–структура (воронки и стадии),
- пользовательские поля (до данных, иначе часть информации "не ляжет"),
- контакты и компании,
- лиды и сделки,
- группы и проекты,
- календари,
- задачи,
- элементы смарт–процессов,
- шаблоны бизнес–процессов,
- таймлайн,
- чаты.
Если нарушить порядок (например, перенести задачи раньше пользователей), в задачах будут указаны ID пользователей из облака, но на коробке эти ID будут принадлежать другим людям. Исправлять это потом дороже, чем сделать правильно сразу.
2. Сложные зоны, которые обычно недооценивают (и как мы их закрыли)
Ниже – блоки, на которых чаще всего "сыпятся" сроки и качество миграции. Мы заранее заложили их в план и сделали так, чтобы перенос был управляемым: с понятным порядком, проверками и маппингом.
Миграция пользователей и подразделений
Первым этапом необходимо перенести список пользователей. Тут важно понимать что при получении данных из облака нам не доступны важные поля, такие как: логин, пароль и данные для входа (отдельная таблица для авторизации).
Из облака можем получить только данные из профиля. Поэтому часто бывает что у пользователя пустое поле почты, а это самая основная часть данных, необходимая для авторизации на коробке. В целом каких либо сложностей нет в данном блоке. Получили данные, записали в коробку.
Добавление – да
Обновление – да
Перенос файлов и папок диска
Диск в Битрикс – это не очень сложная конструкция – по сути, это две важных таблицы в базе: таблица хранилищ `b_disk_storage` и таблица объектов диска `b_disk_object`. Хранилище содержит в себе `ROOT_OBJECT_ID` – идентификатор корневой папки хранилища.
Объекты диска – это файлы и папки, они все вместе хранятся в одной таблице, разделяются по типу и хранят в себе `PARENT_ID` – идентификатор папки, в которой расположен объект.
Вроде бы это все довольно просто, но методы REST не позволяют получить файлы и папки рекурсивно, метод "disk.folder.getchildren" возвращает объекты только первого уровня вложенности. Поэтому наш алгоритм экспорта превратился в простой перебор уровней вложенностей (их оказалось 8). Мигрировали мы их так же – по уровням.
Диск можно экспортировать с помощью приложения под админом 1, у нас с этим проблем не возникло.
Миграция типов смарт–процессов
Вторым этапом произвели миграцию всех доступных типов смарт–процессов.
Добавление – да
Обновление – нет (маппинг по заголовку)
Критичный нюанс – если на стадиях смарт–процессов висят бизнес–процессы, после переноса элементов может понадобиться запуск БП на нужной стадии. Но принудительный запуск БП способен создавать задачи. Если это не учесть, вы получите дубли задач при их миграции.
Миграция стадий и разделов CRM
Далее делаем миграцию воронок и стадий основных типов данных (сделки, лиды, справочники и т.д.).
Добавление – да
Обновление – нет (маппинг по заголовку)
Миграция инфоблоков
В данном блоке производим миграцию типов инфоблока и их элементы. Тут надо понимать что через стандартный API получить вообще все инфоблоки не получится. Вендор намеренно закрыл доступ по апи к справочникам, которые не входят в ленту бизнес–процессов. Такие инфоблоки можно перенести только штатный экспорт и импорт.
Добавление – да
Обновление – да
Миграция пользовательских полей
Здесь производим миграцию пользовательских полей для различных типов данных. Но в данной задаче есть особенность – нет какого то одного запроса, чтобы получить все данные. Для составления полного списка, необходимо для каждого типа получить свой набор данных, тем самым собрать единый массив. Например для пользователей – запрос user.userfield.list, для лидов – crm.lead.userfield.list и т.д.
Добавление – да
Обновление – нет
Миграция контактов и компаний
Наверное один из самых простых пунктов для миграции. Это выделено в один блок, т.к. имеют идентичную структуру запросов, обработки и сохранения в коробку, не имеют каких либо подводных камней.
Добавление – да
Обновление – да
Миграция лидов
Тоже относительно простая задача, но усложняется еще тем, что необходимо использовать стадии и воронки.
Добавление – да
Обновление – да
Миграция сделок
Миграция сделок очень похожа по структуре с миграцией стадий, но со своими небольшими отличиями, в частности связанные с маппингом сделок, записи на коробочную версию.
Добавление – да
Обновление – да
Миграция групп и проектов
В данном блоке происходит не только миграция групп, проектов (как открытых, так и закрытых, и приватных), но и миграция списка пользователей в этих группах.
Добавление – да
Обновление – да
Перенос календарей
События календарей можно экспортировать под админом №1, вебхуки пользователей не понадобились.
Особенность календарных событий в повторяемости – если PARENT_ID равен ID, то это базовое событие, а все, у которых PARENT_ID не равен ID – это автоматически созданные на основе базового периодически повторяемые события, их можно даже не экспортировать, потому что структура повторяемости есть в базовом событии.
Для корректной миграции необходимо использовать маппинг абсолютно всех входящих данных, будь то элементы, поля или стадии сделки. Нет маппинг – нет данных.
Для миграции необходимо использовать вебхук от первого пользователя облака (суперадмин), т.к. он не ограничен правами доступа и ему доступна абсолютно вся информация на портале (ну почти вся).
Ниже список переносимых данных, идущие по порядку то, как это должно загружаться:
Миграция задач
На первый взгляд кажется, что это просто "карточки с текстом", но на практике задача в Битрикс24 живет в плотной связке с другими объектами: пользователями, группами/проектами, подзадачами и файлами. Поэтому при создании или обновлении мы проверяли зависимости и, например, не добавляли задачу, если на коробке еще нет нужной группы или родительской задачи. Иначе она создается некорректно и потом превращается в ручную "пересборку".
Отдельная сложность задач – дополнительные данные, которые нельзя забрать одним запросом. Для полноценного переноса по каждой задаче нужно отдельно подтягивать файлы, чек–листы и комментарии. При этом нет единого запроса "все комментарии по всем задачам", поэтому сбор идет только в момент обработки каждой задачи, и на больших объемах это заметно по времени: от нескольких часов до суток и больше.
Плюс есть контентная часть: в описаниях встречаются BB–коды, которые нужно переписывать под новую систему ID. Например, [USER=209] требует замены ID пользователя по таблице маппинга, а [DISK FILE ID=1212] – сначала переноса самого файла на Диск, получения нового ID и только потом подмены идентификатора в тексте. В этом блоке у нас работали и добавление, и обновление, чтобы миграцию можно было прогонять итерациями.
Добавление – да
Обновление – да
Миграция элементов смарт–процессов
По логике они похожи на лиды и сделки, но часто имеют больше нестандартных связей, часть которых приходится настраивать уже на коробке. На время импорта мы старались отключать роботов и обработчики событий, чтобы случайно не запустить бизнес–процессы и не нагенерировать лишние задачи и действия. Здесь также использовали добавление и обновление.
Добавление – да
Обновление – да
Миграция бизнес–процессов
Ручной экспорт/импорт почти всегда слишком дорог по времени: каждый шаблон нужно импортировать и перенастраивать параметры, переменные, константы и activity под новые сущности. Поэтому мы автоматизировали перенос через API и делали подмену облачных привязок на коробочные. Важно учитывать, что глобальные переменные и константы по API не выгружаются, их приходится собирать отдельно и переносить с маппингом. Такой подход обычно закрывает большую часть шаблонов автоматически (порядка 80–90%), а точечные места, особенно связанные с Диском и правами, правятся вручную.
Добавление – да
Обновление – да (но не рекомендуется)
Миграция ленты событий (таймлайн)
Заключительным этапом миграции по части CRM является обогащение различных типов сущностей, а конкретнее события в таймлане: комментарии, письма, дела, задачи, события БП. Сложность в том, что у разных типов событий разная структура и привязки, а чтобы выгрузить полный объем, нужно много запросов: сначала списки, затем по каждому элементу отдельно комментарии и activity. Поэтому по времени этот блок обычно занимает 3–6 часов.
Добавление – да
Обновление – нет
Чаты
Главная особенность – приватные диалоги нельзя выгрузить под админом №1, если он не участник: нужен вебхук пользователя с доступом к конкретному чату. Дополнительно мы учитывали привязки чатов к сущностям (CRM, проекты, календарь), поэтому они должны быть заранее перенесены и смапплены. Файлы в чатах скачиваются по временной ссылке, которая живет минуты, поэтому работали строго по цепочке: FILE_ID –> получить DOWNLOAD_URL –> сразу скачать –> загрузить на Диск –> сохранить маппинг.
Технические особенности выгрузки чатов
Для переноса персональных чатов важно сразу принять ключевое ограничение: запросы к REST должны выполняться через вебхуки тех пользователей, которые реально имеют доступ к чатам. Приложение, работающее под админом с id 1, видит только чаты самого первого админа. Если попытаться получить данные чата, в котором пользователь не состоит, REST вернет ошибку ACCESS_ERROR.
Чаты в Битрикс24 бывают разных типов. Есть персональные/приватные (типа "P" или "private") – там всегда только два пользователя. Есть и остальные типы, где участников может быть больше. На проекте нам встретились такие типы: "private", "chat", "general", "channel", "crm", "sonetGroup", "calendar".
Отдельно нужно учитывать, что часть чатов привязана к сущностям ("crm", "sonetGroup", "calendar"). Значит, для корректной миграции этих чатов сначала необходимо перенести сами сущности и смаппить их ID, иначе связки не соберутся.
Есть еще одна практическая особенность: когда вы экспортируете данные через вебхук конкретного пользователя, он отдает сразу все доступные этому пользователю чаты – и приватные, и общие. Поэтому нельзя просто "выгрузить все вебхуками" без контроля: нужно фиксировать, какие чаты уже были экспортированы, чтобы не выгружать их повторно и не плодить дубли.
В результате мы пришли к стабильной схеме выгрузки:
- получаем список чатов через "im.recent.list",
- по этому списку берем данные чата методом im.dialog.get,
- сообщения выгружаем "вглубь", до самых первых, через im.dialog.messages.get,
- участников чата получаем через im.chat.user.list.
При этом метод im.dialog.messages.get возвращает нестандартную структуру: в "messages" приходит до 20 сообщений, в "users" – авторы этих 20 сообщений, в "files" – файлы этих 20 сообщений. Если хранить чат в таком виде "как отдал метод", получится неудобная структура из трех вложенных массивов. Поэтому в нашей системе мы разделили результат im.dialog.messages.get на три отдельных файла экспорта: отдельно сообщения, отдельно пользователи, отдельно файлы. Это сильно упростило дальнейшую обработку и импорт.
Как мы организовали сбор вебхуков:
Чтобы выгрузка приватных чатов не превратилась в бесконечную переписку с сотрудниками, мы поставили процесс "на рельсы":
- сделали понятную инструкцию с картинками "Как создать вебхук за 3 минуты";
- провели короткий 15–минутный вебинар для ключевых пользователей;
- назначили ответственного со стороны клиента, который контролировал сбор вебхуков;
- завели таблицу учета: кто предоставил вебхук и какие чаты удалось выгрузить.
Важный нюанс: вебхуки не обязательно собирать со всех сотрудников. Если в чате 5 человек, достаточно одного вебхука от любого участника этого чата.
Файлы в чате
Отдельная важная часть чатов – файлы. По сути это файлы Диска, и после серии тестов мы остановились на скачивании через disk.file.get: метод возвращает параметр DOWNLOAD_URL – актуальную ссылку на скачивание с авторизацией. Но такая ссылка живет буквально несколько минут, поэтому скачивание можно делать только "в цепочке", без пауз: FILE_ID –> disk.file.get –> DOWNLOAD_URL –> файл скачан –> файл сохранен на диск –> выполнен маппинг.
Управление проектом: как организовать процесс
Работа с клиентом – ключ к успеху
1. Сделайте клиента союзником: Объясните, что успех зависит от совместных усилий. Клиент должен организовать своих сотрудников для тестирования.
2. Четкий план тестирования:
- Сформируйте фокус–группу из ключевых пользователей
- Проведите 2–3 волны тестирования
- Используйте канбан–доску в Битрикс для учета замечаний
3. Коммуникация – регулярно и прозрачно:
- Еженедельные созвоны по статусу
- Письменные отчеты о прогрессе
- Четкие дедлайны для всех участников
Чего избегать: "бесконечная миграция"
Самая частая причина провала – когда после старта миграции сотрудники продолжают активно работать в облаке. В итоге данные расходятся, и часть блоков приходится переносить заново.
Наше решение:
- Четкое расписание: "До пятницы все проверяют свои данные, с пятницы по воскресенье – миграция, в понедельник – работаем только в коробке"
- Ответственный от клиента, который контролирует соблюдение графика
- Техническая блокировка облака после финальной миграции.
Технические сложности и их решения
Память и производительность
При работе с большими объемами данных мы столкнулись с повышенным потреблением памяти. Решили это практично:
- Оптимизировали обработку больших массивов: разбивали на чанки по 100–200 записей;
- Использовали прогрессивное сохранение: не держали все данные в памяти;
- Настроили мониторинг: следили за использованием ресурсов в реальном времени.
Маппинг идентификаторов
Разные ID в облаке и на коробке – основная техническая сложность. Мы создали единую систему маппинга, которая:
- Хранила соответствия старых и новых ID;
- Использовалась всеми модулями миграции;
- Позволяла откатываться и проверять целостность связей.
Что мы получили в итоге
Проект занял около двух месяцев от аудита до полного перехода. Основное время ушло не на техническую реализацию, а на организацию и качество:
- Подготовку и планирование (20%)
- Тестирование и обратную связь от пользователей (40%)
- Непосредственно миграцию данных (40%)
Результат: клиент стабильно работает на коробочной версии. Критические бизнес–процессы перенесены полностью. Незначительные расхождения в исторических данных не повлияли на текущую работу.
Советы тем, кто только начинает такой проект
Планируйте с запасом и не недооценивайте объем работ. Вкладывайтесь в проектирование архитектуры миграции: часы на старте экономят дни в конце. Автоматизируйте все, что можно, и документируйте этапы – это помогает и в отладке, и в повторяемости результата. И главное: держите тесную связку с клиентом, потому что вовлеченность команды на стороне бизнеса – это половина успеха.
Заключение
Успешная миграция – это сочетание профессионального анализа требований, четкого планирования, качественной технической реализации, сильного управления проектом и партнерских отношений с клиентом. Мы вышли из проекта с методологией и инструментами, которые позволяют повторять такие миграции предсказуемо – без паники, неожиданностей и срывов сроков. Если вы стоите перед похожей задачей, правильный подход простой: сначала анализ, потом план, затем поэтапная миграция и тестирование.