Переход из облака в коробку Битрикс24: как спланировать миграцию

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

Зачем компании переходят из облака в коробку

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

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

Границы задачи обычно такие:

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

Если цель — не переезд, а запуск уже купленного портала, это другая задача, и её разбирает материал «Купили Битрикс24, никто не пользуется»: как реально запустить CRM.

Что переносится, а что придётся воссоздавать

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

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

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

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

Карта миграции CRM: документ, без которого не начинают

Карта миграции — это таблица, которая связывает объекты источника и приёмника и заранее отвечает на вопрос «как поймём, что перенеслось». Её готовит администратор портала вместе с руководителем проекта, а согласует владелец процесса продаж. Без карты перенос превращается в набор разрозненных действий, а приёмка — в спор о вкусах.

Разумный набор колонок:

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

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

Как выбрать способ переноса

На рынке есть несколько приложений для переноса между порталами Битрикс24, и они отличаются по охвату и ограничениям. Сравнивать их стоит по составу переносимых данных, поддерживаемым направлениям (облако в коробку, коробка в коробку и так далее), лимитам и требованиям к порталу-приёмнику.

[

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

Отдельно проверьте, как инструмент обходится с датами, дублями и повторным запуском. Некоторые приложения при повторном прогоне создают дубликаты, поэтому перенос выполняется один раз, а перед запуском делается резервная копия портала-приёмника.

Подготовка портала-приёмника

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

1. Развернуть сервер и установить портал, настроить домен и защищённое соединение. 2. Убедиться, что лицензия и конфигурация соответствуют планируемому объёму данных и числу пользователей. 3. Сделать резервную копию портала-приёмника до миграции — это точка возврата. 4. Проверить, что портал пустой или содержит только те данные, которые не конфликтуют с переносимыми. 5. При переносе в коробку отключить рассылку писем до завершения миграции и включить её после — иначе сотрудники и клиенты получат лишние уведомления. 6. Подготовить тестовый контур, если есть возможность: на нём прогоняется перенос и проверяются связи.

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

Порядок переноса: пользователи, диск, сущности

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

Рабочий порядок выглядит так:

• пользователи и структура подразделений;
• справочники и настройки, от которых зависят карточки (воронки, статусы, пользовательские поля);
• файловое хранилище;
• CRM: компании, контакты, лиды, сделки;
• задачи, проекты, смарт-процессы;
• коммуникации и история.

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

Переключение пользователей и внешних каналов

Данные в коробке — это ещё половина переезда. Вторая половина — переключить людей и каналы так, чтобы работа не встала.

Что нужно закрыть:

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

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

Учебный пример: перенос на тестовых данных

Учебный пример. Данные условные и не описывают реальную компанию.

Входные условия. Компания с отделом продаж из 40 человек решила перейти на коробочную версию. В облачном портале накопилось около 30 000 сделок, 12 000 контактов, 6 000 компаний, порядка 90 000 задач и файловое хранилище объёмом около 40 ГБ. Есть интеграция с сайтом и обмен с учётной системой. Критично сохранить историю сделок и привязки к клиентам.

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

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

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

Как проверить результат и принять работу

Приёмка — это не «вроде всё на месте», а сверка по заранее согласованным критериям. Проверку удобно вести по чек-листу.

• Сверено число записей по каждому объекту из карты миграции: сделки, контакты, компании, задачи, пользователи.
• Выборочно открыты сделки и проверены связи: контакт, компания, ответственный, товарные позиции.
• Проверены пользовательские поля и значения, которые в них переносились.
• Проверено, что задачи видны своим исполнителям и привязаны к нужным проектам.
• Проверены файлы: открываются, привязаны к правильным карточкам, нет битых ссылок.
• Проверены права доступа: сотрудники видят то, что должны, и не видят лишнего.
• Проверены внешние каналы: почта, телефония, формы, интеграции.
• Зафиксированы известные ограничения (например, даты создания) и то, как команда будет с ними работать.
• Сделана резервная копия коробочного портала после успешного переноса.
• Определён период параллельной работы и момент отключения облачного портала.

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

Типичные ошибки и ограничения

• Перенос на непустой портал. Многие инструменты требуют чистого приёмника, иначе данные смешаются или перенос не запустится.
• Повторный запуск без необходимости. Часть приложений при повторном прогоне создаёт дубликаты, поэтому перенос делают один раз.
• Отсутствие резервной копии. Без точки возврата любая ошибка становится необратимой.
• Забытая рассылка писем. При переносе в коробку её отключают до завершения, иначе уходят лишние уведомления.
• Недооценка объёма. Лимиты на число сущностей за прогон и на размер файлов могут потребовать нескольких этапов.
• Ожидание, что перенесётся всё. Даты создания, часть комментариев и настроек могут не переноситься — это проверяется заранее.
• Переключение людей до проверки данных. Сотрудники начинают работать в коробке, пока перенос ещё не подтверждён.

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

Какие исходные данные подготовить для оценки

Чтобы оценить объём работ и стоимость, нужны факты, а не общие слова. Подготовьте:

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

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

Что дальше

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