Что ломается при переезде Битрикс24 из облака в коробку

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

Почему перенос — это пересоздание, а не копия

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

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

Утром после переноса компания получила 2500 писем

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

Причина в том самом штатном создании. Каждая задача и каждое назначение ответственного рождают уведомление, а уведомление, которое человек не прочитал за несколько минут, уходит ему письмом. Для обычной работы это правильно, для переноса — катастрофа: на агрохолдинге набралось 1629 уведомлений по задачам и 890 по CRM, и каждое размножилось по числу участников.

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

Все сделки оказались в первой стадии

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

Стадия сделки в Битриксе — не просто название, а код вроде C5:NEW, в котором зашит номер воронки. Номер воронки на новом портале свой, код из старого не находится, и сделка падает в первую стадию: системе больше некуда её положить. Есть и вторая тонкость, которую обнаруживаешь не сразу: если обновлять стадию, не указывая явно порядок сортировки, платформа сбрасывает этот порядок, и стадии в воронке перемешиваются — даже те, что перенеслись верно.

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

Карточки клиентов на месте, а позвонить некому

Контакты переехали: имена, компании, ответственные, история дел. Менеджер открывает карточку, чтобы набрать клиенту, — поле телефона пустое. И почты нет. И так во всех карточках.

Это самая коварная ошибка переноса, потому что она тихая. Выгрузка карточки «со всеми полями» отдаёт всё, кроме телефонов, почты, сайтов и мессенджеров: такие поля хранятся отдельно и запрашиваются отдельным обращением. Перенос при этом проходит без единого сбоя — журнал чистый, количество записей сходится, ошибки нет. Просто в карточках пусто, и выясняется это, когда менеджеру нужно позвонить.

Теперь контактные данные запрашиваются явно, отдельным шагом, и дописываются уже перенесённым карточкам. На одном переносе так вернулись телефоны и почта 451 контакту и 437 лидам. После каждого переноса мы открываем десяток случайных карточек и смотрим, есть ли чем связаться, — это пункт обязательной проверки.

У всех задач одна дата создания

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

Ядро ставит дату создания на момент, когда задача появилась, и никакого «на самом деле она от марта» не предполагает: в обычной жизни задача и создаётся сейчас. Со сроком отдельная беда — формат даты из старого портала ядро не распознаёт и молча подставляет свой.

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

Человек вошёл на портал и ничего не может

Сотрудники заходят по новым адресам, логины работают, структура компании на месте. Но разделы пустые, задачи не создаются, а у руководителя нет даже кнопки «Создать проект». Компания стоит, а внешне всё в порядке — самый неприятный вид поломки.

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

После переноса мы проходим по всем сотрудникам и расставляем группы. На последнем проекте в рабочую группу добавили 49 человек из 54, в группу руководителей — 25 из 28, остальные туда и не должны были попасть. Заодно назначаем руководителей подразделений по структуре старого портала. Проверяем не списком в админке, а входом: берём несколько человек с разными ролями и смотрим портал их глазами.

Демо-данные занимают номера настоящих карточек

Этот случай снаружи не виден вообще, и в этом его опасность.

Свежеустановленная коробка приходит с демонстрационным содержимым: несколько сделок, лидов и контактов под номерами с первого по десятый. При переносе мы сохраняем номера записей — иначе рассыплется всё, что на них ссылается: дела, привязки сделок к контактам, упоминания в переписке, ссылки в задачах. И если демо-данные оставить, настоящие карточки лягут поверх демонстрационных или не лягут вовсе. Всплывает это не в день переноса, а через недели, когда кто-то откроет сделку и увидит там чужого «Ивана Петрова» из комплекта поставки.

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

Иногда ошибка не в переносе, а в самой платформе

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

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

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

Как убедиться, что перенеслось всё

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

Проверять нечем, если заранее не с чем сравнивать, поэтому сверка начинается до переноса, а не после. Мы снимаем количества на старом портале до начала работ и те же количества на новом после: сделки, лиды, контакты, компании, задачи, чаты, сообщения, файлы. Отдельно сверяем не штуки, а суммы — например, сумму сделок по каждой стадии: так ловятся записи, которые перенеслись, но легли не туда. Смотрим крайние даты: самая ранняя и самая поздняя запись в каждом разделе должны совпадать с тем, что было. И сверяем связи — сколько дел привязано к сделкам, сколько файлов к сообщениям: записи бывают на месте, а связи между ними рвутся незаметнее всего.

Расхождения в итоговой таблице не замазываются, а объясняются построчно: столько-то демонстрационных записей удалено до старта, столько-то личных чатов не перенесено, потому что сотрудники не выдали доступ. Клиент получает таблицу, где сходится каждая строка либо стоит причина, почему не сходится. Это единственный честный ответ на вопрос «всё ли на месте»: не «мы проверили», а «вот цифры, сверьте сами».

Что из этого следует

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

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