Міграція On-Premise Бітрікс24 у хмару: покрокова інструкція та вартість

Ви хочете піти від адміністрування власного сервера, скоротити IT-інфраструктуру та використовувати хмарні функції, яких немає в коробці. Перехід з On-Premise у хмару має принципове обмеження: Бітрікс24 не надає офіційного інструменту імпорту з коробкової версії. Перенесення даних можливе лише через REST API — у зворотному напрямку, ніж при міграції з хмари в коробку. За 5 років ми виконали понад 30 таких проєктів і знаємо всі підводні камені. Наша команда має сертифікацію Бітрікс24 та гарантує цілісність даних під час міграції.

Хмарний Бітрікс24 дає вбудовані можливості, недоступні в коробці: WebRTC-телефонія, повноцінний мобільний застосунок, автоматичні оновлення. Це знімає навантаження з IT-відділу та скорочує витрати на серверне обладнання на 40-60%. Наприклад, для компанії з 50 співробітниками економія на серверному обладнанні та адмініструванні становить від 40 000 до 60 000 гривень на місяць, а для 100 співробітників — до 80 000 гривень. За 3 роки економія може перевищити 2 000 000 гривень. Автоматичні оновлення хмари у 3 рази знижують навантаження на IT-відділ порівняно з коробкою.

Дані, доступні для перенесення

Не все, що є в коробці, доступне в хмарі. Ключові відмінності, які потрібно перевірити до прийняття рішення:

Чому кастомні модулі — головна проблема?

Якщо в коробці є кастомні PHP-модулі або компоненти, у хмарі їх потрібно переписати як REST-застосунки. Це основна складність: таке доопрацювання може переважити вартість самої міграції. На етапі аудиту ми оцінюємо кожен модуль і даємо висновок. Кастомні модулі Бітрікс24 — це найчастіша причина подорожчання проєкту.

Процес перенесення даних CRM

Дані вивантажуються з коробки через REST API (він працює однаково в обох версіях) і завантажуються в хмару через той самий REST API. Ми використовуємо batch-запити (масове завантаження) та обробку помилок через вебхуки для підвищення ефективності. Послідовність:

1. Створити OAuth-застосунок у хмарному порталі для аутентифікації запитів.
2. Перенести користувачів — запросити вручну через інтерфейс або використати user.add (тільки в On-Premise; у хмарі додавання через API обмежено).
3. Перестворити довідники: статуси угод (crm.status.add), воронки (crm.dealcategory.add), користувацькі поля (crm.userfield.add).
4. Перенести CRM-дані: компанії → контакти → ліди → угоди зі збереженням маппінгу ID.
5. Перенести файли з Диска через disk.folder.uploadfile.

Скрипт міграції працює з двома API-клієнтами одночасно: один підключений до коробки (джерело), інший — до хмари (приймач).

Офіційна документація Бітрікс24 REST API обмежує частоту запитів до хмарного API сильніше, ніж до коробочного. На тарифі «Команда» — 2 запити в секунду, на «Компанія» — до 200. Для перенесення великих обсягів реалізуємо rate limiting:

class RateLimiter
{
    private float $lastRequest = 0;
    private float $minInterval;  // секунди між запитами

    public function wait(): void
    {
        $elapsed = microtime(true) - $this->lastRequest;
        if ($elapsed < $this->minInterval) {
            usleep((int)(($this->minInterval - $elapsed) * 1_000_000));
        }
        $this->lastRequest = microtime(true);
    }
}

Що таке ліміти API і як їх обійти?

Ліміти API — ключовий фактор при плануванні. У документації REST API Бітрікс24 зазначено, що для хмарних тарифів вони нижчі. RateLimiter вище — стандартне рішення. На практиці ми використовуємо налаштовуваний інтервал і чергу завдань, щоб не перевищувати ліміт API хмарного Бітрікс24.

Хмарний Бітрікс24 у 2–3 рази знижує сукупну вартість володіння (TCO) порівняно з коробковою версією за рахунок виключення серверного обладнання та його адміністрування.

Що входить у роботу?

• Аудит поточної конфігурації: інвентаризація модулів, користувацьких полів, бізнес-процесів.
• Узгодження плану міграції: які дані переносимо, що переписуємо.
• Розробка скриптів перенесення: з урахуванням rate limiting та маппінгу ID.
• Тестовий прогін: на копії даних, перевірка цілісності.
• Паралельна робота: 2–4 тижні спільного використання коробки та хмари.
• Навчання співробітників: робота з новим інтерфейсом та REST-застосунками.
• Пост-міграційна підтримка: 2 тижні після перемикання.

Чек-лист перед міграцією:

• Перевірити, які PHP-модулі використовуються — вони не переносяться.
• Визначити тариф хмари: від нього залежать ліміти API.
• Призначити відповідального за маппінг користувацьких ID.
• Створити OAuth-застосунок у хмарному порталі.
• Підготувати середовище для паралельної роботи.

Період паралельної роботи

Рекомендований період паралельної роботи — 2–4 тижні. У цей час нові дані вносяться в хмару, а стара коробка залишається в режимі read-only для звірки. Після завершення періоду — деактивація коробки та звільнення сервера. Це виключає простій порталу та дозволяє перевірити цілісність даних. Паралельна робота Бітрікс24 — стандартний підхід при міграції.

Типові терміни

Вартість міграції варіюється від 200 000 до 1 000 000 гривень залежно від обсягу даних та складності кастомізацій. Замовте міграцію під ключ – ми оцінимо ваш проєкт безкоштовно. Пишіть нам для отримання комерційної пропозиції. Зв'яжіться з нами для консультації.

Міграція сайтів на 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 та підтримку застарілого коду. Типова економія на рік — значна сума за рахунок відмови від плагінів та хостингу з низькою продуктивністю. Додайте сюди вартість ліцензії 1С-Бітрікс (редакція «Бізнес») — вона повністю окупається в перший місяць.

Отримайте консультацію з міграції: заповніть форму на сайті, і ми підготуємо пропозицію за 1 день. Оцінимо ваш проєкт безкоштовно — напишіть нам для розрахунку.