Битрикс24 облако или коробка: что выбрать и когда переезжать
Чем облачный Битрикс24 отличается от коробочного, во что реально обходится коробка и в какой момент компании имеет смысл переезжать. Разбор для руководителя.
Короткий ответ: большинству компаний подходит облако. Коробка нужна в трёх случаях: когда есть внутреннее требование размещать систему на собственных серверах, когда нужно менять логику ядра под свои процессы, и когда Битрикс24 должен работать с системами, которые не смотрят в интернет. Если ни одно из этих условий не выполняется, коробка добавит расходов и постоянной работы, но не даст выигрыша.
Ниже разбор для руководителя, который принимает решение: чем версии отличаются на практике, во что обходится коробка за пределами цены лицензии, какие триггеры говорят о необходимости переезда и как переезд проходит технически.
Чем отличается облачный Битрикс24 от коробочного
Облако - это подписка на портал, который работает на инфраструктуре вендора. Коробка - это лицензия на программный продукт, который вы разворачиваете на своём сервере или на арендованном хостинге и обслуживаете сами.
| Критерий | Облако | Коробка |
|---|---|---|
| Где хранятся данные | На серверах вендора | На вашем сервере или у выбранного вами хостера |
| Кто обновляет систему | Вендор, автоматически, без вашего участия | Вы или подрядчик, вручную, с предварительным тестированием |
| Бэкапы | Делает вендор, восстановление по запросу | Ваша зона ответственности: настройка, хранение, проверка восстановления |
| Модель оплаты | Регулярная подписка за портал | Разовая лицензия плюс продление плюс инфраструктура плюс поддержка |
| Скорость старта | Портал доступен сразу после регистрации | От нескольких дней до нескольких недель на подготовку сервера и установку |
| Доступ к исходному коду | Нет | Есть, код лежит на вашем сервере |
| Правка ядра | Невозможна, только API и приложения | Возможна технически, но осложняет обновления |
| Внутренние системы в закрытом контуре | Нужен шлюз или публикация сервиса наружу | Прямое подключение внутри своей сети |
| Ограничения по диску | Зависят от тарифа | Ограничены объёмом вашего хранилища |
| Ограничения по пользователям | Зависят от тарифа | Определяются купленной лицензией |
| Новые функции | Появляются первыми | Приходят с обновлениями позже |
| Мобильное приложение | Работает сразу | Работает, но портал должен быть доступен снаружи и с корректным сертификатом |
| Отказоустойчивость | Обеспечивает вендор | Обеспечиваете вы: резервирование, мониторинг, дежурство |
Главная разница не в функциях, а в том, кто отвечает за работоспособность. В облаке ответственность на вендоре. В коробке она полностью на вас.
Кому подходит облако
Облако закрывает потребности компании, если верно большинство пунктов:
- Нет своего системного администратора. Или он один и занят другими системами. В облаке администрировать сервер не нужно вообще.
- До нескольких сотен пользователей. Облачные тарифы рассчитаны на этот диапазон, и производительности хватает без отдельной настройки.
- Нет внутреннего требования размещать систему у себя. Если в компании нет политики, которая запрещает внешние сервисы, вопрос снимается.
- Нужен быстрый старт. Портал разворачивается за день, а бюджет уходит на настройку процессов, а не на инфраструктуру.
- Процессы стандартные. Продажи, задачи, документооборот, база знаний закрываются штатными инструментами и приложениями маркетплейса.
- Команда распределена. Сотрудники работают из разных городов и с мобильных устройств, портал должен быть доступен отовсюду.
Практическое наблюдение: компании, которые начинают с облака, доходят до рабочей автоматизации быстрее. Они не тратят первые месяцы на сервер и сразу занимаются процессами. Как это выглядит на старте, мы разбирали в материале про внедрение Битрикс24 с нуля.
Кому нужна коробка
Коробка оправдана, когда есть хотя бы один жёсткий признак:
- Внутренние требования к размещению данных. Служба безопасности или головная компания требует, чтобы система стояла в вашем контуре. Это не обсуждается и не решается настройками облака.
- Интеграция с системами, которые не выходят в интернет. Внутренняя ERP, производственная система, складской контур, база, доступная только из локальной сети. Пробрасывать такие системы наружу часто дороже и рискованнее, чем поставить портал рядом с ними.
- Потребность менять логику ядра. Не добавить поле или робота, а изменить поведение системы: свои алгоритмы расчёта, нестандартная модель прав, собственная логика обработки сущностей.
- Очень большое количество пользователей. На масштабе в тысячи сотрудников экономика лицензий и требования к производительности считаются отдельно.
- Специфические требования к аутентификации. Единый вход через корпоративный каталог пользователей, свои правила парольных политик, синхронизация оргструктуры из внутренней системы.
- Требования к резервным копиям. Регламент обязывает хранить бэкапы в определённом месте и определённый срок под вашим контролем.
Если ни один пункт не про вас, а аргумент звучит как «коробка солиднее» или «хотим, чтобы всё было своё», это не техническое требование. Это предпочтение, за которое придётся платить ежегодно.
Сколько стоит коробочный Битрикс24
Главная ошибка при расчёте бюджета: считать только лицензию. Коробка - это не покупка один раз, а постоянные расходы. Точные цифры зависят от редакции, числа пользователей и подрядчика, поэтому ниже логика расчёта, а не прайс.
| Статья расходов | Периодичность | Что влияет на сумму |
|---|---|---|
| Лицензия | Разово при старте | Редакция и количество пользователей |
| Продление лицензии | Ежегодно | Даёт доступ к обновлениям и техподдержке вендора |
| Серверы или хостинг | Ежемесячно | Число пользователей, объём файлов, требования к скорости |
| Администрирование | Ежемесячно | Свой админ в штате или абонентское обслуживание у подрядчика |
| Обновления и их тестирование | Несколько раз в год | Объём доработок: чем больше правок, тем дороже каждое обновление |
| Доработки | По мере задач | Сложность требуемой логики |
| Восстановление после сбоев | Непредсказуемо | Качество резервного копирования и наличие тестового контура |
Три статьи, которые чаще всего забывают заложить в бюджет:
- Продление лицензии. Без активного продления вы остаётесь на текущей версии: новые функции и обновления безопасности не приходят.
- Тестирование обновлений. Обновлять боевой портал сразу - плохая практика. Нужен тестовый контур и человек, который проверит, что доработки пережили обновление.
- Дежурство. Если портал лёг в пятницу вечером, кто-то должен его поднять. В облаке это забота вендора, в коробке - ваша.
Считайте горизонт не менее трёх лет. На дистанции в год коробка может выглядеть выгоднее подписки, а на трёх годах с учётом хостинга и администрирования картина часто разворачивается.
Мифы про коробку
| Миф | Как на самом деле |
|---|---|
| Коробка безопаснее | Безопасность зависит от того, как настроен сервер, кто имеет к нему доступ и как быстро ставятся обновления. Необслуживаемая коробка защищена хуже, чем облако |
| В коробке можно всё | Технически можно менять код ядра. Практически каждая такая правка усложняет обновления и увеличивает стоимость поддержки |
| Коробка дешевле на длинной дистанции | Зависит от количества пользователей и от того, есть ли у вас админ. Без своего специалиста экономия съедается счетами подрядчика |
Разберём подробнее.
«Коробка безопаснее». Сервер в вашем контуре не защищает сам по себе. Он защищает при условии, что настроен доступ, закрыты лишние порты, обновляются операционная система и веб-сервер, работает мониторинг и есть проверенные бэкапы. Если портал поставили один раз и забыли, риск выше, чем у облака, которое обслуживает выделенная команда.
«В коробке можно всё». Возможность править ядро выглядит как свобода, но работает как долг. Каждое обновление придётся сверять с вашими правками, а часть правок переносить заново. Хорошая практика: менять поведение системы через API, события и собственные модули, а не через изменение исходного кода вендора.
«Коробка дешевле». Сравнивайте не лицензию с подпиской, а полную стоимость владения: лицензия плюс продление плюс хостинг плюс часы администрирования плюс тестирование обновлений. Для компании на 30 человек без своего админа облако почти всегда дешевле. Для компании на несколько сотен человек с сильным IT-отделом расчёт может дать другой ответ.
Когда переезжать с облака на коробку
Конкретные триггеры, при которых переезд обоснован:
- Появилось внутреннее требование или требование заказчика разместить систему в собственном контуре.
- Нужна интеграция с системой, которую нельзя выставить в интернет, и обходные шлюзы получаются дороже переезда.
- Уперлись в ограничения тарифа по объёму диска или числу пользователей, и расширение экономически невыгодно.
- Требуется логика, которую невозможно реализовать через API и приложения: своя модель прав, нестандартная обработка данных, глубокая переработка интерфейса.
- Нужна аутентификация через корпоративный каталог пользователей с синхронизацией оргструктуры.
- Компания выросла до масштаба, при котором IT-отдел готов взять портал на обслуживание вместе с остальной инфраструктурой.
Когда переезжать не надо
Причины, по которым переезд регулярно затевают зря:
- «Хотим свои данные у себя». Формулировка без конкретного требования. Спросите, какой документ или регламент это предписывает. Если такого нет, переезд решает эмоцию, а не задачу.
- «В облаке тормозит». Чаще проблема в раздутых бизнес-процессах, тяжёлых фильтрах или в канале связи офиса. На своём сервере тот же процесс будет тормозить так же.
- «Хотим доработок». Значительная часть доработок делается приложениями и REST API прямо в облаке. Проверьте это до переезда.
- «Дорого платить каждый год». Коробка тоже требует ежегодных платежей: продление, хостинг, обслуживание.
- Портал ещё не приживается. Если сотрудники не работают в системе, смена версии ничего не изменит. Сначала процессы, потом инфраструктура.
Как перейти с облака на коробку
Переезд - это проект, а не операция копирования. Порядок шагов:
1. Аудит. Фиксируем, что используется: сущности CRM, воронки, поля, бизнес-процессы, роботы, права, интеграции, приложения маркетплейса, объём диска и почты. Отдельно список того, что не используется и переносить не нужно.
2. Список того, что переносится, и того, что теряется. Это самый важный шаг. Не всё переносится один в один, и лучше узнать об этом до переключения, а не после.
| Что | Как переносится | Что учесть |
|---|---|---|
| Сотрудники и оргструктура | Переносятся | Пароли задаются заново, доступы проверяются вручную |
| CRM: сделки, лиды, контакты, компании | Переносятся | Пользовательские поля и справочники сверяются отдельно |
| Задачи и проекты | Переносятся | Связи с чатами и старыми уведомлениями могут потеряться |
| Файлы на диске | Переносятся | Объём влияет на время переезда и требования к серверу |
| Бизнес-процессы и роботы | Переносятся с проверкой | Требуют перезапуска и тестирования на новом портале |
| Чаты и лента новостей | Переносятся частично | Историю переписки стоит выгрузить отдельно, если она критична |
| Приложения маркетплейса | Не все и не одинаково | Часть решений выпускается только для облака, наличие коробочной версии проверяется до переезда |
| Внешние интеграции | Настраиваются заново | Меняются адреса вебхуков, ключи и настройки на стороне внешних систем |
3. Подготовка инфраструктуры. Сервер или хостинг, домен, сертификат, почта, резервное копирование, мониторинг. Здесь же решается, кто будет обслуживать систему после запуска.
4. Перенос данных. Выполняется штатными средствами миграции с последующей сверкой. Проверяются количество записей, суммы по сделкам, вложения, связи между сущностями.
5. Перенос настроек и прав. Роли, права доступа к CRM и разделам, настройки воронок, шаблоны документов, справочники. Этот блок почти всегда требует ручной сверки.
6. Интеграции и приложения. Телефония, почта, сайт, интеграция с 1С, мессенджеры, внутренние системы. Каждая интеграция настраивается заново и проверяется отдельно.
7. Тестовый контур. Копия портала, на которой команда проверяет свои сценарии: менеджер проводит сделку, бухгалтер выставляет счёт, руководитель смотрит отчёты и аналитику. Ошибки ловятся здесь, а не в боевом режиме.
8. Параллельная работа и переключение. Несколько дней два портала живут одновременно, новые данные вносятся в новый. Затем облачный портал переводится в режим чтения, а после контрольного периода закрывается.
Реалистичный срок для компании среднего размера с несколькими интеграциями: от двух недель до полутора месяцев. Основное время уходит на интеграции и на сверку данных, а не на сам перенос.
Обратный переезд: с коробки в облако
Обратное движение встречается чаще, чем кажется. Типичный сценарий: коробку поставили несколько лет назад, админ уволился, обновления не ставились, сервер устарел, а бюджет на обслуживание не выделяется.
Переезд в облако проходит по той же логике, с двумя отличиями. Первое: доработки, сделанные правкой ядра, в облако не переедут, их придётся заменять приложениями и сценариями на REST API. Второе: если обновления давно не ставились, портал сначала приводят к актуальной версии, иначе миграция не пройдёт корректно.
Признаки того, что пора обратно: обновления не ставятся больше года, никто не помнит, где лежат бэкапы, портал регулярно недоступен, а изначальные причины выбора коробки уже неактуальны.
Частые вопросы
Что дешевле - облако или коробка
На горизонте одного года лицензия коробки может выглядеть выгоднее подписки. На горизонте трёх лет к ней добавляются продление, хостинг, администрирование и тестирование обновлений. Для небольших компаний без своего системного администратора облако обычно дешевле, для крупных с собственным IT-отделом расчёт индивидуален.
Можно ли перейти с облака на коробку без потери данных
Основные данные переносятся: сотрудники, CRM, задачи, файлы, бизнес-процессы. Часть вещей переносится не полностью или требует ручной настройки: история чатов, права доступа, интеграции. Перед переездом составляется список того, что переносится, и того, чем можно пожертвовать.
Работают ли приложения маркетплейса в коробке
Часть приложений выпускается в обеих версиях, часть только для облака. Составьте список используемых решений и проверьте наличие коробочной версии до начала переезда. Если критичного приложения в коробке нет, ищите замену или закладывайте бюджет на разработку аналога.
Нужен ли для коробки отдельный системный администратор
Нужен человек, который отвечает за сервер, обновления, резервные копии и восстановление после сбоев. Это может быть сотрудник в штате или подрядчик на абонентском обслуживании. Вариант «поставили и забыли» приводит к устаревшей и уязвимой системе.
Можно ли вернуться с коробки в облако
Да, обратная миграция выполнима и практикуется. Сложность зависит от объёма доработок: изменения, сделанные правкой исходного кода, придётся переделывать через API и приложения. Перед переносом коробку обновляют до актуальной версии.
Отличается ли функциональность облака и коробки
Базовая логика работы совпадает: CRM, задачи, документы, чаты, бизнес-процессы. Новые функции появляются в облаке раньше, а в коробку приходят с обновлениями. Коробка при этом даёт доступ к коду и возможность подключаться к внутренним системам напрямую.
Что делать дальше
Решение принимается не по ощущению, а по списку требований. Выпишите свои: где должны лежать данные, с какими системами нужна интеграция, сколько будет пользователей через два года, кто будет обслуживать сервер. Если в списке нет ни одного жёсткого требования к размещению или к правке ядра, оставайтесь в облаке и вкладывайте бюджет в процессы: настройку воронок, автоматизацию рутины и отчётность.
Если требования есть, посчитайте полную стоимость владения на три года и заранее проверьте, что все нужные приложения и интеграции существуют в коробочном варианте.
Мы в Aventra 12 лет работаем с Битрикс24, выпустили больше 75 приложений в маркетплейсе и входим в ТОП-5 разработчиков. Помогаем выбрать версию под конкретные требования, посчитать бюджет и провести переезд в обе стороны без остановки работы отделов: подробнее об услуге внедрения Битрикс24.