Compatibilidad de módulos

Análisis hecho contra las 44,918 contactos / 51,495 oportunidades / 44,909 conversaciones reales de Trebol Insurance.

Leyenda:

• ✅ Existe en ambos — mapping directo
• ⚠️ Existe pero distinto — requiere transformación
• 🆕 Solo en GHL — hay que crear colección nueva en imcrmdev
• ❌ Solo en imcrmdev — quedará vacío (campo del CRM destino sin origen)

Resumen por módulo

Módulo GHL	Volumen	Destino imcrmdev	Estado	Notas
Sub-account / location	1	companies	✅	Bootstrap inicial
Users	~6	users	✅	Mapping directo
Custom Field definitions (catálogo)	227	—	⏸️	TODO — ver todo.md. El script SÍ lee las definiciones en runtime para resolver IDs a keys legibles, pero NO persiste el catálogo.
Custom Values	varios	custom_values	🆕	Colección nueva
Tags	docenas	tags	🆕	Colección nueva
Pipelines (ventas)	27	sales_pipelines	🆕	El service_pipelines actual es para tickets, no se reutiliza
Pipeline stages	~250	sales_pipeline_stages	🆕	Colección nueva
Contacts (persona)	44,918	contacts_new (service_type=residential)	✅	Mapping rico
Businesses (B2B Companies)	6	contacts_new (service_type=corporate)	✅	Convención del destino: "company" = contacto corporate. Solo 0.01% de contactos persona tienen businessId set. Vínculo persona→business via custom_fields.parent_business_external_id.
Notes (por contacto)	variable	contacts_new.notes[]	✅	Embebido
Tasks (por contacto)	variable	tasks	✅	Mapping directo
Appointments (por contacto)	variable	—	⏸️	TODO — ver todo.md
Opportunities	51,495	opportunities	✅	Mapping completo
Conversations	44,909	conversations	🆕	Colección nueva
Messages	~450k	messages	🆕	Colección nueva
Calendars (catálogo)	múltiples	—	⏸️	TODO — ver todo.md
Calendar events	variable	—	⏸️	TODO — ver todo.md
Forms	varios	forms	🆕	Colección nueva
Form submissions	variable	form_submissions	🆕	Colección nueva
Workflows	varios	—	❌	No se migra (lógica de automatización propia de GHL)
Campaigns	varios	—	❌	No se migra
Email/SMS templates	varios	email_templates	⚠️	Solo email; SMS no tiene destino
Phone numbers (Twilio sub)	—	—	❌	Configuración de telefonía propia de GHL
Funnels / Websites	—	—	❌	Builder propio de GHL
Memberships / Courses	—	—	❌	Producto distinto
Affiliate manager	—	—	❌	Producto distinto
Invoices / Payments	—	—	❌	Trebol no usa esto en GHL (verificar)
Products	0	—	❌	Trebol no tiene productos en GHL — endpoint regresa lista vacía

Campos del destino que no se llenan (porque GHL no los tiene)

Estos vienen del modelo SEMTEC (ISP) y para Trebol (insurance) van vacíos:

contacts_new

Campo	Por qué
billing_account_id, account_id	ISP-specific
linked_status, network_status	ISP-specific
network_information[]	ISP equipos de red
onus[]	ONU/equipos de fibra
contract_info[]	ISP contratos

service_type sí se llena: residential para contactos persona, corporate para businesses migrados desde GHL.

opportunities

Campo	Por qué
serviceBundle	ISP bundles de internet/TV
installationSLA	ISP instalación
mrcType	Recurring revenue (telecoms)

Otros

• contracts, contract_lists, contract_statuses — sin uso para insurance
• products — Trebol no vende productos de catálogo en GHL en este modo
• devices, network_alerts, access_technologies — telecom-only
• service_pipelines (tickets) — Trebol usa pipelines de ventas, no de tickets

Campos de GHL que no tienen destino (se preservan en _ghl_raw)

Para cero pérdida, cada doc migrado guarda el JSON original de GHL en un campo _ghl_raw. Esto cubre:

• contact.followers[] (no hay concepto de followers en imcrm)
• contact.attributionSource, lastAttributionSource (atribución de marketing)
• opportunity.relations[] aparte del primary contact (vínculos N-N)
• conversation.scoring[]
• Cualquier custom field nuevo creado después de la migración inicial

Si más adelante imcrmdev gana esos conceptos, basta correr un script ligero que lea _ghl_raw de cada doc y populate los campos nuevos — sin volver a tocar GHL.