Из облака Битрикс24 в коробку: что перенёс инструмент, что делали руками и что не переехало

17 сентября 2026 года команда «+Альянс» передала заказчику его Битрикс24, который раньше жил в облаке, уже в коробочной редакции «1С-Битрикс24: Корпоративный портал 250». Туда уехали пользователи и оргструктура, задачи, календари, лента, Диск, смарт-процессы и мессенджер вместе с личной перепиской сотрудников. Переехало не всё. Часть мелких данных облако не отдало, часть личных диалогов осталась без разрешения владельцев, а шаблоны задач и три файла больше гигабайта пришлось переносить руками.

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

Кейс — для того, кто отвечает за облачный портал и примеряет миграцию Битрикс24 из облака в коробку. По нему вы соберёте план для своего портала: разложите сущности на три списка (переносится инструментом, переносится руками, не переносится), распределите прогоны по ночам и заранее назначите сбор разрешений на личные чаты. Всё, что здесь сказано о поведении Битрикс24, — наблюдение нашей команды на одном портале. На другие порталы я его не обобщаю.

Коротко

• Облачный портал заказчика на тарифе «Энтерпрайз 250» перенесён в коробочную редакцию «1С-Битрикс24: Корпоративный портал 250» собственным инструментом компании «+Альянс» на Python и FastAPI; передача заказчику — 17 сентября 2026 года.
• Масштаб портала заказчика на день передачи: 142 учётные записи с учётом служебных и заблокированных, 3 221 задача, 5 488 чатов со 105 311 сообщениями, 22 783 файла общим объёмом около 32 ГБ.
• С портала заказчика в коробку не попали экземпляры запущенных бизнес-процессов, личные диалоги 41 учётной записи, не выдавшей разрешения, и 4 групповых чата. Шаблоны задач и файлы крупнее примерно 1 ГБ переносились руками.
• Доступ к личным чатам через OAuth-виджет открыла 101 учётная запись из 142; на сбор разрешений ушло больше недели.
• Финальный догон изменений в нашем проекте занял 6,4 часа из 16 отведённых. День переключения заказчик описывает как примерно половину рабочего дня без портала; с нашей стороны коробка была готова к работе, когда закрыли облако, а сотрудники ждали перенастройки настольного приложения.

Первый шаг плана: три списка сущностей

Начните план с трёх списков: что переедет инструментом, что придётся переносить руками и что не переедет вовсе. У нас они сложились так.

Файлы крупнее примерно 1 ГБ коробка у нас на проекте по REST не принимала. Таких нашлось три — 1,05, 2,19 и 2,57 ГБ. Соседний файл на 560 МБ переехал нормально, поэтому порог, на наш взгляд, именно в размере. Список крупных файлов своего портала соберите до первого прогона. Шаблоны задач тоже ушли в ручную работу: методов для них мы не нашли, и инструмент их не перенёс.

Процессы, которые будут идти в момент переезда, выпишите заранее и назначьте, кто проверит их повторный запуск. Экземпляр запущенного бизнес-процесса — это его состояние на ходу, и REST облака у нас на проекте не отдавал такое состояние ни в каком виде. Процессы в коробке стартовали заново, когда заявки встали на свои стадии.

Какой портал переезжал

Портал заказчика жил в облаке Битрикс24 на тарифе «Энтерпрайз 250» и уехал в коробку, редакция — «1С-Битрикс24: Корпоративный портал 250». Учётных записей на портале 142, и в этот счёт вошли служебные и заблокированные. Заказчик считает только действующих сотрудников, и таких переезд затронул 113. Подразделений на портале 23, рабочих групп 49: 44 проекта и 5 коллабов.

Соберите таблицу объёмов своего портала до выбора инструмента. Таблица портала заказчика на день передачи выглядела так.

На портале 168 пользовательских полей: 52 принадлежат смарт-процессам, 4 — задачам, остальные — поля ядра и сервисные поля. Шаблонов автоматизации 16, из них 8 у «Отпуска», по одному на стадию. Приложений маркетплейса в коробке нет, открытых линий у заказчика не было.

Если вы прикидываете сервер под свою коробку, вот конфигурация, на которой живёт этот портал. Сервер один, и все роли стоят на нём. У этого сервера 8 процессорных ядер и 32 ГБ оперативной памяти. ОС — «AlmaLinux 9.8 (Olive Jaguar)», nginx 1.30.4 и Apache 2.4.62, PHP 8.2.33, база — Percona Server 8.0.46. На 28 сентября 2026 года в работе было около 9 ГБ памяти, остальное занимал файловый кэш, и запас мы оцениваем как двукратный. Средняя нагрузка тогда была 0,28 на 8 ядер — по нашей оценке, портал практически не нагружен.

Свой инструмент вместо штатного и цена прямой записи в базу

Портал заказчика команда «+Альянс» переносила собственным инструментом на Python и FastAPI. Чтение шло через REST облака, запись — через REST коробки, файлы — через вебхук коробки. Со стороны инструмента работали два вебхука, на чтение облака и на запись в коробку, и одно OAuth-приложение для сбора пользовательских токенов.

Штатным инструментом 1С-Битрикс и сторонними сервисами на этом проекте мы не пользовались. Мы так решили по своей оценке: штатный инструмент переносит не всё и не сохраняет авторство.

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

Структуру таблиц команда вычитывала из ORM-классов самого продукта, но там только поля и типы. Что ядро записывает, когда создаёт ту же сущность само, какие флаги влияют на отображение и какие поля обязаны быть заполнены, там не описано. Отсюда правило команды: сначала снять эталон. Сущность создаётся руками в интерфейсе, потом смотрят, что ядро положило во все таблицы, где она упоминается, и воспроизводят это один в один.

Связи в инструменте держит карта соответствий. Ключ из модуля, типа сущности и облачного id ведёт в ней к коробочному id, и через карту резолвятся задача, проект, ответственный, файл, комментарий. Недостающего родителя инструмент подтягивает по требованию: если в чате попалась ссылка на задачу, которую ещё не перенесли, эта задача переносится тут же. Повторный прогон дозаливает недостающее и не плодит дублей.

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

Кто откроет доступ к личным чатам?

У нас на проекте администратор портала личной переписки не видел: Битрикс24 отдавал её только участнику диалога. То же было с комментариями к постам ленты и личными стадиями «Моего плана». Мы считаем это защитой самого портала.

Для переноса мы сделали OAuth-виджет. Через него сотрудник выдаёт разрешение, и инструмент читает данные этого сотрудника под его же токеном. Виджет прошла 101 учётная запись из тех же 142, куда входят служебные и заблокированные. Сбор занял больше недели, и этот этап уже не про технику, а про работу с людьми. Заводите сбор разрешений отдельной задачей и начинайте его задолго до последней ночи.

Для нашего инструмента правило простое: личные данные, которых не отдаёт REST, приедут в коробку только у того, кто прошёл виджет. Окно для них закрывается вместе с облаком. На портале заказчика так не переехали личные диалоги 41 учётной записи. Не попали в коробку и 4 групповых чата: их не отдал никто из участников.

В перенесённых чатах сохранились автор, дата, вложения, реакции, цитаты, карточки пересланных сущностей и привязка чатов к задачам, проектам и встречам. Чат задачи остался внутри чата проекта. Отметки о прочтении не переносили: мы считаем прочтение личной отметкой каждого человека, которая набирается заново.

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

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

Отключите почтовые шаблоны до первого прогона. Создание пользователя по API у нас на проекте рассылало письма-приглашения, и перед прогоном шаблоны гасили.

Порядок прогонов у нас сложился такой.

1. Сначала модуль за модулем на стенде, потом доводка на данных заказчика. Большинство подводных камней у нас вылезло как раз на живых данных: объёмы, дубли, уволенные, внешние гости, кастомные поля, роботы.
2. Первые полные прогоны на боевом портале заняли около 20 часов. В это время не входит хвост — отдельный проход, который переписывает связи и ссылки внутри перенесённых текстов: упоминания проектов, ссылки на посты и задачи, привязки заявок к задачам, теги вложений.
3. Тяжёлые модули ушли в отдельные ночи. Диск — 84 минуты переноса плюс 25 минут догона, мессенджер в первый раз — более 17 часов.
4. Дальше ускоряли: параллельная запись задач, пакетная запись «Моего плана» вместо построчной, ускорение мессенджера, сужение чтения облака по дате изменения там, где метод это умеет. На нашем проекте у событий календаря фильтра по изменению не было вообще, их сравнивали по времени изменения с картой соответствий.
5. К финалу ночная цепочка догона из 21–23 шагов укладывалась в 5,7–6,4 часа. Последняя дельта заняла 6,4 часа из отведённых 16. Работу людей остановили только на заключительную ночь, чтобы зафиксировать состояние и не гнаться за изменениями бесконечно.
6. После перехода людей в коробку полные проходы запрещены: они затрут работу сотрудников. Дельта работает, пока источник истины — облако.

Что пропустила сверка по количествам

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

Все 32 поста ленты с картинками после переноса оказались нерабочими, хотя журнал переноса и автоматическая приёмка были чистыми. Ссылка на вложение в постах портала заказчика встречалась в двух видах, которые отличаются одним символом: один вид указывает на объект Диска, другой — на уже привязанное вложение. Перенос оставил в ссылках номера из облака, а в коробке этих номеров нет. Нашлось это глазами. Первая починка подставила номер уже привязанного вложения, но оставила пометку объекта Диска, и ссылка снова не заработала. Вторая вписала номер объекта Диска коробки.

Уборка дублей в чатах, построенная на панели «Файлы» облака, снесла восемь законных файлов в пяти чатах. Панель у нас на проекте оказалась дедуплицированной, неполной и обрезанной потолком в 200 строк. Файлы восстановили, эталон переделали на пары «сообщение + файл», которые собирали обходом истории.

В коробке Битрикс24 у нас интерфейс показывал только последние 25 сообщений в 3 125 чатах. Среди них 3 075 чатов задач, 49 проектных чатов и 1 чат «Заметки». В базе все сообщения были на месте. В чате задачи причина оказалась в служебном баннере, который ядро само писало в этот чат сразу при его создании. Номер у баннера маленький, у перенесённой истории номера больше, и интерфейс решал, что старее баннера ничего нет.

У стадий смарт-процесса, созданных переносом, не заполнилась принадлежность к воронке. Стадии в интерфейсе видны, вручную заявка переводится, а робот «Сменить стадию» цель внутри воронки не находит и молча не срабатывает. В приёмке нашего инструмента есть шаг, который сравнивает, на какой стадии стоит каждая заявка в облаке и в коробке. Заявки дефект не сдвинул, и расхождений по нему этот шаг не показал. Симптом заметили 17 сентября, в первый день работы людей в коробке. Причину нашли и исправили на следующий день на всех 12 стадиях.

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

Проверку полноты мы вели на трёх уровнях. Первый — сверка трёх чисел: сколько в облаке, сколько в карте и сколько реально в коробке. К этой сверке прилагался перечень расхождений. Второй — пополевая сверка срезами по сущности, по проекту и по человеку. Третий — сверка размера каждого из 22 783 файлов, и расхождений там 0.

После истории со стадиями к проверке добавили аудит целостности ссылок. Это ответ на целый класс дефектов, когда ядро молча принимает ссылку на несуществующее. В аудите 12 проверок по задачам, проектам, участникам, комментариям задач и календарю. Смарт-процессы и стадии в него не входят. Аудит видит только одно: существует ли то, на что ведёт ссылка. Удалённый или заблокированный пользователь для него существует.

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

В свой план я бы сразу вписал аудит ссылок: у нас ссылки на несуществующее сверку по количествам проходили. Перечень сущностей для него собирайте по своим модулям. В наших 12 проверках нет ни постов ленты, ни шаблонов автоматизации, а такие ссылки стояли как раз там. Отдельным пунктом — просмотр глазами выборки перенесённого: нерабочие посты ленты нашли именно так.

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

День переключения глазами заказчика и нашей стороны

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

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

Отдельно заказчик упомянул около семи точечных обращений от сотрудников, которые не могли войти в новый портал: кому-то не пришло письмо о смене пароля, кто-то не увидел рассылку с новым адресом. Их решили в рабочем порядке. Назначьте заранее, кто в первый день будет разбирать вопросы по входу.

Итог проекта заказчик пока не подводит: после миграции ещё не прошло двух-трёх месяцев, и оценивать результаты рано.

Почему эти цифры могут не подойти вашему порталу

Все длительности этого кейса получены на портале заказчика. Порталу один год, и данных на нём немного. На портале постарше мерьте свои прогоны заново на стенде.

Эталоны для прямой записи мы снимали, когда версия продукта была «26.700.0 от 30.06.2026», и к финишу она не менялась. Если у вас продукт новее или старше, я бы собрал их заново: на совместимость таблиц между выпусками мы не рассчитываем.

Частые вопросы

Сколько длится переезд портала Битрикс24 из облака в коробку?

У заказчика облачный портал на тарифе «Энтерпрайз 250» переезжал в коробку поэтапно. Отладку вели на стенде по одному модулю, потом на данных самого портала. Дальше шли полные прогоны на боевом портале: первые из них занимали около 20 часов, и это без прохода по ссылкам в текстах. Завершали ночные догоны. Последний из них в нашем проекте уложился в 6,4 часа при окне 16 часов. Для своего портала заложите отдельные ночи под Диск и мессенджер и больше недели на сбор разрешений к личным чатам.

Перенесётся ли личная переписка сотрудников?

В нашем проекте личная переписка переехала только у тех учётных записей, которые сами открыли к ней доступ через OAuth-виджет: диалоги читались под токеном сотрудника. Разрешение выдала 101 учётная запись из 142, диалоги остальных 41 в коробку не попали. Сбор разрешений начинайте заранее: в нашем инструменте окно для таких данных закрывается вместе с облаком.

Что при переезде в коробку не переносится?

На портале заказчика в коробку не попали личные диалоги учётных записей, не выдавших разрешения, 4 групповых чата, которых никто из участников не отдал, и состояние запущенных бизнес-процессов — процессы стартовали заново. Ещё облако не отдало мелочи, например признак «заместитель руководителя», теги проектов и комментарии к событиям календаря. Шаблоны задач и файлы больше примерно 1 ГБ переносили вручную. Это опыт одного портала, поэтому свой список составляйте по своим модулям.

Будут ли сотрудники сидеть без портала?

В нашем проекте заказчик и мы описываем день переключения по-разному. По оценке заказчика, портала не было около половины рабочего дня; по нашей — работать в коробке было можно уже к закрытию облака, и люди ждали перенастройки настольного приложения. Точных времён у нас нет. Сам заказчик в следующий раз хотел бы время без портала максимально сократить или убрать полностью.

Достаточно ли сверить количество записей до и после?

В нашем проекте не хватило. Посты ленты с картинками и стадии смарт-процесса по счёту совпали, но все 32 поста оказались нерабочими, а робот «Сменить стадию» на перенесённых стадиях молча не срабатывал. Посты нашли глазами, и ради таких находок я бы оставил в плане выборочный просмотр того, что приехало. Дефект стадий прошёл и счёт, и сравнение заявок с облаком; заметили его 17 сентября, когда люди первый день работали в коробке, а на следующий день исправили. После этого в проверку добавили аудит ссылок. Его 12 проверок касаются задач, проектов, участников, комментариев задач и календаря. Смарт-процессов и стадий среди них нет. Аудит смотрит только на то, существует ли объект, на который ведёт ссылка.

Александр Жогов, основатель компании «+Альянс».