Коробка Энтерпрайз как следующий этап развития системы: переезд с облачного Битрикс24

Как мы перенесли почти 2 ТБ данных и не остановили работу компании

Компания – растущий бизнес с командой 800+ сотрудников и сильной внутренней IT-экспертизой. Несколько лет она работала в облачном Битрикс24: система помогла вырасти, выстроить продажи и внутренние процессы.

Появились задачи, которые в Облаке Энтерпрайз решались слишком сложно или вообще не решались:

• нестандартные бизнес–процессы;
• глубокие интеграции с внутренними сервисами;
• требования к безопасности и контролю данных;
• предсказуемость изменений и доработок.

В этот момент Коробка Энтерпрайз стала логичным следующим шагом – когда важно не просто использовать систему, а гибко управлять ею под нужды бизнеса.

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

Задача звучала предельно четко – и именно это сразу задало правильный тон проекту:

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

Если сказать проще – переехать аккуратно и без потерь всех данных.

Важно! Мы не делим Битрикс24 на «хороший» и «плохой»: облако и коробка подходят для разных этапов роста. В этом случае коробочная версия стала логичным выбором, так как позволила гибко настроить процессы, обеспечить контроль над данными, интегрироваться с внутренними сервисами и планировать обновления в удобном для бизнеса режиме.

Первое, что важно было проговорить: волшебной кнопки «перенести все» не существует. Да, у Битрикс24 есть инструменты миграции, но они не покрывают сложные и кастомные сценарии.

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

1. составили карту всех сущностей и связей между ними;
2. определили, какие данные реально используются, а какие можно не переносить;
3. оценили объем файлового хранилища – именно здесь клиента ждал сюрприз в виде почти 2 ТБ данных.

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

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

Мы построили собственный "движок миграции":

• консольное PHP–приложение на официальной библиотеке bitrix24/b24phpsdk;
• единая точка управления процессом (что уже перенесено, что в очереди, что упало);
• детальное логирование (ошибки, длительность этапов, статистика);
• возможность безопасно останавливать и продолжать миграцию;
• быстрые доработки под специфику клиента (например, обработка BB–кодов в задачах).

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

Главное правило миграции: порядок решает все. В Битрикс24 сущности связаны между собой. Если переносить "как получится", вы получаете некорректные назначения, битые ссылки на файлы, потеря связи и хаос в правах.

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

Миграция пользователей и подразделений

Миграцию начали с пользователей и структуры компании. В облаке недоступны данные для авторизации (логины и пароли), поэтому мы работали только с профилями пользователей. Критичным полем стала почта – без нее невозможно корректно создать учетную запись на коробке. Данные были получены, сопоставлены и перенесены без потери структуры.

Добавление – да

Обновление – да

Перенос файлов и папок Диска

Диск Битрикс24 технически несложен, но REST–методы не позволяют получать файлы и папки рекурсивно – только по одному уровню вложенности. Мы реализовали поуровневый алгоритм экспорта и импорта (8 уровней вложенности), что позволило сохранить структуру и связи. Экспорт выполнялся под суперадминистратором без ограничений по правам.

Миграция типов смарт–процессов

На следующем этапе перенесли все типы смарт–процессов. Сопоставление выполнялось по заголовкам, что исключало дубли, но не предполагало обновление существующих типов.

Добавление – да

Обновление – нет (маппинг по заголовку)

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

Миграция стадий и разделов CRM

Перенесли воронки и стадии для сделок, лидов и других CRM–сущностей. Стадии сопоставлялись по названиям, без обновления уже существующих.

Добавление – да

Обновление – нет (маппинг по заголовку)

Миграция инфоблоков

Перенесли типы инфоблоков и их элементы. Часть справочников недоступна через API – такие инфоблоки переносились штатным экспортом и импортом.

Добавление – да

Обновление – да

Миграция пользовательских полей

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

Добавление – да

Обновление – нет

Миграция контактов и компаний

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

Добавление – да

Обновление – да

Миграция лидов

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

Добавление – да

Обновление – да

Миграция сделок

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

Добавление – да

Обновление – да

Миграция групп и проектов

Перенесли группы и проекты всех типов (открытые, закрытые, приватные) вместе со списком участников.

Добавление – да

Обновление – да

Перенос календарей

Календарные события выгружались под суперадминистратором. Для повторяющихся событий переносились только базовые события – это позволило избежать дублей.

Миграция задач

Задачи – один из самых сложных блоков. Они тесно связаны с пользователями, проектами, подзадачами и файлами, поэтому перед созданием мы проверяли наличие всех зависимостей. Отдельно переносились чек–листы, комментарии и файлы. Контент в описаниях переписывался с учетом новых ID. Миграция выполнялась итерационно.

Добавление – да

Обновление – да

Миграция элементов смарт–процессов

Элементы смарт–процессов переносились аналогично лидам и сделкам, но с учетом большего количества нестандартных связей. На время импорта отключались роботы и обработчики событий, чтобы не запускать бизнес–процессы.

Добавление – да

Обновление – да

Миграция бизнес–процессов

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

Добавление – да

Обновление – да (не рекомендуется)

Миграция ленты событий (таймлайн)

Финальный этап CRM–миграции – перенос комментариев, писем, дел, задач и событий БП. Блок требовал большого количества запросов и аккуратной обработки данных.

Добавление – да

Обновление – нет

Чаты

Самый чувствительный блок миграции. Приватные диалоги нельзя выгрузить под админом №1, если он не является участником чата – для этого нужны вебхуки пользователей с доступом к конкретным диалогам. Дополнительно мы учитывали привязки чатов к сущностям (CRM, проекты, календарь), поэтому эти данные должны быть заранее перенесены и смапплены. Файлы в чатах скачиваются по временным ссылкам, которые живут всего несколько минут, поэтому перенос выполнялся строго по цепочке: FILE_ID → получить DOWNLOAD_URL → сразу скачать → загрузить на Диск → сохранить маппинг.

REST-запросы выполняются только через вебхуки пользователей, имеющих доступ к чату. Приложение под админом с id 1 видит только собственные чаты; попытка получить чужой диалог приводит к ошибке ACCESS_ERROR.

В Битрикс24 есть разные типы чатов: приватные и групповые. В рамках проекта переносились чаты типов: 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 возвращает данные в виде трех массивов (сообщения, пользователи, файлы). Мы разделяли их на отдельные файлы экспорта, что значительно упростило дальнейшую обработку и импорт.

Сбор вебхуков

Чтобы сбор вебхуков не превратился в ручной хаос, мы организовали процесс: подготовили пошаговую инструкцию «Как создать вебхук за 3 минуты»;

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

Важно: вебхуки не требуются от всех сотрудников – если в чате несколько участников, достаточно вебхука от любого из них.

Файлы в чатах

Файлы переносились через disk.file.get, получая актуальный DOWNLOAD_URL. Из-за короткого времени жизни ссылки скачивание выполнялось без пауз, строго в одной цепочке, с обязательным сохранением маппинга файлов.

Мы сразу сделали клиента партнером проекта:

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

Чтобы избежать ситуации «данные разъехались», был утвержден четкий сценарий финального перехода:

• период проверки;
• финальная миграция;
• полное отключение облака и работа только в коробке.

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

• 20% – анализ и подготовка;
• 40% – тестирование и работа с пользователями;
• 40% – сама миграция данных.

В итоге:

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

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

Если бизнес вырос из облака, то коробка может стать не риском, а точкой роста.