Sabemos cómo llevar tu negocio a donde quieres llegar.

Soluciona tus problemas de Marketing y Ventas con HubSpot

Agenda una llamada de 15 minutos con un especialista para revisar tu estrategia y encontrar soluciones con HubSpot Free
DFZ_montaje_02
back to blog arrow Volver al Blog

Migración a HubSpot: guía enterprise de fases, datos y riesgos

Casi todo lo que se publica sobre migrar a HubSpot describe el mismo proceso feliz de seis pasos. Esta guía se ocupa de la otra mitad: qué no se migra, qué se rompe, cuánto tarde de verdad y en qué momento del año no deberías intentarlo.

Una migración a HubSpot en una empresa grande es un proyecto de datos y de procesos, no una importación. Se estructura en seis fases —auditoría del origen, diseño del modelo destino, mapeo, migración de prueba en un entorno separado, cutover y estabilización— y su duración depende del volumen de datos, del número de integraciones y de cuántos equipos usan el sistema, no del tamaño de la empresa.

Fases de una migración a HubSpot

La diferencia entre una migración enterprise y una de empresa pequeña no está en el número de registros: está en cuántos sistemas dependen del CRM y cuántas decisiones de negocio hay que tomar antes de mover un solo dato. En una PyME migras contactos; en una empresa grande rediseñas cómo se representa el negocio.

Fase 1. Auditoría e inventario del sistema de origen

Inventario completo de objetos, campos, automatizaciones, integraciones e informes en uso. El entregable clave no es la lista: es la marca que pones al lado de cada elemento — conservar, archivar o descartar. Criterio para pasar de fase: cada campo del origen tiene una decisión tomada y un responsable que la firmó.

Fase 2. Diseño del modelo de datos destino

Aquí se decide cómo se representa el negocio en HubSpot: qué es un contacto, qué es una empresa, qué justifica un objeto personalizado, cómo se asocian entre sí y qué propiedades son obligatorias. Es la fase más barata de hacer bien y la más cara de rehacer. Criterio para pasar: el modelo está documentado y validado contra los tres o cuatro informes que la dirección mira de verdad.

Fase 3. Mapeo de objetos y propiedades

Campo a campo, del origen al destino, con las reglas de transformación escritas: formatos de fecha, normalización de países y monedas, valores permitidos en las listas desplegables, y qué hacer con los campos que no tienen equivalente. Criterio para pasar: existe un diccionario de datos que un tercero podría ejecutar sin preguntar nada.

Fase 4. Migración de prueba en un entorno separado

Se migra un subconjunto representativo —no una muestra fácil— y se valida con las personas que usan esos datos a diario, no solo con el equipo de proyecto. Criterio para pasar: los usuarios finales confirman que sus registros y sus vistas son utilizables, y los conteos cuadran objeto por objeto.

Fase 5. Cutover

La ventana de cambio, con congelación de escrituras en el origen, migración final, verificación y apertura del nuevo sistema. Necesita un plan escrito con horas, responsables y —lo que más se olvida— un criterio de reversión definido antes de empezar. Criterio para pasar: la verificación post-carga cuadra y el equipo puede trabajar.

Fase 6. Estabilización

Las semanas siguientes al cutover, cuando aparecen los casos que ninguna prueba cubrió. Es una fase real con presupuesto y personas asignadas, no un periodo de buena voluntad. Criterio de cierre: las incidencias abiertas bajan a un nivel estable y el sistema antiguo puede pasar a solo lectura.

Dos profesionales de TI latinoamericanos trabajando juntos frente a dos monitores durante una tarea técnica de migración de datos
El mapeo campo a campo es donde se decide si la migración será limpia o si arrastrará el desorden del sistema anterior.

Migración de datos: qué se migra y qué no

Esta es la sección que evita la mayoría de las discusiones incómodas a mitad de proyecto. Conviene separar lo que HubSpot documenta oficialmente de lo que es práctica del sector.

Elemento Se migra Qué tener en cuenta
Contactos, empresas, negocios, ticketsVía importación, API o integración; el orden importa (empresas antes que contactos)
Asociaciones entre registrosRequieren identificadores consistentes; es la parte que más falla si el origen está sucio
Archivos adjuntosSí, en transferencia puntualHubSpot lo documenta como parte de la transferencia única; bibliotecas grandes añaden tiempo y almacenamiento
Historial de actividades (llamadas, correos, notas)Parcial y con esfuerzoNo figura como elemento estándar de la transferencia; suele requerir trabajo a medida. Decide cuánto histórico necesitas de verdad
Automatizaciones y flujos del sistema de origenNoSe reconstruyen. Presupuéstalo como desarrollo, no como migración
Campos calculadosNo como fórmulaSe migra el valor o se recrea el cálculo en HubSpot; hay que decidir cuál de las dos cosas
Permisos y jerarquías de usuariosNoSe rediseñan según el modelo de equipos y permisos de HubSpot
Informes y paneles históricosNoSe reconstruyen. Captura capturas o exportaciones de los informes clave antes del cutover

Límites documentados que afectan al plan

HubSpot publica límites técnicos que conviene comprobar antes de diseñar el modelo, porque algunos dependen del nivel de suscripción contratado. Para la herramienta de importación, la documentación oficial establece que los archivos deben tener menos de 1.000 columnas y estar codificados en UTF-8 si contienen caracteres no ingleses, con un máximo de 1.048.576 filas por archivo. Los límites de tamaño y de volumen diario dependen del plan: con las herramientas gratuitas, archivos de hasta 20 MB y 500.000 filas al día; con suscripciones de pago, hasta 512 MB por archivo y un volumen diario muy superior.

Los límites de propiedades personalizadas y de objetos personalizados varían según el nivel de suscripción y HubSpot los publica en su catálogo de producto y servicios. Compruébalos contra tu plan concreto antes de cerrar el modelo de datos: descubrir un techo a mitad de la fase de mapeo obliga a rediseñar.

Cómo decidir qué histórico migrar

Tres preguntas por cada conjunto de datos históricos: ¿alguien lo consulta más de una vez al trimestre?, ¿lo necesitamos para una obligación legal o fiscal?, ¿aparece en algún informe que la dirección mira? Si las tres respuestas son no, ese dato se archiva fuera del CRM y no se migra. Migrar todo «por si acaso» es la decisión que más encarece un proyecto y más ensucia el sistema nuevo.

Riesgos y cómo mitigarlos

Equipo de proyecto latinoamericano reunido al final del día durante una ventana de cambio, revisando una lista impresa y coordinando por teléfono

Cada riesgo con su señal temprana y su acción preventiva.

  • Pérdida o corrupción de datos. Señal temprana: los conteos por objeto no cuadran entre origen y destino en la migración de prueba. Prevención: conciliación por conteos y por muestreo en cada carga, y una exportación completa del origen conservada intacta antes de tocar nada.
  • Duplicados. Señal temprana: el origen no tiene una clave única fiable y se está usando el correo electrónico como identificador. Prevención: deduplicar en el origen, antes de migrar; nunca después.
  • Ruptura de integraciones y de atribución. Señal temprana: nadie tiene la lista completa de sistemas conectados al CRM actual. Prevención: inventariar cada integración con su dueño y probarla en el entorno de prueba; asumir que la atribución histórica no cruza la migración intacta.
  • Interrupción de campañas activas. Señal temprana: hay campañas o secuencias en curso durante la ventana de cutover. Prevención: cerrar o pausar campañas antes de la congelación, y no lanzar nada nuevo hasta la verificación.
  • Caída de productividad comercial. Señal temprana: la formación está programada para el mismo día del go-live. Prevención: formar antes, con datos reales en el entorno de prueba, y reforzar en las dos semanas siguientes.
  • Rechazo del equipo. Señal temprana: reaparecen hojas de cálculo paralelas en la primera semana. Prevención: involucrar a los usuarios en la validación desde la fase de prueba, para que el sistema sea suyo antes de ser obligatorio.
  • Dependencia de un solo proveedor. Señal temprana: la documentación vive en la cabeza del consultor. Prevención: exigir documentación entregable y transferencia de conocimiento como criterio de aceptación, no como cortesía final.

El riesgo de calendario: cuándo no migrar

Migrar a mitad de trimestre o en cierre fiscal es una decisión que se paga dos veces. El equipo comercial está cerrando y no tiene margen para aprender un sistema nuevo; y si la migración altera cómo se cuentan las oportunidades, el cierre del periodo queda contaminado y no habrá forma limpia de comparar contra el histórico. La ventana buena es el inicio de un periodo, con la línea base ya capturada del sistema anterior.

La salida del sistema anterior: lo que se planifica tarde

Una migración tiene dos lados y casi todo el esfuerzo se dedica al de llegada. El de salida genera sorpresas caras, y casi todas son contractuales o de calendario más que técnicas.

  • Comprueba tus derechos de exportación antes de anunciar la salida. Qué objetos puedes exportar, en qué formato, con qué frecuencia y si el acceso sigue disponible una vez notificada la baja. Algunos contratos restringen la exportación masiva o la limitan a la ventana de renovación.
  • No hagas coincidir el fin del contrato con el cutover. Deja solapamiento: necesitarás el sistema anterior en modo consulta durante la estabilización, cuando aparezcan los casos que ninguna prueba cubrió. Apagar el origen el mismo día del go-live elimina tu única red de seguridad.
  • Los enlaces de descarga caducan. Las exportaciones suelen entregarse como archivo temporal. Descarga y guarda cada exportación en almacenamiento propio en cuanto esté lista, y verifica que el archivo abre y contiene lo que dice contener.
  • Decide qué pasa con lo que no migras. Los datos que descartaste del CRM no desaparecen del mundo: define dónde se archivan, quién puede consultarlos y durante cuánto tiempo hay que conservarlos por obligación legal o fiscal en cada país donde operas.
  • Guarda evidencia de los informes clave. Exporta o captura los informes que la dirección revisa antes de apagar el origen. Reconstruirlos después, sin el sistema que los generaba, es casi imposible y es la petición que llega siempre en la primera revisión trimestral tras la migración.

Cronograma y equipo típico

Jefa de proyecto latinoamericana señalando un cronograma mural de barras de colores mientras un colega toma notas

No existe una cifra fiable de «cuánto tarda una migración», y desconfía de quien te dé una sin haber visto tus datos. Lo que sí se puede decir con precisión es qué mueve el calendario, ordenado por impacto:

  1. El número de integraciones y si alguna es a medida. Es el factor que más varianza introduce, muy por encima del volumen de registros.
  2. La calidad del origen. Una base sucia añade una fase entera de limpieza que rara vez está en el presupuesto inicial.
  3. El número de equipos y países que usan el sistema, porque cada uno añade decisiones de proceso y de permisos.
  4. La complejidad del modelo de datos, especialmente si hacen falta objetos personalizados.
  5. La velocidad de decisión del cliente. En la práctica, este es el factor que más veces alarga un proyecto: las fases 2 y 3 se bloquean esperando decisiones de negocio, no por trabajo técnico pendiente.

Por el lado del cliente hacen falta, como mínimo: un patrocinador ejecutivo que desbloquee decisiones, un dueño del proyecto con dedicación real, un administrador del CRM que herede el sistema, un referente por cada equipo que use la herramienta y alguien de TI para las integraciones. Por el lado del partner: dirección de proyecto, arquitectura de datos, configuración e integraciones, y habilitación. Cuando falta el dueño interno, el proyecto no se detiene: se degrada en silencio, porque las decisiones las acaba tomando el proveedor con criterio técnico y sin contexto de negocio.

Antes del go-live tiene que existir el modelo de datos, las integraciones críticas, los permisos y los informes que la dirección mira. Puede esperar todo lo demás: automatizaciones secundarias, personalizaciones de detalle y los informes que nadie ha pedido todavía.

Si estás decidiendo si la plataforma encaja antes de plantear la migración, empieza por qué es HubSpot y cuándo conviene; si necesitas dimensionar el presupuesto, la guía de cuánto cuesta HubSpot desglosa licencias e implementación; y si vas a elegir con quién hacerlo, revisa cómo evaluar una agencia partner de HubSpot y nuestra página de implementación e incorporación.

Preguntas frecuentes

¿Cuánto tarda una migración a HubSpot?

Depende de factores que se pueden nombrar con precisión aunque el plazo no se pueda prometer de antemano: el número de integraciones y si alguna es a medida, la calidad de los datos de origen, cuántos equipos y países usan el sistema, la complejidad del modelo de datos y la velocidad con la que el cliente toma decisiones de negocio. En proyectos enterprise el factor que más alarga el calendario suele ser el último, no el trabajo técnico. Cualquier estimación dada antes de auditar el sistema de origen es una conjetura.

¿Qué datos no se pueden migrar a HubSpot?

Los registros y sus asociaciones se migran, y HubSpot documenta que los archivos adjuntos pueden transferirse en una transferencia puntual. En cambio, las automatizaciones y flujos de trabajo del sistema anterior no se migran y hay que reconstruirlos; los campos calculados se migran como valor o se recrean como cálculo, pero no como fórmula; los permisos y jerarquías de usuarios se rediseñan según el modelo de HubSpot; y los informes y paneles históricos se vuelven a construir. El historial completo de actividades no figura como elemento estándar de la transferencia y suele requerir trabajo a medida.

¿Cuándo no conviene migrar a HubSpot?

No conviene migrar a mitad de trimestre ni durante un cierre fiscal: el equipo comercial no tiene margen para aprender y el cambio contamina la comparación con el histórico. Tampoco conviene cuando el proceso comercial no está definido, porque migrarás el desorden actual a una herramienta nueva; ni cuando no hay nadie dentro de la empresa con tiempo asignado para ser dueño del sistema. En esos casos, lo primero no es la migración sino resolver la condición que falta.

¿Qué hay que preparar antes de empezar una migración?

Cuatro cosas. Una exportación completa e intacta del sistema de origen, conservada como copia de seguridad. Un inventario de todos los sistemas integrados con el CRM, cada uno con su responsable. Una decisión escrita, campo por campo, sobre qué se conserva, qué se archiva y qué se descarta. Y la línea base de las métricas que vas a querer comparar después: si no la capturas antes del cutover, no habrá forma de demostrar si la migración mejoró algo.

¿Migración compleja, con integraciones y varios países?

Somos HubSpot Elite Partner. Antes de proponerte un plan queremos ver tus datos de origen: es la única forma honesta de estimar un calendario.

Agenda una llamada

Fuentes: HubSpot Knowledge Base, Understand HubSpot's CRM migration process · HubSpot Knowledge Base, Format import files · HubSpot Knowledge Base, Transfer data using HubSpot Smart Transfer · HubSpot Knowledge Base, Create and edit custom objects · HubSpot Legal, Product & Services Catalog — Technical Limits.