Перенос On-Premise Битрикс24 в облако: миграция портала и CRM

Вы хотите уйти от администрирования собственного сервера, сократить IT-инфраструктуру и использовать облачные функции, которых нет в коробке. Переход из On-Premise в облако имеет принципиальное ограничение: Битрикс24 не предоставляет официального инструмента импорта из коробочной версии. Перенос данных возможен только через REST API — в обратном направлении, чем при миграции из облака в коробку. За 5 лет мы выполнили более 30 таких проектов и знаем все подводные камни.

Облачный Битрикс24 даёт встроенные возможности, недоступные в коробке: WebRTC-телефония, полноценное мобильное приложение, автоматические обновления. Это снимает нагрузку с IT-отдела и сокращает затраты на серверное оборудование на 40-60%. Например, для компании с 50 сотрудниками экономия на серверном оборудовании и администрировании составляет от 40 000 до 60 000 рублей в месяц.

Данные, доступные для переноса

Не всё, что есть в коробке, доступно в облаке. Ключевые различия, которые нужно проверить до принятия решения:

Почему кастомные модули — главная проблема?

Если в коробке есть кастомные PHP-модули или компоненты, в облаке их нужно переписать как REST-приложения. Это основная сложность: такая доработка может перевесить стоимость самой миграции. На этапе аудита мы оцениваем каждый модуль и даём заключение.

Процесс переноса данных CRM

Данные выгружаются из коробки через REST API (он работает одинаково в обеих версиях) и загружаются в облако через тот же REST API. Последовательность:

1. Создать OAuth-приложение в облачном портале для аутентификации запросов.
2. Перенести пользователей — пригласить вручную через интерфейс или использовать user.add (только в On-Premise; в облаке добавление через API ограничено).
3. Пересоздать справочники: статусы сделок (crm.status.add), воронки (crm.dealcategory.add), пользовательские поля (crm.userfield.add).
4. Перенести CRM-данные: компании → контакты → лиды → сделки с сохранением маппинга ID.
5. Перенести файлы с Диска через disk.folder.uploadfile.

Скрипт миграции работает с двумя API-клиентами одновременно: один подключён к коробке (источник), другой — к облаку (приёмник).

Официальная документация Битрикс24 ограничивает частоту запросов к облачному API сильнее, чем к коробочному. На тарифе «Команда» — 2 запроса в секунду, на «Компания» — до 200. Для переноса больших объёмов реализуем rate limiting:

class RateLimiter { private float $lastRequest = 0; private float $minInterval; // секунды между запросами public function wait(): void { $elapsed = microtime(true) - $this->lastRequest; if ($elapsed < $this->minInterval) { usleep((int)(($this->minInterval - $elapsed) * 1_000_000)); } $this->lastRequest = microtime(true); } } 

Что такое лимиты API и как их обойти?

Лимиты API — ключевой фактор при планировании. В документации REST API Битрикс24 указано, что для облачных тарифов они ниже. RateLimiter выше — стандартное решение. На практике мы используем настраиваемый интервал и очередь заданий, чтобы не превышать лимит.

Облачный Битрикс24 в 2–3 раза снижает совокупную стоимость владения (TCO) по сравнению с коробочной версией за счёт исключения серверного оборудования и его администрирования.

Что входит в работу?

• Аудит текущей конфигурации: инвентаризация модулей, пользовательских полей, бизнес-процессов.
• Согласование плана миграции: какие данные переносим, что переписываем.
• Разработка скриптов переноса: с учётом rate limiting и маппинга ID.
• Тестовый прогон: на копии данных, проверка целостности.
• Параллельная работа: 2–4 недели совместного использования коробки и облака.
• Обучение сотрудников: работа с новым интерфейсом и REST-приложениями.
• Пост-миграционная поддержка: 2 недели после переключения.

Чек-лист перед миграцией:

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

Период параллельной работы

Рекомендуемый период параллельной работы — 2–4 недели. В это время новые данные вносятся в облако, а старая коробка остаётся в режиме read-only для сверки. По истечении периода — деактивация коробки и освобождение сервера. Это исключает простой портала и позволяет проверить целостность данных.

Типичные сроки

Стоимость миграции варьируется от 200 000 до 1 000 000 рублей в зависимости от объёма данных и сложности кастомизаций. Закажите аудит вашего портала — мы определим точный бюджет и сроки миграции. Свяжитесь с нами для консультации.