Міграція 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С-Бітрікс.
Міграція сайтів на 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().
Як відбувається міграція?
| Етап |
Тривалість |
Що робимо |
| Аудит |
1–3 дні |
Скануємо Screaming Frog: всі URL, статус-коди, мета-теги. Аналізуємо структуру БД, кастомні доробки, інтеграції. Складаємо карту перенесення. |
| Проектування архітектури |
2–5 днів |
Маппінг: типи контенту → інфоблоки, поля → властивості, довідники → highload-блоки. Архітектура має бути зручною для адміністрування в Бітрікс. |
| Скрипти міграції |
3–10 днів |
PHP-скрипти читають зі старої БД (або API), трансформують і пишуть через API Бітрікса (CIBlockElement::Add, \Bitrix\Sale\Order::create). Запускаємо повторно при тестуванні. |
| Staging |
1–2 дні |
Повне перенесення на тестовий сервер. Перевіряємо цілісність: кількість товарів, властивості, URL, фільтри. |
| Дизайн / шаблони |
1–4 тижні |
Редизайн або адаптація верстки під шаблонізатор Бітрікса (template.php, result_modifier.php). |
| 301-редиректи |
1–2 дні |
Повна карта в .htaccess або nginx.conf. Кожен проіндексований URL → відповідна сторінка нового сайту. |
| Фінальна міграція |
1 день |
Дельта-імпорт свіжих даних, перемикання DNS, моніторинг. |
| Постміграційний контроль |
2–4 тижні |
Моніторимо Google Search Console та Яндекс.Вебмастер: індексація, позиції, crawl errors. |
Як зберегти 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)
| Що отримує клієнт |
Опис |
| Документація |
Карта редиректів, опис маппінгу, схема БД |
| Доступи |
Адміністративна панель, FTP/SSH, API-ключі |
| Навчання |
Відеоуроки або консультація з роботи з Бітрікс |
| Підтримка |
2 тижні постміграційного моніторингу та фіксу багів |
| Гарантія |
Повернення до старого сайту протягом 48 годин при форс-мажорі |
Міграція інтеграцій
Зовнішні інтеграції — окремий пласт. Ми перепідключаємо:
- Платіжні системи —
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 збережені, конфіг задокументовано, доступ до старого хостингу є.
Терміни та економія
| Тип проєкту |
Терміни |
Коментар |
| Інформаційний сайт (до 500 стор.) |
2–4 тижні |
Контент + дизайн + редиректи |
| Інтернет-магазин (до 10 000 товарів) |
4–8 тижнів |
Каталог + замовлення + інтеграції |
| Великий магазин (100 000+ товарів) |
2–4 місяці |
Кастомні скрипти + навантажувальне тестування |
Економія: після міграції ви перестаєте платити за ліцензію старої CMS та підтримку застарілого коду. Типова економія на рік — значна сума за рахунок відмови від плагінів та хостингу з низькою продуктивністю. Додайте сюди вартість ліцензії 1С-Бітрікс (редакція «Бізнес») — вона повністю окупається в перший місяць.
Отримайте консультацію з міграції: заповніть форму на сайті, і ми підготуємо пропозицію за 1 день. Оцінимо ваш проєкт безкоштовно — напишіть нам для розрахунку.