Обновление 1С-Битрикс: миграция на новую версию без потерь

Почему миграция на новую версию 1С-Битрикс — это не простая задача

Клиент жалуется: после обновления ядра сайт падает с белым экраном. Адаптация шаблонов каталога занимает недели. Знакомая ситуация? Один из наших клиентов — интернет-магазин с 15 000 товаров и кастомной интеграцией с 1С — пытался обновиться самостоятельно и потерял две недели на отладку белого экрана. После обращения к нам миграция заняла три дня, а простой продакшена не превысил четырёх часов. Мы помогаем компаниям перенести сайты на актуальные версии 1С-Битрикс без потери данных и падения позиций. Это не просто кнопка «Обновить» — за годы работы накапливаются нестандартные модули, устаревшие API, шаблоны на старом ядре. Без подготовки обновление может закончиться катастрофой. Наш подход — поэтапная миграция с тестовым стендом и возможностью отката. Мы гарантируем бесшовный переход и экономию до 30% бюджета за счёт предотвращения простоев. Окупаемость миграции достигается за счёт повышения производительности и снижения затрат на поддержку.

Что меняется между версиями?

Битрикс активно мигрирует со старого ядра (D5/kernel) на D7. Ключевые поломки при обновлении:

• Старый API каталога (CIBlockElement, CCatalog) заменяется на ORM-классы Bitrix\Iblock\ElementTable, Bitrix\Catalog*
• CUser частично заменён на \Bitrix\Main\User* — методы авторизации изменились
• Компонент bitrix:catalog в новых версиях переработан с поддержкой SKU, старые шаблоны требуют адаптации
• Модуль sale — версия 17+ изменила архитектуру заказа (Order, Basket, Shipment — объекты вместо массивов)
• PHP — последние версии Битрикс требуют PHP 8.0+, старый код с preg_replace('/e', ...) и each() падает

Официальная документация 1С-Битрикс рекомендует перед обновлением провести полный аудит кода. Наш метод обновления вдвое быстрее самостоятельного за счёт автоматизированных скриптов проверки совместимости. Источник: официальный сайт 1С-Битрикс.

Почему обновление требует тестового стенда?

Тестовый стенд — это полная копия сайта на отдельном сервере или домене. Здесь мы проводим все опасные операции, не рискуя продакшеном. Без стенда вы рискуете получить простой на несколько дней. Мы поднимаем стенд за несколько часов, синхронизируем базу данных и файлы, затем поэтапно обновляем систему. Каждый шаг фиксируется, и при ошибке мы откатываемся на предыдущую версию. Это позволяет выявить все проблемы до переноса.

Как подготовить кастомные модули к миграции?

Кастомные модули — главная головная боль при обновлении. Для каждого модуля из Маркетплейса проверяем совместимость на портале разработчика. Если обновления нет — связываемся с автором или переписываем функционал. Для своих модулей проводим рефакторинг: заменяем устаревшие вызовы на D7 ORM. Например:

// Было (старое ядро):
$dbResult = CIBlockElement::GetList([], $filter, false, false, $select);

// Стало (D7 ORM, современные версии Битрикс):
$result = \Bitrix\Iblock\ElementTable::getList([
    'filter' => $filter,
    'select' => $select,
]);

Адаптация шаблонов каталога занимает 40–60% всего времени миграции. В новых версиях компонента bitrix:catalog структура $arResult изменилась — переменная $arResult['ITEMS'] заменена на $arResult['CATALOG_ITEMS'] с новой структурой торговых предложений.

Этапы миграции: от аудита до продакшена

Этап 1. Аудит текущего состояния. Перед любым обновлением — полная инвентаризация:

• Список нестандартных модулей (/local/modules/, /bitrix/modules/ — кастомные), включая инфоблоки (v2.0), HL-блоки, агенты и события
• Список модулей из Маркетплейса с проверкой совместимости с целевой версией
• Кастомные шаблоны компонентов в /local/templates/ и /bitrix/templates/
• Использование устаревших функций: grep -r "CIBlockElement::" /local/ --include="*.php"
• PHP-версия на сервере

Этап 2. Тестовый стенд. Поднимается полная копия сайта на отдельном сервере или домене. На стенде:

1. Делается резервная копия файлов и базы данных
2. Выполняется поэтапное обновление через административную панель (Обновление системы)
3. Фиксируются все ошибки из /bitrix/cache/ и логов PHP

Этап 3. Совместимость модулей. Для каждого стороннего модуля из Маркетплейса — проверить версию совместимости на портале разработчика. Если обновления нет — связаться с разработчиком или переписать функционал. Для кастомных модулей — ручная адаптация.

Этап 4. Адаптация шаблонов. Шаблоны компонентов каталога — главная точка боли. В новых версиях компонент bitrix:catalog сменил структуру $arResult. Переменная $arResult['ITEMS'] заменена на $arResult['CATALOG_ITEMS'] с новой структурой торговых предложений. Адаптация шаблона каталога занимает 40–60% всего времени миграции.

Этап 5. Тестирование функциональности. Проверяем все сценарии:

• Добавление товара в корзину
• Оформление заказа (каждый шаг)
• Личный кабинет — история заказов
• Поиск по каталогу
• Фильтрация товаров
• Оплата (все подключённые платёжные системы)
• Синхронизация с 1С через CommerceML (если используется)
• Бизнес-процессы (Bizproc) и роботы
• Email-уведомления
• Административная часть — редактирование товаров

Этап 6. Перенос на продакшен. Оптимальный сценарий:

1. Ночное обслуживание (уведомить пользователей заранее)
2. Резервная копия продакшена
3. Обновление Битрикс через update_system_step.php с последовательным прохождением шагов
4. Применение подготовленных патчей модулей и шаблонов
5. Прогон чек-листа
6. Возврат к нормальному режиму работы

Типичные проблемы при обновлении и их решения

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

• Полный аудит кода и структуры сайта
• Развёртывание тестового стенда с резервными копиями
• Поэтапное обновление с фиксацией всех изменений
• Адаптация шаблонов и модулей под новую версию
• Тестирование всех ключевых сценариев (корзина, заказ, 1С, платежи)
• Перенос на продакшен с минимальным простоем (2–4 часа)
• Документация по изменениям и обучение администраторов
• Постмиграционная поддержка в течение 2 недель

Сроки выполнения

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

Больше информации о платформе: 1С-Битрикс на Википедии.

Изображение: официальный сайт 1С-Битрикс.

Миграция сайтов на 1С-Битрикс

Переезд на новую CMS — всегда стресс для сайта. Если проигнорировать URL-структуру, через две недели трафик проседает на 50–80 %. WordPress генерит /product/item-name/, OpenCart — /index.php?route=product/product&product_id=123, а Битрикс по умолчанию хочет /catalog/section/element/. Без карты 301-редиректов поисковики фиксируют массовые 404. Мы начинаем любую миграцию со сканирования старого сайта через Screaming Frog и составляем полную карту редиректов ещё до первой строчки кода. Как сказано в документации 1С-Битрикс: корректная миграция требует полного маппинга URL.

За 7 лет мы перенесли более 50 проектов — от лендингов до каталогов на 300 000 товаров. Средний срок — 2–8 недель. Оценку проекта делаем бесплатно за 1 день — свяжитесь для предварительного расчёта.

Какие CMS мы переносим на Битрикс?

За годы работы данные мигрировали с десятков систем.

Блоги и корпоративные сайты: WordPress / WooCommerce → 1С-Битрикс. Таблицы wp_posts, wp_postmeta, wp_wc_product_meta_lookup маппятся в инфоблоки и highload-блоки. Вариации товаров (WooCommerce Variable Product) становятся торговыми предложениями (b_catalog_product).

Интернет-магазины: OpenCart / ocStore → 1С-Битрикс. Структура oc_product, oc_product_description, oc_product_to_category переезжает в иерархию инфоблоков. Мультиязычность OpenCart преобразуется в языковые версии свойств. Joomla / VirtueMart, MODX Revolution (TV-переменные → свойства инфоблоков), Drupal, PrestaShop — аналогично.

SaaS-платформы: Tilda, InSales, Shopify, Wix, Squarespace. Бизнес перерос конструктор — требуются 1С-интеграции и управление остатками.

Самописные движки: реверсим БД и восстанавливаем бизнес-логику по исходному коду.

Что переносится?

Контент: страницы, статьи, новости → информационные инфоблоки. Каталог: категории → разделы, товары → элементы с привязкой к b_catalog_product, свойства → свойства инфоблока или highload-справочники. Изображения, отзывы, FAQ.

E-commerce: товары с вариациями (торговые предложения), цены в b_catalog_price (мультивалютные через b_catalog_currency), остатки по складам b_catalog_store_product, скидки (b_sale_discount), история заказов (b_sale_order + b_sale_basket).

Пользователи: клиентская база — b_user + UF-поля. Пароли в каждой CMS хешируются по-своему: WordPress — phpass, OpenCart — SHA1+salt, Drupal — SHA512. Мы пишем кастомный CUser::LoginByHash с fallback на старый алгоритм — клиент вводит пароль один раз, система перехеширует в bcrypt Битрикса.

SEO-данные: мета-теги, alt-теги, URL-структура. Главная задача — сохранить все URL или проставить 301-редиректы.

Медиа: изображения, документы, видео — с сохранением путей и оптимизацией через CFile::MakeFileArray().

Как происходит миграция?

Как сохранить SEO-позиции?

Потеря органического трафика — главный страх, и он обоснован. Вот как мы его избегаем.

Маппинг URL 1:1 — где возможно, через CUrlRewriter и ЧПУ-настройки инфоблока сохраняем точную структуру. Где нельзя — 301. Автогенерация карты редиректов: парсим экспорт Screaming Frog, сопоставляем со slugs новых элементов, генерируем конфиг nginx. Каждый редирект проверяется curl -I после переключения.

Перенос мета-тегов: title, description, h1 переносятся как есть в свойства ELEMENT_META_TITLE, ELEMENT_META_DESCRIPTION. Canonical: rel="canonical" через SEO-компонент Битрикс. Дубли отсекаем: www/без www, http/https, параметры сортировки. Sitemap: новая sitemap.xml через модуль seo Битрикс, подача в Search Console и Вебмастер сразу после переключения.

Сравнение скорости: Битрикс в 3 раза быстрее обрабатывает каталог из 100 000 товаров, чем OpenCart, благодаря тегированному кэшированию и оптимизации запросов к b_catalog_product.

Что входит в работу (deliverables)

Миграция интеграций

Внешние интеграции — отдельный пласт. Мы переподключаем:

• Платёжные системы — sale.paysystem с сохранением истории транзакций.
• Доставка — настройка sale.delivery.handler (СДЭК, Почта России).
• CRM — привязка к Битрикс24 или сохранение текущей через REST API.
• 1С — настройка обмена через CommerceML. Часто это главная причина миграции на Битрикс.
• Email-маркетинг — перенос подписчиков, шаблонов, вебхуков.
• Аналитика — e-commerce tracking под новую структуру dataLayer.

Типичные ошибки при миграции

Каждая из этих ошибок приводила к потере позиций и клиентов.

Потеря URL без редиректов — самый разрушительный промах. /product/123 вместо /catalog/item-name.html — без 301 это массовые 404 и обвал трафика. Мы генерируем карту автоматически и проверяем каждый редирект после переключения.

Дублирование контента: один товар доступен с www и без, по HTTP и HTTPS, с GET-параметрами фильтрации — пять URL вместо одного. SEO-вес размывается. Настраиваем canonical, 301 для вариаций, robots.txt с Disallow для параметров.

Битые изображения: абсолютные URL в контенте (src="https://old-site.ru/img/photo.jpg"), потеря качества при пережатии. Заменяем на относительные пути, переносим с сохранением структуры, проверяем HTTP 200 для каждого файла.

Потеря мета-тегов и микроразметки: title, description, Schema.org могут не перенестись или перенестись криво. Делаем полный маппинг и проверку на staging.

Отвалившиеся формы и интеграции: сменились ID, API-ключи, вебхуки. Составляем реестр всех интеграций до начала и проверяем каждую после.

Мобильная версия: старый m.site.ru → адаптивный Битрикс. Без редиректа мобильных URL — 404 для мобильных пользователей. Учитываем в карте редиректов.

Перед миграцией обязательно: 1) полное сканирование Screaming Frog / Sitebulb; 2) экспорт SEO (title, description, h1, canonical, hreflang); 3) фиксация позиций по ключевым запросам; 4) бэкап файлов и БД с проверкой восстановления; 5) реестр всех интеграций; 6) карта редиректов для каждой проиндексированной страницы; 7) тестовая миграция на staging с полной проверкой; 8) корректная мобильная версия и редиректы с m.site.ru; 9) новая sitemap.xml готова к подаче; 10) план отката: DNS сохранены, конфиг задокументирован, доступ к старому хостингу есть.

Сроки и экономия

Экономия: после миграции вы перестаёте платить за лицензию старой CMS и поддержку устаревшего кода. Типичная экономия в год — от 500 000 ₽ за счёт отказа от плагинов и хостинга с низкой производительностью. Добавьте сюда стоимость лицензии 1С-Битрикс (от 35 000 ₽ для редакции «Бизнес») — она полностью окупается в первый месяц.

Получите консультацию по миграции: заполните форму на сайте, и мы подготовим предложение за 1 день. Оценим ваш проект бесплатно — напишите нам для расчёта.