37,000 записів мігрувало через 3 платформи за 2 тижні — нульові дані
Повна міграція даних CRM для брокера медичного страхування Medicare: RadiusBob → GoHighLevel + HealthSherpa
---
Ситуація
Брокер медичного страхування Medicare з ~1,600 клієнтів здійснював операції через три роз'єднані системи: RadiusBob (старий CRM), GoHighLevel (новий CRM) та HealthSherpa Medicare (платформа для реєстрації). Агенти щодня вручну звіряли всі три системи — не було єдиного джерела правди, автоматизація була неможлива.
Проблема
Роки історії клієнтів зберігалися в RadiusBob: 1,593 контакти, 1,222 страхових полісів, 32,507 нотаток про взаємодію та 793 зв'язки між контактами. Це не був експорт CSV — це була повна реконструкція через три API з різними авторизаціями, обмеженнями швидкості та форматами даних.
Будь-яка втрата запису означала ризик невідповідності. Ручна міграція зайняла б місяці та призвела б до помилок на кожному етапі.
Рішення
Я створив відновлювальний конвеєр міграції на Python (Docker + Supabase як трекер стану синхронізації). Статус кожного запису відстежувався індивідуально — якщо процес зупинився на запису 500, він відновлювався на 501 без жодних дублікатів.
Дедуплікація контактів: GoHighLevel вимагає унікальних телефонів/електронних адрес, але RadiusBob дозволяв спільні номери (одружені пари). Конвеєр виявляв дублікати з відповідей помилок API, оновлював існуючі записи та генерував звіт (163 групи дублікатів) для перегляду клієнтом.
Відповідність HealthSherpa: стратегія з трьох проходів — спочатку за ID бенефіціара Medicare (найвища впевненість), потім за ім'ям + ДР/електронною адресою/телефоном, потім створення нових записів для невідповідних контактів. Кожне співпадіння зберігало пряме посилання на реєстрацію для доступу в один клік з GHL.
Записи полісів: схема користувацького об'єкта в GHL з 15 полями. Виявлено та оброблено не задокументовані особливості API через систематичне тестування.
32,507 нотаток: Паралельна обробка з 8 одночасними запитами API скоротила час імпорту з 9+ годин до ~1 години, залишаючись в межах обмежень швидкості.
793 зв'язки: Складено 10 типів зв'язків, що обробляють як двосторонні (чоловік і дружина), так і односторонні (батько-дитина) асоціації. 260 не відображених типів задокументовано для перегляду клієнтом.
Технічний стек: Python 3.11, Docker, Supabase (PostgreSQL), GoHighLevel API, HealthSherpa Medicare API, asyncio
Результати
- ~37,000 загальних записів мігрувало через 3 платформи
- 100% контактів імпортовано (1,593/1,593)
- 100% нотаток збережено (32,507/32,507)
- 99.3% полісів імпортовано (1,214/1,222)
- 8 разів швидший імпорт нотаток через паралельну обробку
- Нульова втрата даних — кожен імпортований запис мігрував з повною історією
- Доставка за 2 тижні від початку до завершення
- Посилання на реєстрацію Medicare в один клік на кожному записі клієнта
Як це працює
1. Витяг — витягти всі дані з API RadiusBob
2. Трансформація — нормалізувати формати, очистити дані, перевірити поля, дедуплікація
3. Завантаження — надіслати контакти до GHL, відповідність HealthSherpa через стратегію з трьох проходів
4. Зв'язок — створити записи полісів, прикріпити нотатки, побудувати асоціації зв'язків
5. Перевірка — звірка кількостей, звіт про дублікати, аудит валідації
Кожен етап є ідемпотентним і відновлювальним. Конвеєр може повторно виконуватись без дублікатів або втрати прогресу.
---
Ситуація
Брокер медичного страхування Medicare з ~1,600 клієнтів здійснював операції через три роз'єднані системи: RadiusBob (старий CRM), GoHighLevel (новий CRM) та HealthSherpa Medicare (платформа для реєстрації). Агенти щодня вручну звіряли всі три системи — не було єдиного джерела правди, автоматизація була неможлива.
Проблема
Роки історії клієнтів зберігалися в RadiusBob: 1,593 контакти, 1,222 страхових полісів, 32,507 нотаток про взаємодію та 793 зв'язки між контактами. Це не був експорт CSV — це була повна реконструкція через три API з різними авторизаціями, обмеженнями швидкості та форматами даних.
Будь-яка втрата запису означала ризик невідповідності. Ручна міграція зайняла б місяці та призвела б до помилок на кожному етапі.
Рішення
Я створив відновлювальний конвеєр міграції на Python (Docker + Supabase як трекер стану синхронізації). Статус кожного запису відстежувався індивідуально — якщо процес зупинився на запису 500, він відновлювався на 501 без жодних дублікатів.
Дедуплікація контактів: GoHighLevel вимагає унікальних телефонів/електронних адрес, але RadiusBob дозволяв спільні номери (одружені пари). Конвеєр виявляв дублікати з відповідей помилок API, оновлював існуючі записи та генерував звіт (163 групи дублікатів) для перегляду клієнтом.
Відповідність HealthSherpa: стратегія з трьох проходів — спочатку за ID бенефіціара Medicare (найвища впевненість), потім за ім'ям + ДР/електронною адресою/телефоном, потім створення нових записів для невідповідних контактів. Кожне співпадіння зберігало пряме посилання на реєстрацію для доступу в один клік з GHL.
Записи полісів: схема користувацького об'єкта в GHL з 15 полями. Виявлено та оброблено не задокументовані особливості API через систематичне тестування.
32,507 нотаток: Паралельна обробка з 8 одночасними запитами API скоротила час імпорту з 9+ годин до ~1 години, залишаючись в межах обмежень швидкості.
793 зв'язки: Складено 10 типів зв'язків, що обробляють як двосторонні (чоловік і дружина), так і односторонні (батько-дитина) асоціації. 260 не відображених типів задокументовано для перегляду клієнтом.
Технічний стек: Python 3.11, Docker, Supabase (PostgreSQL), GoHighLevel API, HealthSherpa Medicare API, asyncio
Результати
- ~37,000 загальних записів мігрувало через 3 платформи
- 100% контактів імпортовано (1,593/1,593)
- 100% нотаток збережено (32,507/32,507)
- 99.3% полісів імпортовано (1,214/1,222)
- 8 разів швидший імпорт нотаток через паралельну обробку
- Нульова втрата даних — кожен імпортований запис мігрував з повною історією
- Доставка за 2 тижні від початку до завершення
- Посилання на реєстрацію Medicare в один клік на кожному записі клієнта
Як це працює
1. Витяг — витягти всі дані з API RadiusBob
2. Трансформація — нормалізувати формати, очистити дані, перевірити поля, дедуплікація
3. Завантаження — надіслати контакти до GHL, відповідність HealthSherpa через стратегію з трьох проходів
4. Зв'язок — створити записи полісів, прикріпити нотатки, побудувати асоціації зв'язків
5. Перевірка — звірка кількостей, звіт про дублікати, аудит валідації
Кожен етап є ідемпотентним і відновлювальним. Конвеєр може повторно виконуватись без дублікатів або втрати прогресу.
Харків 
Вільний для роботи