Чи можна перенести абсолютно все?
Не завжди. Експорт однієї системи та імпорт іншої можуть підтримувати різні типи записів. Окремо перевірте нотатки, файли, листування, часові мітки й авторство. Для KeyCRM, HubSpot, Pipedrive, Zoho CRM та Dynamics 365 доступність конкретної операції потрібно підтвердити для вашого продукту й доступу. Якщо історію неможливо відтворити коректно, погодьте формат архіву до запуску.
Побудуйте карту полів і зв’язків
Для кожного об’єкта запишіть старий ідентифікатор, відповідник у новій системі, правила перетворення полів і залежності. Спочатку мають існувати записи, на які посилаються інші об’єкти. Не замінюйте відповідального довільним користувачем лише для успішного імпорту.
- Компанії, контакти та їхні зв’язки.
- Угоди або замовлення, статуси й відповідальні.
- Завдання, строки та необхідна історія.
- Валюта, часовий пояс і довідникові значення.
Сценарій: одна людина має дві картки
У демонстраційному прикладі клієнт спочатку залишив робочий email, а пізніше замовив за телефоном. Однакове ім’я не є достатнім доказом, що картки можна об’єднати. Визначте надійні ознаки, винесіть неоднозначні пари на ручну перевірку й збережіть походження записів. Масове злиття без погодженого правила може зіпсувати історію різних людей.
Що перевіряти після тестового імпорту?
Почніть з обмеженої вибірки: звичайний клієнт, кілька контактів однієї компанії, угода з історією та запис із нестандартними полями. Кількість рядків — не єдиний критерій успіху. Відкрийте картки як майбутній користувач і перевірте, чи можете продовжити роботу.
- Кількість записів і перелік відхилених рядків.
- Зв’язки, суми, валюти та дати.
- Відповідальні й видимість для різних ролей.
- Повторний імпорт не створює неконтрольованих дублів.
Приклад протоколу приймання
Використайте ці перевірки на тестових даних. Для кожного відхилення запишіть причину та погоджене рішення.
Таблицю можна прокрутити горизонтально.
| Перевірка | Що зробити | Коли не запускати |
|---|---|---|
| Відкрита угода | Увійти як менеджер, відкрити клієнта й наступне завдання. | Угода є, але менеджер не має доступу або втрачено клієнта. |
| Історія | Зіставити контрольні нотатки, дати й вкладення з джерелом. | Обов’язкова історія відсутня й немає погодженого архіву. |
| Повторний імпорт | Повторити тестову вибірку за визначеними правилами оновлення. | Повтор створює нові записи замість очікуваного оновлення. |
Висновок. Після погодження запуску зміни, зроблені вже в новій CRM, також потрібно враховувати в плані відновлення. Просте повернення старої копії їх не збереже.
Як організувати перехід команди?
Оберіть момент, після якого нові записи створюються лише в новій CRM. Якщо зупинити роботу на час перенесення неможливо, заздалегідь визначте, як довнести зміни після першого експорту. У команди має бути одна зрозуміла інструкція: де працювати зараз і кому повідомляти про проблему.
Запуск підтверджує визначена людина після контрольних перевірок. До цього не видаляйте вихідну базу та перевірені резервні копії. Узгодьте умови зупинки й порядок відновлення; сам факт наявності резервної копії ще не доводить, що з неї можна відновити роботу.
Що потрібно для оцінки міграції?
Назви й редакції систем, приблизний обсяг записів, перелік потрібних об’єктів, нестандартних полів та інтеграцій. На старті достатньо структури файлу з вигаданими даними. Перед роботою з реальною базою погоджуємо мінімальні доступи, місце зберігання копій та правила їх видалення після приймання.