Міграція даних з Salesforce у Бітрікс24
Salesforce зберігає дані у своїй об'єктній моделі: Account, Contact, Lead, Opportunity, Task, Event. Кожен об'єкт може містити сотні кастомних полів, налаштованих під конкретний бізнес. Прямого імпорту між Salesforce і Бітрікс24 не існує. Завдання вирішується через проміжний шар: експорт через Salesforce API або Data Export, трансформація даних і завантаження через REST API Бітрікс24. Ми накопичили досвід десятків успішних міграцій і гарантуємо цілісність даних. Замовте міграцію під ключ — оцінимо ваш проект за 1 день.
Чому пряма міграція з Salesforce у Бітрікс24 неможлива?
Salesforce використовує власну об'єктну модель з унікальними ідентифікаторами. Бітрікс24 оперує своєю структурою інфоблоків і CRM-сутностей. Відмінності в типах полів (lookup, picklist, formula), форматах телефонних номерів і адрес вимагають обов'язкової трансформації. Крім того, у Salesforce накопичується сміття: видалені записи, дублікати, порожні поля. Без попереднього аудиту прямий перенесення призведе до помилок.
Аналіз структури даних Salesforce
Перший крок — аудит реально використовуваних даних. У типовому Salesforce-акаунті накопичується кілька років сміття: видалені записи в кошику, дубльовані контакти, застарілі поля з нульовим заповненням. Перед міграцією необхідно:
- Вивантажити схему об'єктів через
describeSObjects() API і скласти маппінг на сутності Бітрікс24.
- Перевірити обсяги: Salesforce Data Export дає CSV-файли, розбиті за об'єктами. Зв'язки між записами (lookup-поля) зберігаються як Salesforce ID — їх потрібно резолвити в нові ID Бітрікс24.
- Оцінити кастомні об'єкти (
Custom Objects): вони можуть не мати прямого аналога в Бітрікс24. Для них створюються користувацькі поля або окремі розділи CRM.
Маппінг базових об'єктів:
| Salesforce |
Бітрікс24 |
Примітка |
| Account |
Компанія (crm.company) |
Ієрархія Account не підтримується нативно |
| Contact |
Контакт (crm.contact) |
Прив'язка до компанії через COMPANY_ID |
| Lead |
Лід (crm.lead) |
Статуси мапляться вручну |
| Opportunity |
Угода (crm.deal) |
Етапи воронки перестворюються |
| Task |
Завдання (tasks.task) |
Прив'язка до CRM-сутності через UF_CRM_TASK |
| Case |
Тікет (helpdesk) |
Тільки в Бітрікс24 Enterprise/On-Premise |
Технічний процес міграції
Експорт із Salesforce виконується двома способами:
- Data Export (Setup → Data Export) — повний дамп у ZIP з CSV. Зручно для разової міграції, але вивантаження формується до 48 годин. При великому обсязі файли розбиваються на частини за об'єктом.
- Salesforce API (REST/Bulk API 2.0) — переважно для великих обсягів (від 50 000 записів). Bulk API 2.0 працює асинхронно: створюєте job, завантажуєте дані, чекаєте виконання, завантажуєте результат.
POST /services/data/v58.0/jobs/ingest
{
"operation": "query",
"query": "SELECT Id, Name, Phone, BillingCity FROM Account WHERE IsDeleted = false"
}
Трансформація даних — найбільш трудомісткий етап. Проблеми, які зустрічаються майже завжди:
- Телефони в Salesforce зберігаються в довільному форматі; Бітрікс24 приймає їх через
crm.contact.update у полі PHONE як масив з типом WORK/MOBILE/HOME.
- Адреси в Salesforce — плоска структура (BillingStreet, BillingCity); у Бітрікс24 адреса компанії зберігається через
crm.address.add з прив'язкою до ENTITY_TYPE_ID=4 (компанія).
- Користувачі: власник запису в Salesforce (OwnerId) потрібно зіставити з користувачами Бітрікс24 через
user.get за email або іменем.
Завантаження в Бітрікс24 через REST API:
-
crm.contact.add / crm.company.add — додавання по одному запису; при великих обсягах використовуйте batch-метод (до 50 запитів за раз).
- Порядок завантаження критичний: спочатку компанії, потім контакти (щоб була можливість вказати COMPANY_ID), потім угоди.
- Зберігайте маппінг Salesforce ID → Бітрікс24 ID у проміжній таблиці — він потрібен для прив'язки завдань, подій, файлів.
Які дані мігрувати в першу чергу?
У першу чергу переносяться компанії та контакти — вони є основою для прив'язки всіх інших сутностей. Потім угоди та ліди. Історія взаємодій та вкладення — на останньому етапі, оскільки обсяг даних може бути значним. Листи, дзвінки, зустрічі з Salesforce Activity History мігрують у Бітрікс24 як справи CRM (crm.activity.add). Вкладені файли — через crm.timeline.comment.add з base64-кодуванням або попереднім завантаженням через disk.folder.uploadfile. Обсяг вкладень нерідко стає сюрпризом: 5–10 років роботи в Salesforce легко дають 50–100 ГБ файлів. Це вимагає окремої стратегії: або вибіркова міграція (тільки останні N років), або архівний доступ до Salesforce залишається на період адаптації.
Скільки часу займає міграція?
| Масштаб |
Обсяг даних |
Термін |
| Малий бізнес |
до 10 000 записів, стандартні поля |
2–3 тижні |
| Середній бізнес |
10 000–100 000 записів, кастомні об'єкти |
4–8 тижнів |
| Великий |
100 000+ записів, історія 5+ років, вкладення |
2–4 місяці |
Після завершення перенесення обов'язкова фаза верифікації: вибіркова звірка записів, перевірка зв'язків, тест сповіщень і автоматизацій у Бітрікс24. Паралельна робота у двох системах на перехідний період — стандартна практика. Зв'яжіться з нами для отримання консультації та точної оцінки вашого проекту. Bulk API 2.0 у 5 разів швидший за стандартний REST API при обсягах від 50 000 записів. Досвід наших інженерів підтверджений сертифікатами та десятками успішних проектів.
Wikipedia: Salesforce — документація Salesforce 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 день. Оцінимо ваш проєкт безкоштовно — напишіть нам для розрахунку.
