Переезд Битрикс24 из облака в коробку: спасли историю на вайбкоде
Крупная производственная компания переезжала с облачного Битрикс24 на коробочный. Стандартные миграторы перенесли почти всё — но не ленты рабочих групп, где годами фиксировалась вся история проектов: вехи, артефакты, обсуждения. Мы собрали на вайбкоде загрузчик, который восстановил эти ленты вместе с файлами и, самое главное, с исходными датами сообщений. Историю проектов удалось спасти целиком.
Клиент и задача
Наш клиент — крупная производственная компания с большим количеством проектов. Проекты она ведёт полноценно в Битрикс24, и в какой-то момент приняла решение переехать с облачной версии на коробочную — на свой сервер.
Для переезда есть готовые миграторы, которые переносят данные с портала на портал. Большую часть данных они перенесли штатно. Но, как это часто бывает, «дьявол оказался в деталях».
Проблема: миграторы перенесли не всё
Часть исторических данных при переезде потерялась. В первую очередь — ленты рабочих групп: записи вместе со ссылками на файлы. Сами файлы перенеслись, а вот ссылки на них в лентах — нет. И это было бы полбеды, если бы не второй, куда более болезненный момент — даты сообщений.
«В лентах групп клиент фиксировал вехи по проекту, артефакты, вёл обсуждения — качественно использовал ленту, чтобы фиксировать важные для себя события. Ему было довольно болезненно, что эти данные не перенеслись». — Иван Шум, соучредитель и генеральный директор Соль
Клиент уже был готов махнуть на это рукой — мол, сами понимали, на что шли при переезде. Но для него это была потеря по-настоящему ценной истории: вся хронология проектов жила именно в этих лентах.
Почему стандартный перенос не спасал
Здесь была фундаментальная сложность. Если переносить ленты через REST API, как это делают приложения-мигранты, то дата создания сообщения становится датой переноса.
«Когда мы через API что-то публикуем, дата создания есть дата создания: когда создали — тогда и создали». — Иван Шум, соучредитель и генеральный директор Соль
То есть вся хронология проектов — что и когда происходило — просто схлопнулась бы в один день. Плюс нужно было восстановить потерянные ссылки на файлы и увязать между собой огромное количество идентификаторов: на старом портале одни ID пользователей, файлов и групп, на новом — другие, и всё это нужно было корректно сопоставить.
Решение: восстановление лент на вайбкоде
Мы выгрузили исторические данные из облака через REST — получили массив XML-файлов с описанием каждой группы, каждой ленты и всех взаимосвязей между ними. А дальше написали загрузчик с помощью нейросети.
Почему снова нейросеть? Потому что задача упиралась в огромное количество взаимосвязей: сопоставить пользователей, файлы и группы старого и нового порталов через множество промежуточных таблиц. Вручную это неподъёмно и чревато ошибками.
Ключевых момента в загрузчике было два:
- Сопоставление идентификаторов. Загрузчик сам сводил ID старого и нового порталов — кто есть кто, какой файл к чему относится, какая лента какой группе принадлежит.
- Правка дат прямо в базе данных. Раз API не даёт задать историческую дату, у приложения был отдельный шаг работы с БД — оно проставляло правильные даты по связанным таблицам. А таблицы в базе Битрикс24 по структуре непростые, так что этот шаг требовал аккуратности.
Нейросеть провела загрузку и проконтролировала результат: все данные легли целиком, без дублей, ничего не потерялось. После этого мы перепроверили всё ещё и вручную — убедились, что записи действительно встали на свои места, с правильными датами и файлами.
Чем это отличается от стандартного переезда:
| Стандартный перенос облако → коробка | Восстановление на вайбкоде | |
|---|---|---|
| Ленты рабочих групп | часть теряется | восстановлены полностью |
| Ссылки на файлы в лентах | не переносятся | восстановлены |
| Даты сообщений | становятся датой переноса | сохранены исторические |
| Сопоставление ID (старый ↔ новый портал) | вручную или никак | автоматически, через промежуточные таблицы |
| Контроль целостности | на глаз | нейросеть + ручная перепроверка |
Стандартный переезд против восстановления на вайбкоде для переноса Битрикс24 из облака в коробку
Сложности
Самым тонким местом были именно исторические даты. Битрикс24 при публикации через API всегда ставит текущую дату, поэтому пришлось идти на уровень базы данных и аккуратно править даты по связанным таблицам — а структура таблиц Битрикс24 к простым не относится. Плюс объём взаимосвязей между старым и новым порталами: без автоматического сопоставления ID задача превратилась бы в бесконечную ручную сверку.
Результат
«Клиент не потерял действительно ценные для него данные и сведения о ходе проектов. А мы эту задачу сделали ещё и в разумном бюджете, и достаточно оперативно». — Иван Шум, соучредитель и генеральный директор Соль
История проектов клиента сохранилась полностью — с файлами, обсуждениями и, главное, с реальными датами. То, что стандартный переезд оставил бы за бортом, вайбкод-загрузчик вернул на свои места, целостно и без дублей.
Что дальше
Тот же подход — выгрузка через REST, вайбкод-загрузчик с сопоставлением ID и правкой дат в базе — применим к любой сложной миграции, где важно сохранить не только сами данные, но и их историю. Стандартные миграторы закрывают типовое, а всё нестандартное добираем на вайбкоде.
Кому это пригодится
Решение подойдёт компаниям, которые переезжают с облачного Битрикс24 на коробочный (или между порталами) и не хотят потерять историю: ленты групп, вложения, хронологию проектов. Особенно если в лентах и обсуждениях лежит важная рабочая история, а стандартные миграторы её игнорируют.
Признак, что у вас та же боль: при переезде часть данных «не доехала» или у перенесённых записей слетели даты — и это не мелочь, а потерянная история работы.
Часто задаваемые вопросы
Сохраняются ли даты сообщений при переносе Битрикс24 из облака в коробку?
При стандартном переносе через API — нет: дата создания становится датой переноса, и хронология слетает. Мы решаем это отдельным шагом: загрузчик правит исторические даты прямо в базе по связанным таблицам, поэтому лента сохраняет реальные даты событий.
Что обычно теряется при переезде облако → коробка?
Типовые данные миграторы переносят, но исторические детали часто выпадают: записи в лентах групп, ссылки на файлы внутри лент, даты сообщений. Это и есть то, что мы восстанавливаем отдельно.
Можно ли восстановить ленты групп с файлами после миграции?
Да. Мы выгружаем ленты и связи из старого портала, сопоставляем идентификаторы пользователей, файлов и групп со новым порталом и загружаем всё обратно — с вложениями и исходными датами.
Не появятся ли дубли при таком восстановлении?
Нет. Загрузку ведёт и контролирует нейросеть — следит за целостностью и уникальностью записей, а после мы дополнительно проверяем результат вручную. В этом кейсе всё загрузилось без дублей и потерь.
Почему для этого использовали вайбкод, а не обычную разработку?
Задача нестандартная и завязана на множество взаимосвязей и на работу с базой. На вайбкоде такое решение собирается быстрее и дешевле, чем классическая разработка скрипта с нуля, — при том же контроле качества.
Что такое вайбкод и какие задачи по Битрикс24 на нём решают?
Вайбкод — это сборка решений через описание задачи обычными словами: ИИ пишет код, а специалист направляет и проверяет. На вайбкоде мы собираем то, чего нет в коробке: миграции и загрузчики данных, отчёты и дашборды, чат-ботов, интеграции — например, бота-юриста для проверки договоров.
Можно ли на вайбкоде дописать то, чего не хватает после переезда в коробку?
Да. После миграции часто вылезают пробелы — недоехавшие данные, потерянные связи, отчёты, которых не было. Всё это добирается точечно на вайбкоде, не переделывая портал заново.
Итог
Переезд Битрикс24 из облака в коробку не обязан стоить компании её истории. Там, где стандартные миграторы теряют ленты, файлы и даты, задачу можно закрыть на вайбкоде — собрать загрузчик, который восстановит данные со всеми связями и реальными датами. Если вам предстоит миграция и жаль потерять историю проектов — обсудите задачу с командой Соль: оценим, что переносится штатно, а что нужно добрать отдельно, и перенесём аккуратно.
