Bitrix24 рідко кидають через “погану систему”. Кидають через те, що портал перетворився на смітник: сотні полів, які ніхто не заповнює, автоматизації, які ніхто не пам’ятає навіщо, і ліцензія, що коштує дорожче за цінність. Нижче — чек-лист міграції, яким користуємось ми.

Фаза 1: інвентаризація (тиждень 1)

1. Зніміть реальну картину використання. Скільки активних користувачів заходило в портал за останній місяць? Які розділи відкривались? Зазвичай реально живуть угоди, контакти і задачі — все інше мертве.

2. Порахуйте дані. Кількість контактів, компаній, угод (відкритих / закритих за період), лідів, задач, файлів. Це база для оцінки термінів.

3. Виявіть кастомні поля, що працюють. Поле, заповнене менш ніж у 10% записів — кандидат на смітник, а не на перенесення.

4. Задокументуйте живі автоматизації. Не всі налаштовані, а ті, що реально тригеряться. Подивіться журнал за місяць.

5. Складіть карту інтеграцій. Телефонія, форми сайту, месенджери, 1С/BAS. Для кожної: чи є аналог у цільовій системі, чи потрібен middleware (проміжний сервіс для звʼязку систем).

Фаза 2: підготовка цільової системи (тижні 2–3)

6. Спроєктуйте модель даних наново. Не копіюйте структуру Bitrix24 — вона і була проблемою. Воронки, етапи, поля — під реальний процес.

7. Складіть відповідність полів (мапінг). Таблиця “поле в Bitrix24 → поле в новій системі → правило перетворення”. Це головний документ міграції.

8. Вирішіть долю архіву. Рекомендація: активні угоди + угоди закриті за останні 1–2 роки — в нову систему; решта — в холодний архів (Excel, BigQuery, бекап порталу).

9. Налаштуйте цільову систему до міграції даних. Дані заїжджають в готову структуру, не навпаки.

10. Перепідключіть інтеграції. Телефонія і форми мають писати в нову систему з дня X.

Фаза 3: міграція і перевірка (тижні 4–5)

11. Зробіть тестову міграцію на зрізі даних. 500–1000 записів. На них ловляться помилки мапінгу, кодування, дублікатів.

12. Перевірте три класичні місця втрат:

  • коментарі та таймлайн угод — REST API віддає їх окремими запитами, у стандартному експорті їх нема;
  • зв’язки між сутностями — контакт ↔ компанія ↔ угода мають зберегтись;
  • файли — прикріплення до карток треба викачувати і перепривʼязувати.

13. Узгодьте день X і заморозку. З вечора п’ятниці портал у режимі read-only (лише перегляд, без змін), за вихідні переноситься дельта (дані, що змінились після тестового перенесення), в понеділок команда в новій системі.

14. Мігруйте бойові дані. За готовим, перевіреним на тесті сценарієм перенесення.

15. Звірте цілісність. Кількість записів по кожній сутності, вибіркова перевірка 50 випадкових карток вручну, перевірка сум по відкритих угодах.

16. Не вимикайте Bitrix24 одразу. Місяць у read-only як довідка — дешева страховка.

Після міграції

17. Перший тиждень — hypercare (активна підтримка одразу після запуску). Щоденний збір питань команди, швидкі правки полів і автоматизацій. Саме тут система або приживається, або ні.

18. Через місяць — ревізія. Що з перенесеного не використовується? Які поля просять менеджери? Система має жити і змінюватись.

Міграція — це не “перелити дані”, а нагода перебудувати процес без баласту. Команди, які це розуміють, отримують нову систему, що працює краще за стару з першого тижня.