Migración a HubSpot: Guía completa paso a paso

Una migración profesional debe preservar la información importante, reconstruir correctamente los procesos, evitar interrupciones operativas y conseguir que HubSpot se convierta en una fuente de información fiable para la organización. 

Migrar a HubSpot no consiste solamente en exportar contactos desde un sistema, limpiar un archivo e importarlo en otro.

Una migración completa puede afectar datos, procesos comerciales, automatizaciones, integraciones, permisos, reporting, consentimiento, marketing, soporte al cliente y operaciones internas. También puede modificar la forma en la que los equipos trabajan, colaboran y toman decisiones.

Por eso, una migración a HubSpot debe tratarse como un proyecto de transformación empresarial y no como una simple carga de datos.

En esta guía explicamos cómo planificar, ejecutar y validar una migración a HubSpot, qué riesgos deben controlarse, qué herramientas pueden utilizarse y qué edición de HubSpot puede ser necesaria en cada escenario.

¿Estás evaluando una migración a HubSpot? 

Solicita una evaluación inicial de tu CRM, datos e integraciones.

1. ¿Qué es realmente una migración a HubSpot?

Una migración a HubSpot es el proceso de trasladar y adaptar información, relaciones, procesos y capacidades desde uno o varios sistemas hacia la plataforma HubSpot.

El sistema de origen puede ser:

• Otro CRM, como Salesforce, Microsoft Dynamics, Zoho o Pipedrive

• Una plataforma de marketing automation

• Una herramienta de atención al cliente

• Un ERP

• Un sistema interno

• Varias hojas de cálculo

• Una combinación de todas las anteriores

Los datos del sistema anterior no siempre deberían copiarse de forma idéntica. El modelo de HubSpot, sus objetos, sus asociaciones y su lógica de automatización pueden ser diferentes.

Una buena migración no pregunta únicamente:

“¿Cómo copiamos todo lo que existe?”

También pregunta:

“¿Qué información y procesos necesita realmente la organización en el nuevo sistema?”

2. ¿Cuándo conviene migrar a HubSpot?

Una migración suele tener sentido cuando la organización experimenta alguno de estos problemas:

• Los equipos trabajan en sistemas desconectados.

• Ventas no dispone de información fiable sobre marketing.

• Marketing no puede atribuir ingresos correctamente.

• Servicio al cliente no tiene visibilidad del historial comercial.

• Existen demasiados procesos manuales.

• El CRM actual tiene baja adopción.

• Mantener la plataforma anterior resulta costoso o complejo.

• El reporting requiere exportaciones y conciliaciones constantes.

• Se necesita una visión unificada del cliente.

• La empresa quiere simplificar su stack tecnológico.

Sin embargo, HubSpot no debería seleccionarse únicamente porque su interfaz sea más sencilla.

Antes de migrar debe realizarse un análisis fit-gap que confirme:

• Qué requisitos cubre HubSpot de forma estándar.

• Qué requisitos necesitan configuración.

• Qué requisitos necesitan una integración.

• Qué requisitos necesitan desarrollo.

• Qué requisitos no deberían trasladarse.

• Qué limitaciones deben aceptar los equipos.

3. ¿Qué se puede migrar a HubSpot?

Dependiendo del producto, la edición y la arquitectura elegida, una migración puede incluir:

• Contactos

• Empresas

• Leads

• Negocios

• Tickets

• Productos

• Line items

• Cotizaciones

• Facturas

• Suscripciones

• Pedidos

• Llamadas

• Emails registrados en el CRM

• Reuniones

• Notas

• Tareas

• Propietarios

• Pipelines

• Etapas

• Archivos

• Preferencias de comunicación

• Listas de exclusión

• Páginas web

• Landing pages

• Artículos de blog

• Base de conocimiento

• Formularios

• Integraciones

• Datos de objetos personalizados

HubSpot permite importar varios tipos de objetos y asociarlos durante una importación. Para determinados objetos también pueden utilizarse propiedades con valores únicos como identificadores durante la carga.

Pero que algo pueda importarse no significa necesariamente que pueda migrarse de forma completa o idéntica.

4. ¿Qué no se migra directamente y debe reconstruirse?

Algunos componentes suelen requerir reconstrucción o rediseño:

• Workflows

• Secuencias

• Lead scoring

• Automatizaciones de asignación

• Dashboards

• Reportes

• Forecasting

• Reglas de aprobación

• Integraciones

• Formularios

• Emails de marketing

• Plantillas

• Permisos

• Equipos

• Modelos de consentimiento

• SLAs

• Routing 

• Propiedades calculadas

• Objetos personalizados

• Reglas de validación

La migración es una oportunidad para eliminar procesos obsoletos. Recrear todos los procesos históricos sin cuestionarlos suele trasladar la deuda técnica al nuevo CRM.

5. Las 8 fases de una migración a HubSpot

5.1 Fase 1. Descubrimiento y definición del alcance

El primer paso es establecer qué se quiere conseguir con la migración.

Preguntas fundamentales

¿Qué problemas debe resolver HubSpot? 
¿Qué equipos utilizarán la plataforma? 
¿Qué sistemas se reemplazarán? 
¿Qué sistemas continuarán operando? 
¿Qué datos deben mantenerse? 
¿Cuántos años de histórico son necesarios? 
¿Qué regulaciones se aplican? 
¿Cuál será la fuente de verdad por objeto? 
¿Existe una fecha contractual para apagar el sistema anterior? 
¿Qué métricas determinarán el éxito?

Entregables

La fase debería producir:

• Documento de alcance

• Inventario inicial de sistemas

• Matriz de stakeholders

• RACI

• Lista de requisitos

• Fit-gap

• Matriz de productos y licencias

• Registro inicial de riesgos

• Criterios de éxito

• Estrategia de entornos

Consejo práctico

Evita un alcance ambiguo como:

“Migrar Salesforce a HubSpot.”

Sustitúyelo por algo verificable:

“Migrar contactos, cuentas, oportunidades, productos y actividades de los últimos cinco años; reconstruir 18 automatizaciones comerciales; conectar el ERP; reproducir 12 reportes críticos y retirar Salesforce después de 60 días de hypercare.”

5.2 Fase 2. Auditoría del sistema de origen

Antes de diseñar HubSpot hay que comprender qué existe realmente.

Inventario de datos

Para cada objeto deben documentarse:

• Número de registros

• Número de registros activos

• Campos

• Tipo de campo

• Valores posibles

• Porcentaje de valores vacíos

• Duplicados

• Formatos inconsistentes

• Relaciones

• Reglas de negocio

• Histórico necesario

• Datos sensibles

• Responsable del dato
  
  

Inventario de procesos

También deben revisarse:

• Automatizaciones

• Reglas de asignación

• Validaciones

• Aprobaciones

• Cálculos

• Notificaciones

• Integraciones

• Jobs programados

• Reportes

• Exportaciones manuales

• Procesos externos al CRM

Clasificación recomendada

Cada elemento debería etiquetarse como:

• Migrar

• Transformar

• Reconstruir

• Integrar

• Archivar

• Eliminar

• Pendiente de decisión

Esta clasificación evita intentar copiar elementos que no aportan valor.

5.3 Fase 3. Diseño del modelo de datos de destino

El modelo de datos debe diseñarse antes de empezar a importar.

HubSpot utiliza objetos, propiedades y asociaciones. Los contactos y empresas pueden deduplicarse automáticamente mediante email y dominio en determinados contextos, pero una migración empresarial debería incorporar identificadores externos controlados.

Objetos estándar

Antes de crear un objeto personalizado, debe evaluarse si la entidad puede representarse mediante un objeto estándar:

• Contacto

• Empresa

• Lead

• Negocio

• Ticket

• Producto

• Line item

• Cotización

• Factura

• Suscripción

• Pedido

• Actividad

Los objetos estándar suelen tener mejor compatibilidad con reporting, automatización e integraciones.

Objetos personalizados

Un objeto personalizado puede ser apropiado cuando existe una entidad empresarial independiente con:

• Identificador propio

• Ciclo de vida propio

• Relaciones con otros objetos

• Propiedades propias

• Necesidad de reporting

• Necesidad de automatización

Ejemplos:

• Contratos

• Proyectos

• Propiedades inmobiliarias

• Instalaciones

• Pólizas

• Activos

• Membresías

Los objetos personalizados requieren una edición Enterprise compatible. La disponibilidad concreta debe confirmarse en el catálogo de productos vigente del portal.

Propiedades

Para cada propiedad debe documentarse:

• Nombre visible

• Nombre interno

• Objeto

• Tipo

• Descripción

• Valores permitidos

• Regla de transformación

• Sistema propietario

• Obligatoria o no

• Sensibilidad

• Uso en workflows

• Uso en reporting

• Política de retención

Identificadores externos

Es recomendable crear identificadores como:

• legacy_contact_id 

• legacy_company_id 

• legacy_deal_id 

• erp_customer_id 

• external_contract_id 

• migration_batch_id 

• source_system 

Una propiedad con valor único permite identificar registros sin depender exclusivamente del email o del dominio. HubSpot admite propiedades personalizadas con valores únicos para determinados objetos y usos de importación. 

Asociaciones

No basta con migrar registros; hay que preservar sus relaciones.

Ejemplos:

• Contacto → empresa

• Contacto → múltiples empresas

• Empresa → negocio

• Negocio → contactos

• Ticket → contacto

• Ticket → empresa

• Negocio → line items

• Contrato → empresa

• Proyecto → contactos

• Parent company → child company

Las etiquetas de asociación permiten distinguir relaciones como “empresa empleadora”, “distribuidor”, “contacto de facturación” o “responsable técnico”. 

5.4 Fase 4. Limpieza, transformación y preparación de los datos

Una migración no debería utilizarse para copiar errores históricos.

Operaciones habituales

• Normalizar emails

• Normalizar dominios

• Estandarizar teléfonos

• Corregir codificaciones

• Convertir fechas

• Resolver zonas horarias

• Mapear propietarios

• Traducir valores de listas

• Normalizar países y regiones

• Eliminar registros de prueba

• Identificar registros huérfanos

• Corregir asociaciones

• Resolver duplicados

• Separar campos concatenados

• Concatenar campos fragmentados

• Validar monedas

• Clasificar consentimiento

• Excluir datos innecesarios
  
  

Diccionario de transformación
Cada campo debería disponer de una regla documentada.

5.5 Fase 5. Configuración de HubSpot

Antes de cargar los datos deben estar configurados los componentes necesarios:

• Usuarios

• Equipos

• Permisos

• Propiedades

• Objetos

• Pipelines

• Etapas

• Valores de listas

• Monedas

• Subscription types

• Asociación de objetos

• Configuración de privacidad

• Dominios

• Integraciones

• Workflows necesarios para el go-live

• Dashboards mínimos

• Vistas

• Record customization
  
  

Control de automatizaciones

Durante una migración, ciertos workflows pueden:

• Sobrescribir datos

• Crear tareas

• Enviar emails

• Cambiar propietarios

• Crear negocios

• Modificar etapas

• Marcar contactos como marketing

• Actualizar sistemas externos

Por eso, cada automatización debe clasificarse como:

• Activa durante la migración

• Desactivada

• Activa solo para registros nuevos

• Activada después de reconciliar

• Sustituida temporalmente por una regla manual

5.6 Fase 6. Pruebas y migraciones piloto

Nunca debería realizarse la primera carga completa directamente durante el cutover.

Prueba 1. Smoke test

Usar entre 10 y 30 registros representativos.

Debe incluir:

• Registros simples

• Registros con asociaciones múltiples

• Campos vacíos

• Caracteres especiales

• Valores límite

• Actividades

• Propietarios

• Duplicados

• Errores intencionales
  
  

Prueba 2. Piloto funcional

Migrar una muestra más amplia y pedir a usuarios reales que validen:

• Visualización

• Búsqueda

• Procesos

• Asociaciones

• Workflows

• Reportes

• Integraciones
  
  

Prueba 3. Ensayo completo

Ejecutar una migración con volumen y secuencia similares a producción.
Debe medirse:

• Duración

• Errores

• Rendimiento

• Capacidad de reejecución

• Reconciliación

• Impacto de automatizaciones

• Comportamiento de integraciones
  
  

Prueba 4. Delta

Probar cómo se cargarán los cambios producidos entre la extracción inicial y el corte definitivo.

Prueba 5. Rollback

El equipo debe demostrar que puede revertir o compensar la migración, no asumir que podrá hacerlo.

5.7 Fase 7. Cutover y migración definitiva

El cutover es la transición operativa hacia HubSpot.

Decisiones necesarias

• Fecha y hora

• Ventana de congelación

• Último momento permitido para modificar el CRM anterior

• Responsable de go/no-go

• Orden de importación

• Momento de activar integraciones

• Momento de activar automatizaciones

• Comunicación a usuarios

• Procedimiento de incidencias

• Criterios de rollback
  
  

Orden habitual de carga

Un orden frecuente puede ser:

1. Usuarios y propietarios

2. Empresas

3. Contactos

4. Leads

5. Productos

6. Negocios

7. Line items

8. Tickets

9. Objetos personalizados

10. Asociaciones

11. Actividades

12. Preferencias y exclusiones

13. Archivos

14. Datos delta

* El orden exacto depende de las dependencias del modelo.

5.8 Fase 8. Hypercare, adopción y decomisionado

El proyecto no termina el día del go-live.

Hypercare
Durante las primeras semanas deben revisarse:

• Errores de integración

• Registros duplicados

• Datos sin propietario

• Workflows inesperados

• Fallos de permisos

• Diferencias de reporting

• Problemas de adopción

• Deliverability

• Marketing contacts

• Incidencias de usuarios
  
  

Adopción

Los indicadores pueden incluir:

• Usuarios activos

• Registros actualizados

• Actividades registradas

• Negocios sin siguiente actividad

• Propiedades obligatorias incompletas

• Uso de pipelines

• Cumplimiento del proceso

• Creación de reportes paralelos

• Exportaciones manuales
  
  

Decomisionado
Antes de apagar el sistema anterior debe confirmarse:

• Aceptación formal

• Retención legal

• Archivo final

• Acceso de solo lectura

• Cancelación de integraciones

• Rotación o eliminación de credenciales

• Exportación final

• Borrado según contrato

• Evidencia de auditoría

• Cancelación de licencias

Revisa la checklist de migración a HubSpot

Revisa los diferentes controles de datos, integraciones, pruebas, cutover y adopción:

Ver checklist

Cómo diseñar el modelo de datos en HubSpot

6. Qué datos migrar por cada Hub de HubSpot

6.1 Smart CRM y Sales Hub

Los elementos habituales son:

• Contactos

• Empresas

• Leads

• Negocios

• Propietarios

• Pipelines

• Etapas

• Productos

• Line items

• Actividades

• Notas

• Tareas

• Forecast categories

• Propiedades comerciales

Preguntas críticas
¿Qué representa un lead? 
¿Cuándo se crea un negocio? 
¿Cómo se calcula el importe? 
¿Quién es propietario del registro? 
¿Qué fecha representa el cierre? 
¿Qué ocurre con oportunidades perdidas? 
¿Cómo se gestionan varias unidades de negocio? 
¿Cómo se relacionan distribuidores, clientes y partners?

6.2 Marketing Hub

Una migración de marketing puede incluir:

• Contactos

• Marketing contact status

• Subscription types

• Exclusiones

• Formularios

• Landing pages

• Emails

• Listas o segmentos

• Workflows

• Lead scoring

• Campañas

• Eventos

• Preferencias

• Tracking

• Audiencias

• Histórico de interacción disponible

Los contactos importados sin especificar otro estado se establecen como non-marketing por defecto. Sin embargo, formularios, integraciones y workflows pueden utilizar configuraciones diferentes, por lo que debe existir una política explícita de marketing contacts.

6.3 Service Hub

Puede ser necesario migrar:

• Tickets

• Pipelines

• Estados

• Prioridades

• Agentes

• Equipos

• Categorías

• Conversaciones

• Notas

• Archivos

• Encuestas

• SLA

• Base de conocimiento

• Feedback

• Historial de soporte

Una decisión importante es si los tickets cerrados se migrarán como registros operativos o se conservarán en un archivo histórico.

6.4 Content Hub

El alcance puede incluir:

• Páginas

• Landing pages

• Blog

• Autores

• Etiquetas

• Imágenes

• Archivos

• Themes

• Templates

• Modules

• Redirecciones

• SEO metadata

• Contenido privado

• Contenido multidioma

• Dominios

• Formularios

La migración web debe incorporar un plan de:

• URLs

• Redirects 301

• Canonicals

• Sitemap

• Robots.txt

• Metadata

• Structured data

• Analytics

• Tracking

• Rendimiento

• Accesibilidad

6.5 Data Hub

Data Hub puede intervenir cuando se necesitan:

• Sincronizaciones

• Calidad de datos

• Automatización de datos

• Transformaciones

• Datasets

• Integración de fuentes

• Gestión avanzada de propiedades

No debe asumirse que Data Hub elimina la necesidad de diseñar integraciones.

La fuente de verdad, las reglas de conflicto y la observabilidad siguen siendo necesarias.

6.6 Commerce Hub

El alcance puede incluir:

• Productos

• Line items

• Cotizaciones

• Facturas

• Pagos

• Suscripciones

• Pedidos

• Descuentos

• Impuestos

• Frecuencias de facturación

• Condiciones de pago

Las herramientas actuales de cotización y CPQ deben evaluarse dentro de Commerce Hub. El diseño también debe aclarar qué información pertenece a HubSpot y qué información continúa siendo propiedad del ERP o sistema financiero.

7. ¿Cómo migrar actividades y datos históricos?

Las actividades suelen ser uno de los elementos más difíciles.

Pueden incluir:

• Emails

• Llamadas

• Reuniones

• Notas

• Tareas

• Comunicaciones

• Eventos
  
  

Preguntas que deben responderse

¿Cuánto histórico es necesario? 
¿Qué actividades tienen valor operativo? 
¿Qué actividades solo tienen valor legal? 
¿Se dispone del contenido o solamente de metadatos? 
¿Pueden conservarse autor y timestamp? 
 ¿Existen archivos adjuntos? 
 ¿Cómo se asociarán a contactos, empresas, negocios o tickets? 
¿Puede el canal representarse correctamente en HubSpot?

Estrategia por capas

Una buena práctica es dividir el histórico:

Capa operativa: Información reciente y necesaria para el trabajo diario.

Capa analítica: Datos necesarios para reporting y tendencias.

Capa de archivo: Información que debe conservarse, pero no necesariamente cargarse en el CRM.

No todo el histórico necesita estar disponible como actividad nativa en HubSpot. En algunos casos puede mantenerse un archivo consultable o un resumen consolidado.

8. Consentimiento, privacidad y preferencias de comunicación

El consentimiento no debe tratarse como un campo booleano.

Hay que distinguir entre:

• Permiso para almacenar y procesar dato

• Base legal

• Consentimiento para comunicarse

• Tipo de suscripción

• Canal

• Fuente

• Fecha

• Texto aceptado

• Evidencia

• Revocación

• Exclusión global

• Hard bounce

• Spam complaint

• Do-not-call

HubSpot permite gestionar tipos de suscripción y registrar preferencias. También permite importar listas de contactos que se han dado de baja.

Importante: un marketing contact no es necesariamente un contacto con consentimiento para recibir todas las comunicaciones.

La migración debería ser revisada por el responsable legal o de privacidad de la organización. Una guía técnica no sustituye asesoría jurídica.

9. Cómo evitar duplicados

HubSpot utiliza email y dominio para determinados procesos automáticos de deduplicación de contactos y empresas. Sin embargo, esas reglas no resuelven todos los escenarios.

Casos problemáticos

• Contactos sin email

• Contactos con varios emails

• Emails compartidos

• Empresas con varios dominios

• Franquicias

• Grupos empresariales

• Registros creados por distintas filiales

• Dominios genéricos

• Duplicados existentes en el origen

• Identificadores reutilizados

Estrategia recomendada

1. Definir una clave maestra

2. Crear IDs externos

3. Deduplicar antes de importar

4. Registrar reglas de supervivencia

5. Revisar asociaciones

6. Evitar que integraciones recreen duplicados

7. Monitorizar duplicados después del go-live.
   
   

10. Estrategias para ejecutar la carga

10.1 Importador de HubSpot

Adecuado cuando:

• El volumen es manejable

• Las transformaciones ya están hechas

• La estructura es relativamente simple

• Se necesita una ejecución puntual

• El equipo quiere revisar visualmente el mapeo

HubSpot permite importaciones de objetos individuales y múltiples, con requisitos específicos de formato e identificación.

10.2 Imports API

Adecuada cuando:

• Hay grandes volúmenes

• Se necesita automatizar

• Se necesita repetir la carga

• Existen varios archivos

• Se quiere registrar import IDs y resultados

• Se requiere un pipeline técnico reproducible

La Imports API documenta actualmente hasta 80 millones de filas por día, con límites por archivo de 1.048.576 filas o 512 MB. Estos límites deben comprobarse de nuevo antes de ejecutar el proyecto.

10.3 APIs de objetos

Adecuadas cuando:

• Se necesita lógica registro por registro

• Se requieren actualizaciones continuas

• Hay transformaciones dinámicas

• La migración forma parte de una integración

• Se requiere control detallado sobre los errores
  
  

Debe implementarse:

• Gestión de rate limits

• Reintentos

• Backoff

• Logging

• Idempotencia

• Colas de errores

• Monitorización

• Control de versiones

HubSpot introdujo documentación versionada por fecha para sus APIs en 2026, por lo que toda integración nueva debería documentar la versión utilizada.

10.4 Data Sync e integraciones nativas

Adecuadas cuando:

• Existe un conector compatible

• La sincronización continuará después de la migración

• El modelo estándar cubre el caso

• Las reglas de conflicto son aceptables

10.5 iPaaS o middleware

Adecuado cuando:

• Intervienen varios sistemas

• Se necesitan transformaciones complejas

• Hay procesos de larga duración

• Se requiere observabilidad

• Deben gestionarse errores y reintentos

• Existen flujos bidireccionales

11. ¿Cómo migrar automatizaciones y procesos?

Los workflows no deberían copiarse uno a uno sin evaluación.

Para cada automatización debe documentarse:

• Objetivo

• Trigger

• Criterios de exclusión

• Acciones

• Dependencias

• Propiedades

• Integraciones

• Reinscripción

• Horarios

• Riesgo

• Owner

• Volumen esperado

• Método de prueba
  
  

Clasificación recomendada

• Retirar

• Simplificar

• Recrear

• Consolidar

• Reemplazar con funcionalidad estándar

• Implementar fuera de HubSpot

• Implementar mediante custom code
  
  

Error frecuente

Activar workflows antes de importar datos puede provocar acciones masivas no deseadas. Por ejemplo:

• Miles de tareas

• Reasignaciones

• Notificaciones

• Emails

• Actualizaciones de lifecycle stage

• Cambios de marketing status

• Llamadas a sistemas externos

12. ¿Cómo migrar integraciones?

Cada integración debe disponer de una ficha técnica.

Pregunta esencial

¿Qué ocurre cuando el mismo registro cambia en HubSpot y en el sistema externo?

Sin una respuesta clara, una sincronización bidireccional puede generar:

• Bucles

• Sobrescrituras

• Datos inconsistentes

• Duplicados

• Cambios de propietario

• Errores difíciles de rastrear

13. Cómo planificar la convivencia entre ambos sistemas

En migraciones complejas puede existir un período durante el cual ambos sistemas permanezcan activos.

Debe definirse una matriz de coexistencia:

Elementos necesarios

• Freeze

• Delta

• Watermark

• Deleted records

• Merge handling

• Timezone

• Conflictos

• Dual-write

• Reintentos

• Auditoría

14. Plan de pruebas y criterios de aceptación

La aceptación no debería basarse en “los datos parecen estar”.

Reconciliación cuantitativa

Comparar:

• Recuento total

• Recuento por estado

• Recuento por pipeline

• Recuento por propietario

• Recuento por país

• Recuento por mes

• Suma de importes

• Número de asociaciones

• Número de actividades

• Número de registros sin relación
  
  

Reconciliación cualitativa

Validar muestras de:

• Clientes importantes

• Negocios abiertos

• Tickets activos

• Registros complejos

• Empresas con múltiples contactos

• Negocios con productos

• Contactos con preferencias especiales

• Registros con actividades
  
  

Criterios de aceptación

Ejemplo:

• 100% de los negocios abiertos migrados

• 100% de los contactos con consentimiento preservado

• Menos de 0,2% de filas en excepción

• 100% de las integraciones críticas operativas

• Diferencia monetaria inferior al umbral acordado

• Ningún email de marketing enviado durante la carga

• Aprobación de los owners funcionales

15. Estrategia de rollback

Borrar los registros creados por una importación puede ser útil, pero no revierte automáticamente todo lo que ha ocurrido.

Una carga puede haber:

• Actualizado registros existentes

• Creado asociaciones

• Activado workflows

• Enviado notificaciones

• Creado tareas

• Actualizado sistemas externos

• Modificado estados de marketing

• Recalculado propiedades

HubSpot permite analizar importaciones anteriores y gestionar errores, pero esto no equivale a una transacción reversible completa.

Un rollback profesional requiere

• Snapshot previo

• IDs de registros creados

• IDs de registros actualizados

• Valores anteriores

• Relaciones anteriores

• Migration batch ID

• Logs

• Integraciones pausadas

• Scripts de compensación

• Criterios de activación

• Responsable autorizado

16. Runbook de cutover

Un runbook debería incluir tareas, responsables, horarios y criterios.

17. ¿Qué licencia de HubSpot se necesita?

El licenciamiento depende de la solución final, no solamente del mecanismo de migración.

HubSpot permite crear sandboxes y desplegar determinados tipos de configuraciones compatibles hacia producción, pero no todos los elementos se copian o despliegan automáticamente.

El Product & Services Catalog y la orden de compra del cliente deben considerarse la fuente contractual para confirmar funcionalidades, límites, seats y add-ons.

18. Errores frecuentes en una migración a HubSpot

1. Importar antes de diseñar

Crea propiedades duplicadas, asociaciones incorrectas y retrabajo.

2. Migrar todo

Los datos históricos sin uso aumentan complejidad y reducen confianza.

3. Confiar únicamente en email y dominio

No resuelve todos los casos de deduplicación ni relaciones empresariales.

4. Ignorar el consentimiento

Puede crear riesgo legal y de deliverability.

5. Activar automatizaciones demasiado pronto

Puede provocar acciones masivas.

6. No probar el delta

La migración inicial funciona, pero se pierden cambios del período de transición.

7. No reconciliar importes

Los recuentos coinciden, pero el pipeline financiero no.

8. No definir la fuente de verdad

HubSpot y los sistemas externos se sobrescriben.

9. No probar permisos

Los datos están correctos, pero los usuarios no pueden trabajar o ven información que no deberían.

10. Apagar demasiado pronto el sistema anterior

Impide consultar datos o resolver discrepancias durante el hypercare.

19. ¿Cuánto dura una migración a HubSpot?

No existe una duración universal. Una estimación depende de:

• Número de sistemas

• Objetos

• Volumen

• Calidad de los datos

• Asociaciones

• Actividades

• Integraciones

• Automatizaciones

• Reporting

• Compliance

• Disponibilidad de stakeholders

• Necesidad de desarrollo

• Número de ensayos

Aunque cada migración es diferente, estos rangos pueden servir como referencia inicial:

La duración real dependerá del número de sistemas implicados, la calidad de los datos, las integraciones, las automatizaciones y la disponibilidad de los equipos responsables.

20. ¿Cuánto cuesta una migración a HubSpot?

El coste debería calcularse considerando:

• Discovery

• Arquitectura

• Configuración

• Limpieza

• Desarrollo

• Integraciones

• Migración

• Pruebas

• Formación

• Project management

• Hypercare

• Licencias

• Herramientas intermedias

• Soporte posterior

Una propuesta basada solamente en “número de contactos” suele ignorar la mayor parte de la complejidad.

Una migración de 20.000 contactos con cinco sistemas, consentimiento y múltiples asociaciones puede ser más compleja que una migración de un millón de contactos simples.

Checklist definitiva de migración

21. Preguntas frecuentes

¿Se puede migrar todo a HubSpot?

No necesariamente. Muchos registros pueden importarse, pero las automatizaciones, integraciones, permisos, reportes y configuraciones normalmente deben reconstruirse o rediseñarse.

¿Se pueden conservar las fechas originales?

Las fechas de negocio pueden migrarse a propiedades específicas. Cuando una fecha técnica administrada por HubSpot no puede conservarse como valor nativo, debe almacenarse en una propiedad histórica como Legacy created date.

¿HubSpot elimina automáticamente todos los duplicados?

No. HubSpot dispone de mecanismos de deduplicación, pero una migración profesional necesita reglas adicionales, especialmente cuando existen contactos sin email, empresas con varios dominios o identificadores inconsistentes.

¿Es mejor importar con CSV o utilizar la API?

Depende del volumen y la complejidad. Los archivos pueden ser suficientes para cargas puntuales y controladas. La API es más apropiada cuando se necesita automatización, repetibilidad, transformaciones o integración continua.

¿Hay que migrar todas las actividades históricas?

No siempre. Deben migrarse las actividades con valor operativo, analítico o legal. El resto puede archivarse fuera del CRM.

¿Se pueden migrar workflows desde otro CRM?

Normalmente no de forma directa. Deben documentarse, racionalizarse y reconstruirse utilizando workflows, funcionalidad estándar, custom code o integraciones.

¿Cuándo puede apagarse el CRM anterior?

Después de completar la reconciliación, el hypercare, la aceptación formal y los requisitos de archivo o retención. Mantener temporalmente acceso de solo lectura suele reducir el riesgo.

22. Conclusión

Una migración a HubSpot exitosa no se mide únicamente por el número de registros importados.

Se mide por la capacidad de la organización para:

• Confiar en sus datos

• Ejecutar sus procesos

• Utilizar correctamente la plataforma

• Mantener integraciones estables

• Cumplir sus obligaciones de privacidad

• Obtener reporting fiable

• Retirar el sistema anterior sin interrumpir la operación

La tecnología es solamente una parte del proyecto. El diseño del modelo de datos, la gobernanza, las pruebas, la adopción y la gestión del cambio son igualmente importantes.

Una migración bien planificada permite aprovechar HubSpot como plataforma de crecimiento. Una migración improvisada puede trasladar al nuevo sistema los mismos problemas que ya existían en el anterior.

Diseña tu migración con un partner de HubSpot

Te ayudamos a definir el alcance, validar el modelo de datos y crear un plan de migración realista.
Habla  con nosotros