Перенесення даних з іншої CRM у Бітрікс24: маппінг та дедуплікація

При перенесенні 50 000 контактів з Salesforce в Бітрікс24 менеджери втратили зв'язки угод з контактами — знайома ситуація? Кожна CRM має власну модель даних, логіку зв'язків та специфіку полів. Бітрікс24 — теж. Головне завдання міграції: зберегти цілісність даних та історію відносин. Наша команда має понад 10 років досвіду в таких проектах, тому ми знаємо всі підводні камені.

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

Як уникнути втрати даних при перенесенні?

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

Структура даних Бітрікс24

Перш ніж мігрувати, потрібно зрозуміти, куди кладуться дані. Ключові сутності Бітрікс24:

Зв'язки: контакт прив'язаний до компанії через b_crm_company_contact, угода — до контакту через b_crm_deal_contact.

Інструменти перенесення

REST API Бітрікс24 — офіційний і найнадійніший метод. Підтримує пакетні запити (batch), що критично при перенесенні тисяч записів:

$batchCalls = [];
foreach ($contacts as $contact) {
    $batchCalls['create_contact_' . $contact['id']] = [
        'method' => 'crm.contact.add',
        'params' => [
            'fields' => [
                'NAME'       => $contact['first_name'],
                'LAST_NAME'  => $contact['last_name'],
                'EMAIL'      => [['VALUE' => $contact['email'], 'VALUE_TYPE' => 'WORK']],
                'PHONE'      => [['VALUE' => $contact['phone'], 'VALUE_TYPE' => 'WORK']],
                'COMPANY_ID' => $companyMapping[$contact['company_id']] ?? null,
                'UF_CRM_SOURCE_ID' => $contact['id'],
            ],
        ],
    ];
}

$result = $b24->callBatch(array_slice($batchCalls, 0, 50));

Згідно з документацією Бітрікс24, один batch-запит може містити до 50 команд. Прямий запис у БД — для хмарного Бітрікс24 недоступний. Для коробкової версії — прискорює масовий імпорт, але вимагає ручної перебудови індексів та обережності з тригерами. REST API повільніший, але безпечніший: у 2-3 рази повільніший при пакетному записі, зате дає повний контроль і можливість відкату. REST API безпечніший за прямий SQL у 3 рази, хоча й повільніший.

Прямий SQL не варто використовувати в хмарі, оскільки хмарний Бітрікс24 не надає доступ до бази даних. Навіть у коробковій версії ми рекомендуємо REST API для відстеження та відкату.

Чому маппінг полів — найтрудомісткіша частина?

Кожне поле джерела потрібно зіставити з полем Бітрікс24. Приклад маппінгу з HubSpot (див. HubSpot - Wikipedia):

Нестандартні поля HubSpot переносяться в користувацькі поля Бітрікс24 (UF-поля). Їх потрібно створити заздалегідь через crm.contact.userfield.add.

Що робити з дублікатами?

Сторонні CRM часто містять дублі контактів (одна людина під різними email). Перед міграцією — дедуплікація в джерелі. Стратегії:

• Жорстка: один унікальний email = один контакт. Дублі об'єднуються.
• М'яка: переносимо всі записи, потім використовуємо вбудований інструмент дедуплікації Бітрікс24 (Контакти → Дублікати).

Рекомендується м'яка стратегія — зберігає всі дані, дедуплікацію менеджери роблять у процесі роботи.

Послідовність створення сутностей

Порядок важливий через посилальну цілісність:

1. Компанії
2. Контакти (прив'язка до компаній)
3. Угоди (прив'язка до контактів та компаній)
4. Активності — дзвінки, листи, завдання
5. Коментарі та історія — через crm.timeline.comment.add

Після створення кожної сутності зберігаємо маппінг: source_id → b24_id.

$mappingFile = 'migration_map.json';
$mapping = json_decode(file_get_contents($mappingFile), true) ?: [];
$mapping['contacts'][$sourceContact['id']] = $b24ContactId;
file_put_contents($mappingFile, json_encode($mapping));

Історія активностей: дзвінки та листи

Перенесення історії комунікацій — опціональна, але цінна частина. Дзвінки з джерела → crm.activity.add з типом CALL:

$b24->call('crm.activity.add', [
    'fields' => [
        'OWNER_TYPE_ID' => 3,
        'OWNER_ID'      => $mapping['contacts'][$call['contact_id']],
        'TYPE_ID'       => 2,
        'SUBJECT'       => 'Дзвінок від ' . date('d.m.Y', strtotime($call['created_at'])),
        'DESCRIPTION'   => $call['notes'],
        'START_TIME'    => $call['created_at'],
        'END_TIME'      => $call['ended_at'],
        'DIRECTION'     => $call['direction'] === 'inbound' ? 1 : 2,
        'COMPLETED'     => 'Y',
    ],
]);

Контроль якості після перенесення

Після міграції — обов'язкова звірка:

SELECT COUNT(*) FROM hubspot_contacts WHERE is_deleted = 0;
# → 12 847

SELECT COUNT(*) FROM b_crm_contact WHERE DELETED = 'N';
# → 12 839  ← 8 записів втрачено — розслідуємо

Розбіжності логуються та аналізуються: зазвичай це дублі або записи з невалідними даними.

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

Ми надаємо повний комплекс послуг:

• Аудит вихідної CRM — аналіз моделі даних, виявлення дублів та невалідних записів.
• Створення маппінг-карти — зіставлення всіх полів та типів.
• Розробка скриптів міграції — на PHP/JavaScript з використанням REST API.
• Тестова міграція — на копію даних, перевірка цілісності.
• Фінальне перенесення — з мінімальним даунтаймом (зазвичай у вихідні).
• Пост-міграційна підтримка — 2 тижні консультацій та доробок.
• Документація — опис усіх створених полів та зв'язків.

Вартість міграції визначається після аналізу обсягу даних та складності маппінгу. Економія при замовленні комплексної міграції замість поетапного перенесення може бути значною.

Строки виконання

Вартість розраховується індивідуально залежно від складності маппінгу. Зв'яжіться з нами для точної оцінки вашого проекту.

Успішна міграція — це коли менеджери в Бітрікс24 наступного дня бачать повну історію відносин з клієнтами, наче завжди працювали тут. Замовте консультацію — ми оцінимо проект за один день.

Офіційний посібник з REST API Бітрікс24

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