Міграція 1С-Бітрікс: безпечне оновлення без втрат
Чому міграція на нову версію 1С-Бітрікс — це не просте завдання
Клієнт скаржиться: після оновлення ядра сайт падає з білим екраном. Адаптація шаблонів каталогу займає тижні. Знайома ситуація? Один із наших клієнтів — інтернет-магазин з 15 000 товарів і кастомною інтеграцією з 1С — намагався оновитися самостійно і втратив два тижні на налагодження білого екрану. Після звернення до нас міграція зайняла три дні, а простій продакшену не перевищив чотирьох годин. Ми допомагаємо компаніям перенести сайти на актуальні версії 1С-Бітрікс без втрати даних і падіння позицій. Це не просто кнопка «Оновити» — за роки роботи накопичуються нестандартні модулі, застарілі API, шаблони на старому ядрі. Без підготовки оновлення може закінчитися катастрофою. Наш підхід — поетапна міграція з тестовим стендом і можливістю відкату. Ми гарантуємо безшовний перехід і економію до 30% бюджету (середня економія — 25 000 грн). Окупність міграції досягається за рахунок підвищення продуктивності та зниження витрат на підтримку. За 10+ років досвіду ми виконали понад 300 міграцій, 95% з яких пройшли без збоїв.
Що змінюється між версіями?
Бітрікс активно мігрує зі старого ядра (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. Тестовий стенд
Піднімається повна копія сайту на окремому сервері або домені. На стенді:- Робиться резервна копія файлів і бази даних
- Виконується поетапне оновлення через адміністративну панель (Оновлення системи)
- Фіксуються всі помилки з /bitrix/cache/ та логів PHP
Етап 3. Сумісність модулів
Для кожного стороннього модуля з Маркетплейсу — перевірити версію сумісності на порталі розробника. Якщо оновлення немає — зв'язатися з розробником або переписати функціонал. Для кастомних модулів — ручна адаптація.Етап 4. Адаптація шаблонів
Шаблони компонентів каталогу — головна точка болю. У нових версіях компонент bitrix:catalog змінив структуру $arResult. Змінна $arResult['ITEMS'] замінена на $arResult['CATALOG_ITEMS'] з новою структурою торгових пропозицій. Адаптація шаблону каталогу займає 40–60% всього часу міграції.Етап 5. Тестування функціональності
Перевіряємо всі сценарії:- Додавання товару до кошика
- Оформлення замовлення (кожен крок)
- Особистий кабінет — історія замовлень
- Пошук по каталогу
- Фільтрація товарів
- Оплата (всі підключені платіжні системи)
- Синхронізація з 1С через CommerceML (якщо використовується)
- Бізнес-процеси (Bizproc) та роботи
- Email-сповіщення
- Адміністративна частина — редагування товарів
Етап 6. Перенесення на продакшен
Оптимальний сценарій:- Нічне обслуговування (повідомити користувачів заздалегідь)
- Резервна копія продакшену
- Оновлення Бітрікс через update_system_step.php з послідовним проходженням кроків
- Застосування підготовлених патчів модулів і шаблонів
- Прогін чек-листа
- Повернення до нормального режиму роботи
Типові проблеми при оновленні та їх вирішення
| Проблема | Причина | Рішення |
|---|---|---|
| Білий екран після оновлення | PHP-несумісність у кастомному коді | Увімкнути display_errors, знайти файл |
| Злетів дизайн каталогу | Змінився $arResult у компоненті | Адаптація шаблону |
| Не працює кошик | Змінений API модуля sale | Рефакторинг коду роботи із замовленням |
| Старий модуль не працює | Немає версії для нової платформи | Аналог з Маркетплейсу або кастомна доробка |
Що входить у нашу роботу?
- Повний аудит коду та структури сайту
- Розгортання тестового стенду з резервними копіями
- Поетапне оновлення з фіксацією всіх змін
- Адаптація шаблонів і модулів під нову версію
- Тестування всіх ключових сценаріїв (кошик, замовлення, 1С, платежі)
- Перенесення на продакшен з мінімальним простоєм (2–4 години)
- Документація за змінами та навчання адміністраторів
- Постміграційна підтримка протягом 2 тижнів
Строки виконання
| Масштаб проекту | Строк |
|---|---|
| Типовий магазин, мінімальні кастомізації | 3–5 днів |
| Середній проект, 5–15 кастомних модулів | 2–3 тижні |
| Великий портал, складна інтеграція з 1С | 1–2 місяці |
Міграція версії — планове технічне обслуговування, а не разова катастрофа. При правильній підготовці продакшен перебуває в режимі обслуговування лише кілька годин. Замовте міграцію під ключ — отримайте консультацію по вашому проекту вже сьогодні. Зв'яжіться з нами для точного розрахунку строків і вартості. Ми маємо 10+ років досвіду та виконали понад 300 успішних міграцій.
Більше інформації про платформу: Вікіпедія. Зображення: офіційний сайт 1С-Бітрікс.