La parte técnica de una migración de CRM —exportar un CSV, subirlo a otra plataforma— se puede hacer en una tarde. El problema es que eso no es migrar: es trasladar registros y dejar atrás el negocio. El historial de interacciones que explica por qué un cliente compró. Las notas de llamada que documentan lo que prometió el comercial antes de firmar. Las automatizaciones que mueven leads de una etapa a otra sin intervención humana. Las reglas de asignación que garantizan que cada deal llega al vendedor correcto.
Todo eso son metadatos. Y los metadatos son, en realidad, los datos que importan. Un contacto sin historial es solo un nombre y un email. Una oportunidad sin notas es un número en un pipeline que nadie sabe interpretar. Cuando se migra sin estrategia, lo que se pierde no son los registros —esos sí llegan— sino el contexto que los hace utilizables.
Esta guía cubre el proceso completo de migración a HubSpot CRM desde Salesforce o Zoho: cómo auditar el sistema de origen, cómo mapear objetos y campos, cómo limpiar los datos antes de mover nada, cómo configurar HubSpot para recibirlos y cómo validar que la integridad se ha mantenido antes de activar automatizaciones y desconectar el sistema anterior.
El origen de la migración condiciona el nivel de complejidad y el tiempo necesario. No es lo mismo venir de Salesforce que de Zoho CRM, aunque en ambos casos el destino sea el mismo.
Salesforce es el CRM con mayor capacidad de personalización del mercado, y esa flexibilidad es exactamente lo que complica la migración. En una instalación madura de Salesforce es habitual encontrar decenas de objetos personalizados creados a medida, campos con lógica de validación, reglas de flujo construidas sobre el motor de automatización propietario, reportes complejos con métricas calculadas y un ecosistema de integraciones montado sobre AppExchange.
La exportación de datos de Salesforce está bien documentada y los formatos son estándar, pero el verdadero reto no está en la exportación sino en el mapeo: muchos de esos objetos y campos personalizados no tienen un equivalente directo en HubSpot y requieren decisiones de diseño antes de importar. Además, las licencias de Salesforce se facturan por usuario y muchos equipos han creado usuarios de integración o usuarios de sistema que hay que inventariar y gestionar antes del cutover.
Complejidad estimada: alta. Tiempo mínimo recomendado: 6-10 semanas para una migración ordenada.
Zoho CRM tiene una arquitectura más cercana a HubSpot en términos conceptuales —módulos en lugar de objetos, automatizaciones más lineales— lo que facilita el mapeo inicial. Sin embargo, la fragmentación es el problema central: muchas empresas que usan Zoho tienen datos dispersos entre Zoho CRM, Zoho Campaigns, Zoho Desk y Zoho Analytics, y consolidar esa información antes de migrar requiere trabajo adicional.
El sistema de automatización de Zoho —Blueprint para procesos, Workflow Rules para automatizaciones simples— tiene lógicas que no se trasladan directamente a los workflows de HubSpot. No son más complejas, pero son distintas y requieren ser reinterpretadas, no copiadas. El historial de actividades también puede estar fragmentado si el equipo ha utilizado la integración nativa de email de Zoho en lugar del módulo de actividades.
Complejidad estimada: media. Tiempo mínimo recomendado: 4-7 semanas para una migración ordenada.
Una migración bien ejecutada tiene siete fases. Saltarse alguna es la causa más habitual de los problemas post-migración: datos duplicados, campos que no llegan, automatizaciones que se activan sobre registros incompletos.
Antes de tocar nada, hay que saber exactamente qué hay en el sistema actual. Eso significa documentar todos los objetos activos y su volumen de registros, todos los campos —estándar y personalizados— con su tipo de datos y su tasa de completitud, todas las automatizaciones activas con su lógica y sus triggers, todas las integraciones activas con sistemas externos y el modelo de permisos y roles de usuario.
Un campo con un 3% de completitud no merece ser migrado: probablemente sea un campo que nadie ha usado en dos años. Una automatización que lleva inactiva seis meses no merece ser reconstruida: es una oportunidad para eliminar deuda técnica. La auditoría no es burocracia: es el momento de decidir qué se lleva y qué se deja atrás.
El mapeo es la pieza intelectualmente más exigente de todo el proceso. Cada objeto del sistema de origen necesita un equivalente en HubSpot, y cada campo dentro de ese objeto necesita una propiedad de destino con el mismo tipo de datos.
En Salesforce, los Leads y los Contacts son objetos separados. En HubSpot, existe el mismo concepto de Contact para ambos. Eso implica una decisión: ¿se migran los Leads de Salesforce como Contacts en HubSpot? ¿Con qué criterio de cualificación? Las Accounts de Salesforce equivalen a las Companies de HubSpot. Las Opportunities equivalen a los Deals. Las Activities —Tasks y Events— equivalen a Activities en HubSpot, pero con matices en el modelo de asociación.
En Zoho, los Leads, Contacts, Accounts y Deals tienen equivalencias más directas con los objetos de HubSpot. El mapeo es más limpio, pero los campos personalizados de los módulos de Zoho siguen requiriendo revisión campo a campo.
El resultado de este paso debe ser una hoja de mapeo documentada: objeto origen → objeto destino, campo origen → propiedad destino, tipo de datos, transformaciones necesarias (por ejemplo, un campo de selección múltiple en Zoho que en HubSpot debe ser una propiedad de checkbox).
Los datos sucios migran sucios. Antes de exportar nada, hay que ejecutar un proceso de limpieza en el sistema de origen: deduplicar contactos y empresas, normalizar valores de campos de selección (los valores mal escritos o inconsistentes crearán propiedades corruptas en HubSpot), archivar o eliminar registros obsoletos que no tienen actividad en los últimos doce o dieciocho meses y estandarizar formatos de fecha, teléfono y país.
Este paso tiene un beneficio adicional: reduce el volumen de datos a migrar y, con ello, el tiempo de importación y el coste de licencias en HubSpot si el modelo de pricing está basado en número de contactos.
HubSpot debe estar configurado para recibir los datos antes de que llegue ningún registro. Eso incluye crear todas las propiedades personalizadas que el mapeo ha identificado, configurar los pipelines de deals con las etapas correctas —no usar los nombres genéricos de HubSpot si el negocio tiene etapas propias—, configurar los equipos y usuarios con sus roles y permisos, y preparar las listas y segmentos de partida que se necesitarán para el go-live.
Un error habitual es importar primero y configurar después. El resultado es que los registros llegan a propiedades que no existen y HubSpot los trata como texto libre, o llegan a pipelines incorrectos que después hay que corregir registro a registro.
Antes del go-live, la migración debe ejecutarse en un portal de prueba o con una muestra representativa del 5-10% de los datos reales. El objetivo es verificar que el proceso de importación funciona correctamente, que los campos llegan a las propiedades correctas, que las asociaciones entre objetos —contacto asociado a empresa, deal asociado a contacto— se mantienen, y que no hay errores de formato o tipología de datos que HubSpot rechace.
Esta fase es la que más equipos se saltan por presión de tiempo. Y es la que más errores evita.
Una vez ejecutada la migración completa, la validación de integridad no puede ser solo cuantitativa —"hemos migrado 12.400 contactos y en el origen había 12.400"—. Tiene que ser también cualitativa: verificar una muestra representativa de registros comparando campo a campo entre el sistema de origen y HubSpot, comprobar que las asociaciones entre objetos son correctas, verificar que el historial de actividades está vinculado a los registros correctos y confirmar que los campos de fecha no han sufrido problemas de zona horaria o formato.
Un protocolo de validación documentado con una lista de comprobación —no un proceso ad hoc— es lo que distingue una migración controlada de una migración con sorpresas a las dos semanas del go-live.
El go-live de una migración bien ejecutada es un evento tranquilo. El equipo lleva días o semanas trabajando en paralelo en HubSpot, los datos están validados y las automatizaciones están probadas. El cutover es simplemente el momento en que se desactivan las automatizaciones del sistema anterior, se actualiza el routing de formularios y emails al nuevo portal y se comunica al equipo que HubSpot es el sistema de registro único.
La desactivación del sistema anterior no tiene que ser inmediata. Mantener el acceso de solo lectura durante 30-60 días después del go-live es una práctica recomendada para resolver cualquier consulta sobre datos históricos que no se puedan encontrar en HubSpot.
Hay elementos que no existen como datos exportables y que requieren ser recreados manualmente en HubSpot:
Los tiempos varían según el volumen de datos, la complejidad de los objetos personalizados y el número de automatizaciones activas. Estos son los rangos habituales en proyectos de migración con metodología ordenada:
Estas estimaciones asumen dedicación parcial del equipo interno y un partner especializado liderando la migración. Si el equipo interno asume toda la carga sin experiencia previa en migraciones de CRM, los plazos se multiplican y el riesgo de errores aumenta significativamente.
Cada migración tiene sus particularidades. El volumen de datos, el estado del sistema de origen y la madurez de los procesos internos condicionan el enfoque. Si quieres saber qué implica tu caso concreto antes de comprometerte con un plan, nuestro equipo puede hacer una valoración inicial sin compromiso.
Habla con nuestro equipo de migración →
MomentumHUB es HubSpot Gold Partner, top 10% mundial, certificado 2025. Especializados en RevOps e implementaciones CRM para equipos B2B.
Técnicamente sí: HubSpot tiene herramientas de importación nativas y la documentación está disponible. El problema no es la herramienta sino el proceso. Una migración sin experiencia previa tiende a subestimar el tiempo de mapeo, a omitir pasos de limpieza y a no prever los problemas de integridad que aparecen después del go-live. Para migraciones con menos de 3.000 contactos, sin objetos personalizados y sin automatizaciones críticas, es factible hacerlo internamente con la guía adecuada. Para todo lo que supere ese umbral, el coste de los errores de una migración mal ejecutada supera con creces el coste de un partner especializado.
No se pierden si el mapeo se ha hecho correctamente. Los campos personalizados de Salesforce deben tener una propiedad equivalente creada en HubSpot antes de la importación. El riesgo no es la pérdida sino la distorsión: campos de tipo lista de selección en Salesforce que no tienen los mismos valores en HubSpot, campos de fecha con problemas de formato, campos de relación entre objetos que no tienen un equivalente directo. Un mapeo bien documentado previene todos estos problemas.
El historial de actividades —emails, llamadas, notas— puede migrarse, pero con condiciones. Los emails enviados desde el sistema de origen no se migran como actividades de email nativas de HubSpot: se importan como notas o actividades genéricas, sin el formato de email. Las llamadas registradas en el CRM de origen se pueden migrar como actividades de llamada, pero sin el audio ni la transcripción si los hubiera. El historial nativo de HubSpot —emails enviados desde HubSpot, llamadas con transcripción— empieza a construirse desde el go-live. Lo anterior queda como registro histórico consultable.
Depende del volumen de datos, la complejidad del sistema de origen y el alcance de la reconstrucción de automatizaciones e integraciones. No hay un precio estándar porque no hay dos migraciones iguales. Lo que sí existe es un rango razonable: una migración básica con pocos objetos personalizados puede resolverse en una implementación de nivel medio, mientras que una migración compleja desde Salesforce con múltiples integraciones y automatizaciones críticas puede requerir un proyecto de mayor alcance. La valoración inicial es gratuita y sin compromiso.