Міграція з хмари на On-Premise Бітрікс24: як перенести CRM та файли

Наша компанія займається розробкою, підтримкою та обслуговуванням рішень на Бітрікс та Бітрікс24 будь-якої складності. Від простих односторінкових сайтів до складних інтернет-магазинів, CRM систем з інтеграцією 1С та телефонії. Досвід розробників підтверджено сертифікатами від вендора.
Послуги, які ми пропонуємо
Показано 1 з 1Усі 1626 послуг
Міграція з хмари на On-Premise Бітрікс24: як перенести CRM та файли
Середній
~1-2 тижні
Часті запитання

Наші компетенції:

Етапи розробки

Останні роботи

  • image_website-b2b-advance_0.webp
    Розробка сайту компанії B2B ADVANCE
    1357
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    Розробка веб-сайту для компанії ФІКСПЕР
    944
  • image_bitrix-bitrix-24-1c_development_of_an_online_appointment_booking_widget_for_a_medical_center_594_0.webp
    Розробка на базі Бітрікс, Бітрікс24, 1С для компанії Development of an Online
    693
  • image_bitrix-bitrix-24-1c_mirsanbel_458_0.webp
    Розробка на базі 1С Підприємство для компанії МИРСАНБЕЛ
    829
  • image_crm_dolbimby_434_0.webp
    Розробка сайту на CRM Бітрікс24 для компанії DOLBIMBY
    731
  • image_crm_technotorgcomplex_453_0.webp
    Розробка на базі Бітрікс24 для компанії ТЕХНОТОРГКОМПЛЕКС
    1074

Перенесення даних з хмарного Бітрікс24 на коробкову версію (On-Premise)

Хмарний Бітрікс24 не дає прямого доступу до бази даних, кастомізація обмежена через REST API, а ліміти на запити гальмують інтеграції. Для компаній з тисячами угод і десятками інтеграцій це стає вузьким місцем. On-Premise (коробка) знімає ці обмеження: ви отримуєте повний контроль над сервером, необмежені запити до API та можливість модифікувати модулі. Однак переїзд з хмари на коробку — не копіювання файлів, а проєкт з аналізом архітектури, перенесенням даних через REST та адаптацією бізнес-процесів. Ми виконали понад 50 таких проєктів і знаємо всі підводні камені. Оцініть обсяг робіт для вашого порталу — ми проведемо безкоштовний аудит.

Як підготуватися до переходу на On-Premise?

Перед початком потрібно провести аудит порталу: оцінити обсяг CRM, диска, кількість інтеграцій. Від цього залежить стратегія перенесення. Наприклад, при 300 000+ записах CRM знадобиться посторінковий обхід через crm.deal.list та паралельний запуск декількох скриптів для диска. Ми рекомендуємо одразу закладати 2–4 тижні на паралельну роботу хмари та коробки для звірки даних. Економія на ліцензіях при переході на коробку може сягати 40% на рік — для команди з 50 користувачів це близько 120 000 грн.

Неавтоматизовані дані

Через REST API не експортуються історія чатів, стрічка новин та налаштування SIP-телефонії. Бізнес-процеси вивантажуються через bizproc.workflow.template.list, але їхні шаблони прив'язані до хмарної конфігурації та потребують ручної адаптації під коробку. Файли диска доступні через disk.file.get та disk.folder.uploadfile, але швидкість обмежена тарифом: безкоштовний — до 2 запитів/с, платний — до 200. Для десятків тисяч файлів це означає дні безперервної роботи скрипта.

Як мігрувати CRM без втрати даних?

CRM-сутності — найоб'ємніший блок. Порядок перенесення критичний для збереження зв'язків між записами.

  1. Користувачі (user.get) — створюються на коробці вручну або через LDAP.
  2. Статуси та воронки (crm.status.list, crm.dealcategory.list) — перестворюються до завантаження даних.
  3. Користувацькі поля (crm.userfield.list) — додаються через crm.userfield.add.
  4. Компанії → Контакти → Ліди → Угоди — строго в такій послідовності з маппінгом старих ID.
  5. Активності та справи (crm.activity.list).
  6. Коментарі таймлайну (crm.timeline.comment.list).

Приклад посторінкового обходу угод:

$start = 0;
$deals = [];
do {
    $result = $bitrix24->call('crm.deal.list', [
        'select' => ['*', 'UF_*'],
        'start'  => $start,
    ]);
    $deals = array_merge($deals, $result['result']);
    $start = $result['next'] ?? null;
} while ($start !== null);

Файлове сховище: як прискорити перенесення?

Файли з Диска завантажуються через disk.file.get (отримати URL завантаження) та завантажуються на коробку через disk.folder.uploadfile. При великих обсягах (десятки тисяч файлів) процес займає кілька днів безперервної роботи скрипта. Рішення — паралельний запуск кількох процесів з розділенням файлів по папках, але з контролем лімітів API. On-Premise перевершує хмару в 2–3 рази за швидкістю обробки запитів до БД, а також дозволяє одночасно запускати до 10 скриптів без обмежень. Це особливо помітно при роботі з великими каталогами: коробка обробляє 100 000+ товарів без затримок, тоді як хмара впирається в ліміти API.

Які ризики при переході на On-Premise?

Головний ризик — втрата зв'язків між даними. Якщо імпортувати угоди до створення користувацьких полів, вони не знайдуть свої значення. Ми мінімізуємо це покроковою верифікацією: тестове перенесення на копію, потім повна перевірка. Ще один ризик — збої в інтеграціях. Налаштування 1С, ЮKassa, СДЕК доведеться адаптувати під коробку, оскільки API ендпоїнти можуть відрізнятися. Ми маємо сертифікацію Bitrix Partner, що гарантує якість робіт. Окупність міграції — протягом 8–12 місяців за рахунок зниження щомісячних платежів.

Що входить у нашу роботу

Ми пропонуємо повний цикл перепенесення під ключ:

  • Аудит поточного порталу та складання карти даних.
  • Написання скриптів перенесення під вашу структуру.
  • Тестове перенесення з покроковою верифікацією.
  • Переналаштування інтеграцій (1С, пошта, телефонія, ЮKassa).
  • Налаштування прав доступу та ролей на коробці.
  • Навчання адміністраторів роботі з On-Premise.
  • Паралельна робота хмари та коробки 2–4 тижні.
  • Супровід після запуску та усунення можливих розбіжностей.

Налаштування та структура порталу

На відміну від даних, налаштування порталу не мігрують через API — їх потрібно переналаштовувати вручну: структура відділів та посад, права доступу (ролі CRM, диска, груп), інтеграції із зовнішніми сервісами, зовнішні віджети та додатки з маркетплейсу. На коробці з'являються можливості, яких немає в хмарі: прямий доступ до бази, LDAP/Active Directory, кастомні модулі та повний контроль над файловою системою. Це основна причина переходу для компаній з нетиповими вимогами.

Чому важлива правильна підготовка сервера?

Коробковий Бітрікс24 потребує:

  • Linux (CentOS 7+, Ubuntu 18.04+) або Windows Server.
  • PHP 7.4–8.1 з набором обов'язкових розширень (кешування опкодів, буферизація).
  • MySQL 5.7+ / MariaDB 10.3+ з оптимізацією запитів.
  • Мінімум 4 ГБ RAM для команди до 50 користувачів, 16+ ГБ для 200+.

Для встановлення рекомендуємо використовувати BitrixVM — готовий образ віртуальної машини з налаштованим стеком. Це економить 2–4 години на налаштуванні. Ми допомагаємо підібрати конфігурацію під ваше навантаження з урахуванням майбутнього зростання.

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

Масштаб компанії Обсяг даних CRM Термін міграції
Малий бізнес (до 20 кор.) до 50 000 записів 1–2 тижні
Середній (20–100 кор.) 50 000–300 000 записів 3–5 тижнів
Великий (100+ кор.) 300 000+ записів, великий диск 2–3 місяці

Після міграції обов'язковий період паралельної роботи (2–4 тижні), коли хмара ще доступна для звірки даних. Потім — перемикання та закриття хмарної підписки.

Порівняння можливостей хмари та коробки

Можливість Хмарний Бітрікс24 Коробка (On-Premise)
Прямий доступ до БД ні так
Ліміт REST API до 200 запитів/с (платний) не обмежений (коробка в 2-3 рази швидша)
Кастомні модулі лише через REST повна кастомізація
LDAP / Active Directory ні так
Підтримка 1С обмежено повноцінно

Згідно документації Бітрікс24, коробкова версія дозволяє необмежені запити до API.

Зв'яжіться з нами для розрахунку термінів та вартості міграції. Отримайте консультацію прямо зараз.

Міграція сайтів на 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 день. Оцінимо ваш проєкт безкоштовно — напишіть нам для розрахунку.