Перенесення даних з RetailCRM в Бітрікс24: історія та лояльність
При перенесенні з RetailCRM в Бітрікс24 основна складність — різна модель даних: RetailCRM центрується на замовленнях, Бітрікс24 — на угодах. Без акуратного маппінгу губляться статуси, історія платежів та дані клієнтів. Ми стикалися з проектами, де через невірний маппінг статусів 30% угод опинялися в неправильних стадіях, а історія лояльності була втрачена. Наша команда за 6 років провела більше 50 міграцій, і ми знаємо, як обійти ці граблі. Ми використовуємо RetailCRM API v5 для вивантаження та REST API Бітрікс24 для запису. Для великих обсягів паралелимо запити з обмеженням 5 RPS, що дозволяє обробляти до 50 000 замовлень на день. Міграція через наш автоматизований конвеєр у 3 рази швидша за ручне перенесення через Excel.
Чому правильний маппінг — основа міграції з RetailCRM в Бітрікс24?
RetailCRM зберігає статуси в багаторівневій структурі з групами, а Бітрікс24 — у плоских стадіях угод. Без маппінгу «Скасовано» може стати «Успішно», а «В роботі» — «Програш». Ми автоматично зіставляємо статуси через StatusMapper, який враховує бізнес-логіку: наприклад, «Повернення» в RetailCRM маппиться в «Скасування угоди» зі збереженням причини. На одному з проектів клієнт втратив 30% угод через те, що статус «Доставлено» не був перенесений — після впровадження мапера втрати виключені.
Які дані ми переносимо?
RetailCRM будується навколо замовлень (Orders) як центральної суті, що відрізняє її від класичних CRM на кшталт Бітрікс24, орієнтованих на угоди:
- Order — замовлення зі складом, статусом, доставкою, оплатою
- Customer — покупець (фізична особа або компанія)
- Product — товар (з каталогу магазину)
- Task — завдання (вбудовані в інтерфейс)
- Note — коментарі до замовлень і покупців
- Segment — сегменти покупців (маркетингові)
- Loyalty — програма лояльності (бали, рівні)
Всі ці сутності ми переносимо у відповідні об'єкти Бітрікс24. Наприклад, замовлення стають угодами, покупці — контактами, а програма лояльності — кастомними полями контакту або модулем бонусних балів.
Як влаштована міграція: покроковий процес
- Аудит даних — вивантаження з RetailCRM, аналіз структури та обсягу (етап займає 1–3 дні).
- Проектування маппінгу — які поля відповідають яким, рішення для статусів і бізнес-процесів.
- Розробка скриптів міграції — на PHP з використанням RetailCRM API v5 та REST API Бітрікс24.
- Тестування на копії — перенесення даних на тестове середовище, звірка контрольних сум.
- Верифікація — порівняння сумарних показників (кількість замовлень за статусами, GMV).
- Запуск у продакшн — перенесення в робоче середовище, навчання співробітників.
Як переносити замовлення зі збереженням статусів?
RetailCRM має багаторівневу систему статусів з групами. У Бітрікс24 створюються відповідні стадії угоди. Ми автоматично маппимо статуси через StatusMapper, який враховує бізнес-логіку: наприклад, «Скасовано» в RetailCRM може стати «Програш угоди». Важливо також зберегти історію змін статусів — ми переносимо її в події таймлайну угоди.
Що робити з програмою лояльності?
Дані лояльності (бали, рівні, історія нарахувань) мігрують через кастомні поля контакту або модуль бонусних балів Бітрікс24. Ми розробляємо PHP-скрипт, який перераховує баланси на момент перенесення та завантажує історію операцій. Якщо в RetailCRM використовується система згорання балів, ми налаштовуємо агенти Бітрікс24 для автоматичного списання.
Маппінг замовлень: приклад
При інтеграції RetailCRM з Бітрікс24 маппінг замовлень залежить від того, чи є в компанії інтернет-магазин на Бітрікс.
Якщо магазин є: замовлення вже можуть бути синхронізовані — мігруємо лише покупців та історію.
Якщо магазину немає: замовлення переносяться як Угоди, покупці — як Контакти та Компанії.
| RetailCRM |
Бітрікс24 (без магазину) |
Бітрікс24 (з магазином) |
| Customer |
Контакт / Компанія |
Користувач сайту |
| Order |
Угода |
Замовлення (b_sale_order) |
| Order Item |
Позиція угоди |
Позиція кошика |
| Task |
Завдання |
Завдання |
| Note |
Коментар таймлайну |
Коментар |
| Segment |
Група користувачів |
Сегмент CRM |
Типові терміни та окупність
| Обсяг |
Термін |
| до 10 000 замовлень, до 5 000 покупців |
2–3 тижні |
| 10 000–100 000 замовлень |
4–8 тижнів |
| 100 000+ замовлень, лояльність, сегменти |
2–4 місяці |
Інвестиції в міграцію окупаються вже через 3–6 місяців за рахунок автоматизації рутинних операцій. Вартість розраховується індивідуально на етапі аудиту. Наші сертифіковані спеціалісти гарантують точний маппінг та збереженість даних.
Що входить в роботу
- Аудит даних — вивантаження структури RetailCRM, аналіз дублів та аномалій.
- Проектування маппінгу — детальна схема відповідності полів з урахуванням бізнес-процесів.
- Розробка скриптів — на PHP з використанням API, з можливістю кастомної логіки.
- Тестова міграція — на копії середовища, з верифікацією контрольних сум.
- Навчання співробітників — вебінар або очна зустріч по роботі з новими даними.
- Документація та вихідні коди — передаються замовнику.
- Пост-міграційна підтримка — 2 тижні моніторингу та виправлення помилок.
Як уникнути помилок при міграції?
Використовуйте тестове середовище. Наші інженери налаштовують клон Бітрікс24, де відпрацьовують сценарії перенесення. Тільки після підтвердження замовника дані переносяться в бойове середовище. Ми також пишемо скрипти зворотної сумісності на випадок відкату. Гарантуємо збереженість даних та відповідність 54‑ФЗ при передачі фіскальних даних. Всі вихідні коди та документація передаються замовнику.
Зв'яжіться з нами для попереднього аудиту — ми безкоштовно оцінимо обсяг та складність міграції. Отримайте консультацію сертифікованого спеціаліста.
Міграція сайтів на 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 день. Оцінимо ваш проєкт безкоштовно — напишіть нам для розрахунку.
