Перенос CRM з Megaplan у Бітрікс24: угоди, контакти, задачі

Переїзд до Бітрікс24 з Megaplan: досвід п'ятдесяти проектів

При міграції з Megaplan у Бітрікс24 ми стикаємося з типовою проблемою: Megaplan не надає повного API для всіх сутностей, і прямий експорт через CSV дає плоскі дані без зв'язків. Наш досвід показує, що тільки глибока кастомна інтеграція через REST API Бітрікс24 та Megaplan REST API забезпечує перенесення всієї історії та вкладень. Ми гарантуємо збереження даних та мінімальний даунтайм. Використання API Megaplan дає в 10 разів більше структурованих даних, ніж стандартний CSV-експорт. Ми виконали більше 50 міграцій CRM за 5 років роботи — це дозволяє нам гарантувати результат. Кожен проект включає детальний аналіз структури даних, маппінг полів та тестування на вибірці.

Типові сценарії включають перенесення від 500 до 50 000 угод з тисячами контактів та задачами. На старті ми завжди проводимо аудит даних і складаємо карту відповідностей. Це мінімізує ризики та прискорює процес.

Основні проблеми при перенесенні з Megaplan

Перша проблема — обмеженість REST API Megaplan: недоступні історія змін полів, видалені записи та звіти. Друга — невідповідність стадій та воронок: у Megaplan стадії задаються інакше, ніж у Бітрікс24, і вимагають ручного перестворення. Третя — перенесення вкладень та коментарів до задач: файли потрібно завантажувати та завантажувати заново, зберігаючи прив'язку до задач.

Як відбувається перенесення з Megaplan у Бітрікс24?

Процес ділиться на п'ять етапів:

1. Аналітика. Вивчення структури даних у Megaplan: список сутностей, кастомних полів, зв'язків між угодами, контактами та задачами. Виявляємо обмеження API.
2. Проектування. Складаємо карту маппінгу полів та сутностей. Визначаємо спосіб перенесення вкладень та коментарів.
3. Розробка скриптів. Пишемо скрипти на PHP 8.1+, використовуючи для Megaplan Guzzle HTTP-клієнт, для Бітрікс24 — REST OAuth. Реалізуємо посторінкове вивантаження та завантаження з повтором при помилках. Скрипти обробляють угоди в 3 рази швидше стандартних рішень за рахунок паралельних запитів.
4. Тестування. Переносимо тестову вибірку (50–100 записів) та звіряємо дані. Виправляємо невідповідності.
5. Деплой та перевірка. Запускаємо фінальну міграцію, проводимо контрольну звірку 5% записів кожного типу. Передаємо документацію.

Що можна отримати з Megaplan

Megaplan надає REST API версії 3. Доступні сутності: угоди, контакти, компанії, задачі, співробітники. Через API недоступні історія змін полів, видалені записи та звіти в сирому вигляді. Офіційний експорт у CSV дає плоску таблицю без прив'язок — підходить тільки для невеликих обсягів.

Стратегія міграції через API

Використовуємо API Megaplan для посторінкового отримання даних, перетворюємо та завантажуємо через REST API Бітрікс24:

<?php
// Отримання угод з Megaplan
$page = 1;
$deals = [];
do {
    $response = $megaplanClient->get('/api/v3/deals', [
        'limit' => 100,
        'offset' => ($page - 1) * 100,
        'fields' => 'id,name,amount,status,responsible,company,contact,created_at',
    ]);
    $deals = array_merge($deals, $response['data']);
    $page++;
} while (count($response['data']) === 100);
?>

Маппінг сутностей

Поля угод у Megaplan включають кастомні поля (Додаткові поля) — їх потрібно ідентифікувати через API (/api/v3/deal-fields) та створити відповідні користувацькі поля в Бітрікс24 через crm.userfield.add.

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

Неправильна відповідність полів призводить до втрати даних. Наприклад, якщо стадії угод не перестворені в Бітрікс24, угоди завантажуються без воронки. Ми ретельно аналізуємо всі кастомні поля та зв'язки, щоб кожен запис став на своє місце.

Задачі та коментарі

Задачі Megaplan мають ієрархічну структуру (підзадачі). У Бітрікс24 ієрархія задач реалізована через поле PARENT_ID. Коментарі до задач переносяться через task.commentitem.add.

Вкладення до задач завантажуються з Megaplan та завантажуються на Диск Бітрікс24 через disk.folder.uploadfile, потім прив'язуються до задачі через task.item.update із вказівкою UF_TASK_WEBDAV_FILES.

Воронки та стадії

Стадії угод у Megaplan не мають прямої відповідності стадіям Бітрікс24. Необхідно:

1. Отримати список стадій Megaplan (/api/v3/deal-stages)
2. Перестворити воронки та стадії в Бітрікс24 через crm.dealcategory.add та crm.status.add
3. Скласти таблицю відповідностей для маппінгу при завантаженні угод

Типові строки

Після міграції необхідний період перевірки: вибіркова звірка 50–100 записів кожного типу для підтвердження коректності перенесення даних та зв'язків.

Типові помилки при міграції та як їх уникнути

• Неправильний маппінг кастомних полів призводить до втрати даних. Завжди перевіряйте через API список полів.
• Завантаження вкладень без перевірки розміру файлу — API Бітрікс24 має обмеження у 50 MB. Великі файли потрібно стискати.
• Ігнорування тайм-аутів API: при великому обсязі запити можуть падати. Використовуйте повторні спроби з експоненційною затримкою.

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

• Розробка та запуск скриптів міграції
• Маппінг всіх полів та сутностей
• Перенесення вкладень та коментарів
• Тестування на вибірці та повна перевірка
• Документація з маппінгу та інструкція для користувачів
• Підтримка протягом 2 тижнів після міграції

В одному з проектів ми переносили 25 000 угод з 300 кастомними полями. API Megaplan віддавав тільки 100 записів за раз, і обробка зайняла 3 дні через обмеження за частотою запитів. Ми реалізували асинхронне вивантаження з експоненційним backoff — це скоротило час на 40%. Повна міграція з тестуванням зайняла 4 тижні, після чого всі користувачі приступили до роботи без затримок.

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

Час на налаштування CRM після міграції скорочується до 70%, а вартість розраховується індивідуально під ваш обсяг. Докладніше про REST API Бітрікс24 та Megaplan REST 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().

Як відбувається міграція?

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