Компания 1С-Битрикс неожиданно прекратила оказывать услуги по переносу данных из облачной версии Битрикс24 в коробочную. Теперь компании, которые начали пользоваться облачной версией Битрикс24 и планируют перейти на коробочную, должны переезжать самостоятельно. Мы прошли этот путь и готовы поделиться опытом.
Зачем нужно переезжать на коробку Битрикс24?
В Битрикс24 реализовано две версии: облачная и коробочная.
Облачная доступна к работе сразу и не требует от компании наличия собственных серверов, данные хранятся в защищенных дата-центрах. Эта версия легко настраивается и отлично подходит для начала работы.
Если компании нужны более широкие возможности системы, тогда требуется коробочная версия. Она устанавливается на серверы компании, где хранятся данные. Исходный код открыт, можно вносить изменения с помощью модулей или через PHP и JavaScript. Коробочная версия подходит компаниям, которым важна закрытая среда для хранения данных и интеграция с внутренними системами.

Если компания начала работать в облаке, но потребовались дополнительные возможности коробки, то переехать можно, но теперь уже без технической поддержки компании 1С-Битрикс.
Сложности самостоятельного переезда из облака в коробку
Поскольку коробочная версия устанавливается на серверы компании, то необходимы отдельные скрипты для переноса всех сущностей и данных с портала: задачи, пользователи, лиды, сделки, контакты, компании, счета, справочники, смарт-процессы, события и многое другое. Все сущности должны быть перенесены с учетом связей и настроек.
Наша задача усложнялась еще и масштабом портала заказчика.

Оценив объем информации, мы начали с изучения API: хватит ли его возможностей, чтобы выгрузить все необходимые данные?
Облачные решения Битрикс24 предоставляют удобный доступ к данным через API, но важно учитывать жесткие ограничения: лимиты на количество запросов в секунду, размер выборки и другие параметры. Скрипт, который соблюдал бы лимиты и постепенно выгружал данные, при учете масштабов портала клиента привел бы к многодневному или даже к многонедельному простою, что, конечно же, было неприемлемо долго.
Мы пробовали использовать fast_bitrix24 – библиотеку, которая ускоряет работу с API. И она действительно работает быстро, но недолго. Лимиты Битрикс24 остаются жесткими, а при превышении лимита запросов API блокируется, и приходится долго ждать восстановления доступа.
Битрикс24 не раз отмечали, что их REST API не предназначен для работы с большими данными, но других альтернатив нет, поэтому мы нашли решение, как избежать потерь и длительных простоев.
Как мы выстроили процесс и с чем столкнулись?
Мы проанализировали работающую систему клиента, сущности и данные в Битрикс24, с которыми работали сотрудники, определили ключевые технические требования и оценили существующие ресурсы.
Разработав первый прототип системы переноса, оценив скорости, мы поняли, что существующие лимиты все-таки не позволят нам в разумные сроки решить задачу и обсудили с заказчиком объемы переносимых данных. В ходе обсуждения решили переносить полностью только компании, контакты, сделки и комментарии, а задачи и звонки сократить.
Далее мы оценили производительность сервера, который принимает данные. Скорость скачивания составляла 5 задач в секунду, а скорость вставки на сервере – 2 задачи в секунду. Поэтому при использовании стандартной коробочной API Б24 нам пришлось внести временные правки в ядро, чтобы исключить лишние проверки данных.
Неожиданной сложностью в процессе стала работа с файлами в Битрикс24.

Система использует два принципиально разных типа файлов: файлы с Диска, доступные через стандартное API, и так называемые «простые файлы», которые физически хранятся в директории /upload/main/ в коробочной версии.
Основная сложность заключалась в том, что внутри портала эти типы файлов были хаотично перемешаны, в разных сущностях могли встречаться оба варианта одновременно. Это создавало серьезные проблемы при обработке, так как для «простых файлов» не существовало полноценного API. Наш первоначальный прототип, рассчитанный на работу через веб-хуки, оказался неэффективным, и нам пришлось параллельно разрабатывать отдельное приложение специально для работы с этим типом файлов.
Дополнительные трудности возникли при массовой обработке файлов: их количество исчислялось сотнями тысяч. Казалось бы, решение напрашивалось само собой – распараллелить процесс скачивания. Однако мы вновь уперлись в ограничения API, ведь каждое скачивание файла также считалось отдельным запросом.
Особенно неприятным сюрпризом стало ограничение временных токенов доступа. Полученные через приложение ссылки на «простые файлы» были действительны всего один час. Это вынуждало нас разрабатывать сложный алгоритм: в течение каждого часа скачивать максимально возможное количество файлов, затем заново получать полный список, сравнивать его с предыдущей выборкой и докачивать оставшиеся файлы, повторяя этот цикл до полного завершения процесса.
В конечном итоге, мы перенесли все сущности и данные, сохранили связки и настройки и избежали длительного простоя.
Результаты и главные выводы
В результате миграции компания клиента перешла на коробочную версию Битрикс24 с сохранением всех настроек, сущностей и данных облачной версии.
Наш опыт показал, что даже самые сложные задачи по переносу данных решаемы при правильной технической экспертизе и системном подходе.
Вот главное, что помогло нам осуществить переезд Битрикс24 из облака в коробку:
- Согласование разумных объемов переносимых данных.
- Разделение процесса переезда на относительно независимые этапы: компании, контакты, лиды, сделки, задачи. После добавления задач – добавление чек-листов и комментариев.
- Профилирование коробки на вставках данных, что позволило внести временные правки ядра, которые существенно повысили скорость импорта. Также был предоставлен очень быстрый «железный» сервер с SSD-дисками в RAID-массиве.
- Деление импорта файлов на два этапа: сначала создание пустых файлов без реального скачивания, а затем скачивание содержимого файлов.