Міграція даних з amoCRM в Бітрікс24: повний гайд

Міграція даних з amoCRM в Бітрікс24

Ми займаємося перенесенням CRM-систем понад 5 років та виконали вже більше 50 проектів з міграції з amoCRM в Бітрікс24. Цей процес потребує глибокого розуміння обох платформ: без грамотної стратегії ви ризикуєте втратити історію угод або створити дублі. У цій статті розберемо технічні нюанси та покажемо, як ми забезпечуємо цілісність даних.

amoCRM та Бітрікс24 — найближчі конкуренти на ринку, але їхні моделі даних суттєво відрізняються. amoCRM будується навколо угод (pipeline-центрична модель), Бітрікс24 — більш комплексна система з розділенням лідів, угод, контактів та компаній. Ця різниця визначає всю стратегію міграції.

Принципові відмінності моделей

В amoCRM «угода» (lead) — це і лід, і угода одночасно. При міграції потрібно прийняти рішення: переносити все в угоди Бітрікс24, або розбити на ліди + конвертовані угоди. Ми рекомендуємо другий варіант, оскільки він відкриває доступ до бізнес-процесів та воронок Бітрікс24.

Чому важлива правильна міграція?

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

Як ми отримуємо дані з amoCRM

amoCRM надає REST API v4. Аутентифікація через OAuth 2.0. Ліміти API: не більше 7 запитів за секунду — при вивантаженні великої бази обов'язкова затримка між запитами.

Клієнт для вивантаження контактів посторінково (250 записів за запит):

class AmoCrmClient {
    public function getContacts(int $page = 1): array {
        $url = "https://{$this->domain}.amocrm.ru/api/v4/contacts"
            . "?page={$page}&limit=250&with=leads,companies";
        $http = new \Bitrix\Main\Web\HttpClient();
        $http->setHeader('Authorization', 'Bearer ' . $this->accessToken);
        return json_decode($http->get($url)->getResult(), true);
    }
}

Маппінг воронок та статусів

Воронки amoCRM → напрямки (воронки) Бітрікс24. Створюються заздалегідь через , потім для кожної воронки — статуси через .

Маппінг зберігається у файл або таблицю для використання при перенесенні угод:

$pipelineMapping[$pipeline['id']] = $b24CategoryId;
$statusMapping[$status['id']] = 'STAGE_' . $status['id'];

Як створюються кастомні поля в Бітрікс24?

В amoCRM кастомні поля створюються довільно. Перед міграцією — створити відповідні UF-поля в Бітрікс24 через . Тип поля визначається за з API amoCRM:

• → рядок
• → ціле число
• → дата
• → список (enumeration)

Перенесення контактів

Кожен контакт amoCRM стає контактом в Бітрікс24. Телефони та email зберігаються в з кодами та . Дата створення переноситься через поле .

Після створення контакту — зберігаємо маппінг для прив'язки угод.

Перенесення угод з примітками

Угоди — центральна частина міграції. Кожна угода amoCRM переноситься в Бітрікс24 через з прив'язкою до контактів та компаній за маппінгом. Зберігаємо вихідний ID у користувацькому полі — для звірки та налагодження.

Примітки (notes) з amoCRM переносяться як timeline-коментарі через . Це зберігає історію переговорів, видиму менеджеру в картці угоди.

Завдання та дзвінки

Завдання з amoCRM переносяться через . Записи дзвінків (якщо підключена телефонія) — через з типом CALL. Це цінна історична інформація для відновлення роботи з клієнтом.

Як уникнути дублів при повторному запуску?

При повторних запусках скрипту міграції (при помилках та відновленні) потрібна перевірка: не створювати запис, якщо вже існує в Бітрікс24.

$existing = $b24->call('crm.deal.list', [
    'filter' => ['UF_CRM_AMO_ID' => $amoLead['id']],
    'select' => ['ID'],
]);

if (!empty($existing['result'])) {
    continue; // Вже перенесено
}

Валідація результатів

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

• Технічна документація: схема маппінгу, логи переносу, інструкція для адміна.
• Навчання команди: 2 вебінари по роботі в Бітрікс24, відповіді на питання в чаті.
• Тестовий прогін: міграція копії бази для перевірки.
• Гарантія: 2 тижні безкоштовної підтримки після переносу — виправляємо помилки, якщо вони виникнуть.

Терміни виконання

Перехід з amoCRM на Бітрікс24 — це зміна парадигми роботи команди. Паралельно з міграцією даних потрібне навчання новим бізнес-процесам — завдання, не менш важливе, ніж технічний перенос. Бітрікс24 пропонує більш гнучку систему: за даними Wikipedia, сучасні CRM дозволяють збільшити продажі на 29%. З нашим досвідом ви отримаєте максимум від нової платформи.

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

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