В 2023 году компания 1С-Битрикс анонсировала, что с 1 сентября нельзя запросить у неё выгрузку бэкапа с облака. Но компании-разработчики и партнёры вендора частично могут перенести процессы и данные между версиями системы. Расскажем, как мы написали мигратор, который «вытягивает» данные и переносит их с одного портала Битрикс24 на другой.
Сроки на бэкап
Ранее все, кто хотел перейти с коробки на облако, запрашивали у компании 1С-Битрикс бэкап. В течение недели пользователь системы переносил полученные данные на коробку Битрикс24, а потом продолжали настраивать систему под свои нужды в обычном темпе. По условиям вендора, компания могла запрашивать бэкап только 1 раз. Поэтому те, кто решился на переход с одной версии Битрикс24 на другую, относились к этому вопросу серьёзно и выполняли миграцию оперативно.
В течение 2023 года вендор неоднократно анонсировал, что с сентября такой возможности не будет. Компания-разработчик системы не будет формировать бэкап с облака для последующего переноса на коробочную версию программы.
В этом процессе были особенности. Вендор передавал полный бэкап. Это значит, что компания копирует не только данные, но и ядро продукта со всеми системными модулями и их настройками. А ядра в обеих версиях Битрикс24 отличаются, и когда наступает момент переноса выгруженной информации в коробку, то она начинает «сбоить». Это приводит к массе ошибок в системе, которые влияют на репутацию вендора, лояльность к продукту и на дополнительную работу по налаживанию системы.
Нужно переехать из облачного Битрикс24 в коробку?
Давайте обсудим
Мы в своём решении не переносим данные вместе с настройками программы (ядро) из облака в коробку, а лишь загружаем накопленные сущности (сделки, контакты, компании, задачи и т.д.) системы в базу данных нового портала Битрикс24. Поэтому ошибок в работе платформы не возникает, так как далее не надо:
- Переустанавливать и перенастраивать системные модули системы (Задачи, Управление масштабированием, Маркет, Диск Битрикс24) для их корректной настройки.
- Исправлять возможные ошибки в пути до файлов системы, обновлением коробочного продукта Битрикс24.
- Проводить переиндексацию и сброс паролей пользователей.
Однако есть и обратная сторона — перенести можно большую часть данных, но не всё.
Решаем проблему переноса данных с облака на коробку Битрикс24
Многие компании не успели перейти с облака на коробку, но хотят это сделать. Сейчас у них есть два варианта:
- Обратиться к профильным компаниям, которые занимаются разработкой на Битрикс, для создания специального модуля (мигратора).
- Купить коробку и вручную перенести все записи и настройки.
Второй вариант подходит в том случае, если у компании нет финансовой возможности оплатить услуг разработчика, который быстро и качественно перенесёт бэкап в коробку; есть время, чтобы сделать всё вручную; а также если в облаке не успело накопиться много информации.
Во всех остальных случаях рекомендуем обращаться к профессиональным разработчикам, которые сформируют бэкап и без потерь данных перенесут его на коробочный Битрикс24.
Мигратор для боевой коробки Битрикс24
Мы расскажем, как разработали модуль для выгрузки бэкапа с облачной версии на коробочную для нашего клиента.
Мигратор - это код, который размещается на коробке у клиента и «обращается» через RestAPI к облачному порталу Битрикс24, откуда необходимо выполнить миграцию данных. Он «вытягивает» информацию и записывает её на коробку. Казалось бы, всё просто, но это не так.
На данный момент, мигратор — это единственный способ вытащить информацию из облака. Такой мигратор может написать любой квалифицированный разработчик. Но здесь важно учитывать опыт переноса данных: знать какие есть REST методы, как грамотно их применить, как в дальнейшем настроить систему. Мы уже делали бэкап на сложных проектах. Кроме того, у нас есть готовый модуль, а значит, его можно «допилить» под индивидуальные нюансы в системе пользователя и сократить срок переноса данных в новом проекте. Комментарий от Максима Жуланова, тимлида команды разработки Luckru
В данном кейсе наша команда выполняла миграцию на уже действующий портал со своими сущностями и настройками. Помимо, миграции нам необходимо было правильно объединить настройку и бизнес-логику объединяемых порталов. Сложность состояла в том, что в допиленной коробке Битрикс24 был ряд проблем: не оптимизирован код, а также была интеграция со сторонней программой, которая работала с перебоями. Кроме того, коробка на момент переноса, была в «боевом» режиме, то есть клиент уже настроил Битрикс24 под свои процессы и загрузил новую информацию. Это всё нужно было учитывать.
При этом выгрузка информации из Битрикс24 — не всегда простая задача. Мы задействовали все возможные RestAPI методы, но даже при таком раскладе они не позволяют выгрузить всю информацию из системы. Ниже пример, что можно и нельзя выгрузить с помощью доступных методов ↓
| Можно выгрузить | Нельзя выгрузить |
|---|---|
| сделку, все её поля и связи с другими сущностями, все элементы таймлайна этой сущности (комментарии, дела, записи входящих/исходящих звонков, задачи, сгенерированные документы) | историю по сделке, которая расположена во вкладке История |
| универсальный список, все элементы и настройки этого списка | файлы, которые прикреплены к элементам этого списка, если файлы не сохранены в Диске Битрикс24. |
При этом важно уметь грамотно применять методы, чтобы выгрузить данные быстро и целостно, минуя ограничения RestAPI методов.
Например, если Сделки в обеих версиях системы сопоставить легко, то Задачи в процессе переноса можно потерять. А ведь к задачам нужно прикрепить комментарии, а к ним — файлы, которые сохраняются отдельно. Поэтому надо уметь правильно «вытягивать» информацию, особенно если объём данных большой (например, >50 Гб).
В дальнейшем требовалось проверить перенос информации, сохранение связей сущностей после миграции и протестировать работу системы. Ошибки выявляется с помощью логирования, а также можно вручную «просмотреть» структуру данных (сделки, контакты, сущности системы). Автоматизировать такую проверку невозможно.
Почему надо обратиться к нам за переносом Битрикс24 с облака в коробку:
- Уверенность в результате. Мы используем тестовые сервер и аккаунт, на которых пробуем миграцию данных. Не переносим данные на сервер клиента, пока не убедимся в корректности миграции.
- Нужно быстро перейти на коробочный портал системы. У нас уже есть готовое решение. Остаётся подкорректировать его под индивидуальные условия проекта и использовать по назначению. Поэтому организовать процесс можно в короткие сроки.
- Есть нюансы, которые не под силу другим разработчикам. В начале проекта проводим техаудит с клиентом и выясняем исходные данные. При необходимости (боевая коробка, сложные интеграции и другое) прорабатываем пути решения для беспроблемного перехода между версиями системы.
Варианты миграции в Битрикс24
Итак, возможны две ситуации с переносом: на чистую (без настроек, информации и еще не работающую) и боевую (настроенную, с частью данных, работающую) коробки.
Конечно, первый вариант — идеальный. В этом случае можно быстро, легко и без проволочек перенести всё из облачного портала Битрикс24 в коробочный.
Однако чаще бывает именно второй вариант: коробку уже купили и даже настроили под рабочие процессы, сохранили документы, информацию, контакты. И в неё же требуется добавить всё то, что уже настроено и сохранено на облачном портале. По времени подобный проект обычно занимает от 3 дней до недели (перенос + тестирование).
Требования для качественного переезда с облачного на коробочный Битрикс24
Компания-пользователь системы перед миграцией данных должна подготовить почву:
- Выбрать надёжного провайдера по услугам аренды сервера.
- Проверить объём памяти на сервере.
- Не настраивать коробку (желательно).
- Выбрать подрядчика и рассказать обо всех интеграциях, а также дать доступ к коду систем, чтобы он мог оценить время на проект и разработать стратегию при необходимости.
Чем больше разработчик знает о системе клиента, тем меньше вероятность затягивания проекта и риска ошибок. Если у вас остались вопросы или хотите заказать услугу переезда между версиями Битрикс24, оставьте заявку, и наши менеджеры перезвонят.
