Переход между редакциями 1С-Битрикс без потери данных

Сайт вырос: каталог больше не помещается в текущую редакцию, нужны несколько типов цен, распределённые склады, полноценная работа с оптом. Возникает задача перейти на старшую редакцию 1С-Битрикс. И тут же — главный страх: «а не потеряем ли мы данные и не ляжет ли сайт?». Хорошая новость: переход на старшую редакцию не разрушает данные. Плохая — сделанный впопыхах, без бэкапа и теста, он всё же способен доставить неприятности.

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

Зачем менять редакцию

Редакцию меняют, когда текущей перестаёт хватать. Причины почти всегда связаны с ростом бизнеса и усложнением процессов, а не с «хочется новее».

• Нужен интернет-магазин. Переход с редакции без коммерции на редакцию с торговым каталогом.
• Несколько типов цен и складов. Опт, дилеры, региональные цены, распределённые остатки.
• B2B-функционал. Группы клиентов, персональные условия, расширенные скидки.
• Модули старшей редакции. Функции, доступные только в «Бизнесе» или выше.

Важно отделять «нужна другая редакция» от «нужны доработки». Иногда задачу решает не смена лицензии, а грамотная настройка или разработка на текущей редакции. Поэтому перед покупкой апгрейда полезно понять, чего именно не хватает.

Как устроены редакции и лицензия

1С-Битрикс поставляется редакциями — наборами модулей под разные задачи: от простого сайта до крупного интернет-магазина и корпоративного портала. Редакция определяется лицензионным ключом: он «включает» доступный набор модулей.

Ключевое для понимания перехода: младшие и старшие редакции построены на одном ядре. Старшая — это та же система плюс дополнительные модули (торговый каталог, расширенная коммерция и т. д.). Поэтому переход «вверх» — это активация нового ключа и подгрузка недостающих модулей, а не миграция на другую платформу. Данные и структура при этом остаются на месте.

Что происходит с данными при апгрейде

Главный вопрос — судьба данных. При переходе на старшую редакцию база данных, файлы, инфоблоки, пользователи и настройки не трогаются. Система лишь получает доступ к новым модулям и, при необходимости, доустанавливает их таблицы.

Отсюда правило: относитесь к переходу как к любому значимому изменению на проде — с резервной копией, тестовым прогоном и планом отката. Тогда «без потери данных» — не надежда, а гарантированный результат.

Сравнение редакций для магазина

Чаще всего переходят между коммерческими редакциями. Ниже — ориентировочное сравнение по типовым потребностям магазина (точный состав модулей уточняйте по актуальному описанию редакций).

Практический ориентир: небольшому магазину хватает «Малого бизнеса», а при росте ассортимента, появлении оптовых сценариев, нескольких складов и групп цен переходят на «Бизнес». Именно потребность в этих механизмах чаще всего и запускает переход.

Подготовка: бэкап и тестовая копия

Переход начинается не со смены ключа, а с подготовки. Два обязательных шага, без которых к апгрейду не приступают.

1. Полный бэкап. Резервная копия базы данных и файлов на момент до перехода, с проверкой, что копия восстанавливается.
2. Тестовая копия сайта. Развёрнутая копия проекта на отдельном окружении, где апгрейд прогоняют до продакшена.

Тестовый прогон — самая ценная часть подготовки. На копии вы активируете новую редакцию, доустанавливаете модули и проверяете, что ничего не сломалось, — и только убедившись, повторяете на боевом сайте. Про то, как удобно держать окружения и разворачивать копии, — в статье о хостинге и BitrixVM.

Инвентаризация доработок

Главный источник проблем при апгрейде — нештатные доработки. Если функционал расширяли правильно (отдельные модули и обработчики событий), переход пройдёт гладко. Если правили файлы ядра или чужих модулей, новые модули старшей редакции могут с ними конфликтовать.

Перед переходом стоит:

• Составить список доработок. Что именно и где дописано в проекте.
• Найти правки в ядре. Изменения в системных файлах — кандидаты на конфликт.
• Проверить совместимость. Как доработки поведут себя рядом с новыми модулями.
• Изолировать критичное. Правки, вшитые в чужой код, вынести в отдельные обработчики.

Правильно оформленные доработки — залог безболезненных апгрейдов не только сейчас, но и в будущем. Как расширять Битрикс через события и модули, не трогая ядро, мы разбирали в статьях о разработке модуля и работе с D7 и ORM.

Порядок смены редакции

Сама техническая процедура несложна, если подготовка сделана. Общая последовательность (названия пунктов зависят от версии):

1. Подготовьте прод. Свежий бэкап, по возможности — технологическое окно с низким трафиком.
2. Активируйте новый ключ. Введите лицензионный ключ старшей редакции в настройках системы обновлений.
3. Загрузите модули. Через систему обновлений подтянутся недостающие модули новой редакции.
4. Установите модули. Активируйте и установите добавившиеся модули (например, торговый каталог).
5. Проверьте админку. Убедитесь, что новые разделы появились, ошибок установки нет.

После этого функционально сайт уже на новой редакции, но работа не окончена: новые модули нужно настроить под ваши процессы.

Настройка новых модулей

Новые модули приходят с настройками по умолчанию, которые почти наверняка не совпадают с вашими процессами. Основное внимание — коммерческой части.

• Типы цен. Заведите нужные типы (розница, опт, дилер) и права групп на их просмотр.
• Склады. Настройте склады и привязку остатков, если появилась многоскладовость.
• Торговый каталог. Свяжите инфоблок каталога с торговым каталогом, настройте единицы, наличие, цены.
• Скидки и правила. Перенесите или заведите правила работы с корзиной, если они появились в редакции.

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

Проверка обмена с 1С

Появление торгового каталога, типов цен и складов напрямую влияет на обмен с учётной системой. После перехода обмен CommerceML почти всегда требует проверки и донастройки.

1. Сопоставьте типы цен. Убедитесь, что цены из 1С ложатся в правильные типы на сайте.
2. Проверьте склады. Остатки по складам приходят и раскладываются корректно.
3. Сверьте свойства. Свойства товаров и единицы измерения передаются без потерь.
4. Прогоните тестовый обмен. Сделайте пробную выгрузку и сверьте результат.

Часто именно ради полноценного обмена с распределёнными складами и группами цен и затевают переход. Про безопасную передачу данных между системами полезно почитать материал о REST, вебхуках и безопасности в Битрикс.

Тестирование после перехода

Перед тем как считать переход завершённым, сайт прогоняют по ключевым сценариям. Апгрейд затрагивает коммерцию, поэтому проверяют в первую очередь её.

• Каталог и цены. Товары отображаются, цены и наличие корректны для разных групп.
• Корзина и заказ. Оформление проходит полностью, скидки и правила применяются верно.
• Личный кабинет. История, повторные заказы и персональные условия на месте.
• Обмен. Заказы уходят в 1С, статусы и оплаты возвращаются.
• Доработки. Кастомный функционал работает рядом с новыми модулями.

Ручную проверку полезно дополнить автоматическими тестами и включить их в процесс выката, чтобы будущие обновления не ломали коммерцию незаметно — про это в статье о CI/CD и деплое в 1С-Битрикс.

Откат, если что-то пошло не так

Даже при хорошей подготовке нужен план на случай проблем. Именно ради него делают бэкап и тестовый прогон.

• Восстановление из бэкапа. При критичной проблеме сайт возвращают к состоянию до перехода.
• Точка невозврата. Заранее определяют, до какого момента откат безопасен.
• Изоляция изменений. Пока идёт проверка, новые процессы не запускают в бой полностью.
• Журнал действий. Фиксируют, что именно меняли, чтобы точечно откатить проблемный шаг.

На практике при выполненном тестовом прогоне откат почти не требуется — большинство проблем ловится на копии. Но наличие рабочего плана отката превращает переход из «страшного» в рутинную операцию.

Частые ошибки

• Апгрейд без бэкапа. Любой сбой становится потенциальной катастрофой.
• Смена редакции сразу на проде. Без тестового прогона конфликты доработок всплывают на живом сайте.
• Игнорируют правки в ядре. Нештатные изменения конфликтуют с новыми модулями.
• Не настроили новые модули. Каталог и цены остаются в состоянии «по умолчанию».
• Забыли про обмен с 1С. После апгрейда цены и склады перестают сопоставляться.
• Нет проверки после перехода. Проблемы в корзине и заказе замечают уже клиенты.
• Путают апгрейд и даунгрейд. Пытаются «понизить» редакцию и теряют данные модулей.

Чек-лист перехода

1. Потребность подтверждена. Ясно, каких именно модулей не хватает и что даст старшая редакция.
2. Бэкап сделан. Есть проверенная копия базы и файлов, которая восстанавливается.
3. Тестовая копия готова. Апгрейд прогнан на копии, конфликты пойманы.
4. Доработки проверены. Правки в ядре найдены, критичное изолировано.
5. Редакция сменена. Новый ключ активирован, модули установлены без ошибок.
6. Модули настроены. Типы цен, склады и торговый каталог заведены под процессы.
7. Обмен проверен. Цены, склады и свойства из 1С сопоставляются верно.
8. Сценарии протестированы. Каталог, корзина, заказ, кабинет и обмен работают.

Вывод

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

Основная работа — не в самой смене ключа, а вокруг неё: инвентаризация доработок, настройка новых коммерческих модулей и перепроверка обмена с 1С. Сделайте эти шаги аккуратно, и переход пройдёт незаметно для клиентов, а магазин получит нужные типы цен, склады и B2B-возможности. Если проект крупный и с историей, разумно провести апгрейд вместе с аудитом — так вы закроете техдолг и получите чистую основу для роста.