Перенесення даних з Microsoft Dynamics у Бітрікс24 під ключ

Міграція з Dynamics 365 на Бітрікс24

Перехід з Microsoft Dynamics 365 на Бітрікс24 — рішення, яке приймають компанії для зниження витрат на ліцензування та відповідності російському законодавству. Однак перенесення накопичених даних — нетривіальне завдання. Dynamics має одну з найскладніших об'єктних моделей серед CRM-систем: ієрархічні бізнес-одиниці, кастомні сутності, десятки типів полів (Lookup, OptionSet, Customer, PartyList), глибока інтеграція з Microsoft 365 (Outlook, Teams, SharePoint). Помилки на етапі вилучення або маппінгу призводять до втрати зв'язків, дублювання записів та зупинки бізнес-процесів. Наша команда виконує міграцію під ключ: від аудиту вихідної схеми до налаштування інтеграцій та навчання користувачів. Ми гарантуємо цілісність даних і прозорий план робіт. Зв'яжіться з нами для оцінки вашого проекту — ми підготуємо прозорий план із зазначенням термінів та бюджету.

Як уникнути втрати даних при міграції?

Ключовий етап — детальний аудит вихідної схеми. Dynamics 365 зберігає дані в SQL Server (on-premise) або Azure SQL (хмара). Основні сутності: Account (організація), Contact (фізична особа), Lead, Opportunity (угода), ActivityPointer (базовий тип активностей), PhoneCall, Email, Appointment, Task (конкретні активності), Quote, Order, Invoice (комерційні документи). Кастомні сутності створюються через Power Apps і зберігаються в таблицях з префіксом видавця. Без аналізу цих таблиць висока ймовірність пропустити пов'язані записи або некоректно перетворити типи. Особливу увагу приділяємо поліморфним типам Customer (прив'язка до Contact або Account) та PartyList (множинні учасники). Ми пишемо скрипти вибіркової перевірки після завантаження — порівнюємо кількість записів і зв'язки.

Як вилучити дані з Dynamics 365?

OData API (Web API) — рекомендований метод для хмарних і on-premise версій. Він підтримує пагінацію, фільтрацію, вибірку полів. Приклад запиту:

$response = $dynamics->get('/api/data/v9.2/accounts', [
    '$select' => 'accountid,name,telephone1,emailaddress1,websiteurl',
    '$filter' => 'statecode eq 0',
    '$top'    => 5000,
]);
// Пагінація через @odata.nextLink

Прямий SQL працює тільки для on-premise і швидший при великих обсягах. Таблиця AccountBase відповідає сутності Account, ContactBase — Contact і так далі. Схему можна отримати через Metadata API: GET /api/data/v9.2/EntityDefinitions(LogicalName='opportunity')/Attributes. Докладніше про OData API.

Маппінг сутностей: Dynamics 365 -> Бітрікс24

Що робити з кастомними полями?

Dynamics 365 підтримує десятки типів полів: Lookup, OptionSet, MultiSelectOptionSet, Money, Customer, PartyList. Найбільшу складність становлять Customer та PartyList. Перший — поліморфна прив'язка до контакту або компанії, другий — список учасників (наприклад, для активності). У Бітрікс24 ці концепції реалізуються через множинні прив'язки або кастомну розробку. Ми створюємо користувацькі поля, а для складних випадків — додаткові сутності. Приклад: поле Customer перетворюється на два окремі поля: «Контакт» і «Компанія» з правилами заповнення. Для PartyList створюємо сутність «Учасники» з прив'язкою до угоди.

Як відтворюються бізнес-процеси?

Workflows у Dynamics (тепер Power Automate) не мігрують напряму. Їх потрібно відтворити через роботи, тригери та бізнес-процеси Бітрікс24. Аналіз логіки кожного процесу — окреме завдання, яке часто займає стільки ж часу, скільки сама міграція даних. Ми документуємо кожен процес і переносимо його покроково. Наприклад, процес створення зустрічі з листа в Dynamics замінюється тригером Бітрікс24 на подію Email.

Етапи міграції

1. Аудит поточної системи — аналіз схеми Dynamics, виявлення кастомних сутностей, полів, бізнес-процесів.
2. Проектування маппінгу — зіставлення сутностей і полів (дивіться таблицю вище).
3. Вилучення даних — через OData API або прямий SQL.
4. Трансформація та завантаження в Бітрікс24 — конвертація типів (Customer, PartyList), створення кастомних полів.
5. Відтворення бізнес-процесів — заміна Power Automate на роботи Бітрікс24.
6. Інтеграція з Microsoft 365 — налаштування Outlook, календаря, диска.
7. Тестування та валідація — вибіркова перевірка записів, звірка зв'язків.
8. Запуск і супровід — навчання користувачів, підтримка перші тижні.

Інтеграція з Microsoft 365

Однією з переваг Dynamics є нативна інтеграція з Outlook, Teams, SharePoint. При переході на Бітрікс24 потрібно забезпечити аналогічні сценарії:

• Outlook → Пошта Бітрікс24 або конектор Exchange.
• Teams → Відеодзвінки Бітрікс24 (або залишити Teams для зустрічей).
• SharePoint → Диск Бітрікс24.

Ми допомагаємо налаштувати Бітрікс24 REST API для інтеграції з іншими сервісами Microsoft.

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

• Документація з маппінгу полів і сутностей.
• Скрипти вилучення та трансформації.
• Файл зі схемою перенесених даних.
• Звіт про кількість записів і помилки.
• Інструкція для користувачів.
• Підтримка два тижні після запуску.

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

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

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