Una migración de Salesforce a HubSpot se juzga por lo que usted decide no copiar. Los registros, las automatizaciones y los informes se reparten en tres grupos: copiar, archivar o reconstruir. Los equipos que los clasifican a propósito terminan con un CRM en el que la gente confía; los que se saltan la clasificación trasladan su desorden en seis semanas.
No estoy en contra de la velocidad. Un partner de HubSpot anuncia una migración en seis semanas sin interrupción del negocio, y es una promesa razonable para la parte mecánica. El problema es que el plazo mide la parte fácil de medir.
Por qué el plazo de seis semanas mide lo equivocado
Un plazo le dice cuándo llegan los datos al sistema nuevo. No le dice nada sobre si esos datos significan lo mismo una vez allí. Una migración de Salesforce a HubSpot puede terminar a tiempo y aun así dejarle un año de informes rotos.
Las dos plataformas se basan en modelos de datos distintos. Salesforce permite acumular a lo largo de los años custom objects, tipos de registro y reglas de validación, y la documentación para desarrolladores de Salesforce muestra cuánto de esa estructura es configurable. HubSpot usa un modelo más plano de objetos, propiedades y asociaciones, descrito en la documentación para desarrolladores de HubSpot. Todo lo que dependía de una estructura propia de Salesforce debe traducirse o rediseñarse.
Un cliente con el que hablamos se enfrentaba a unos 1.300 registros duplicados y a transiciones de etapas del pipeline que nadie había probado, con la ventana de migración ya fijada. La fecha estaba bien. El riesgo eran las preguntas sin responder.
La clasificación en la migración de Salesforce a HubSpot: copiar, archivar o reconstruir
Este es el marco que uso. Para cada objeto de datos, automatización e informe hacemos una sola pregunta: ¿el negocio sigue actuando en función de esto? Si la respuesta es sí y está limpio, se copia. Si tiene valor histórico pero nadie actúa en función de ello, se archiva. Si la gente actúa en función de ello pero su funcionamiento es un parche, se reconstruye.
| Activo | Decisión por defecto | Motivo |
|---|---|---|
| Cuentas, contactos y deals abiertos | Copiar tras deduplicar | Los representantes trabajan con ellos a diario |
| Deals perdidos y actividad antigua | Archivar | Útiles para el análisis, ruido en el CRM activo |
| Etapas de lifecycle y etapas de deal | Reconstruir | Las etapas antiguas codifican hábitos antiguos |
| Automatizaciones tipo workflow | Reconstruir | La mayoría eran parches sobre parches |
| Atribución de fuente y de campaña | Copiar con cuidado | Recrear las marcas de tiempo es costoso |
Para bien o para mal, la columna de reconstrucción es donde se va el tiempo. También es donde está el valor.
Datos: deduplique antes de mover y archive en lugar de copiarlo todo
El duplicado más barato de corregir es el que se corrige antes de importar. Otro cliente nos contó que su base de datos de Salesforce era difícil de limpiar a su escala porque no tenían ni el personal ni los créditos de enrichment necesarios. Moverla sin cambios habría convertido un problema de datos en un problema de HubSpot, con precios por contacto además.
Por eso propongo una regla práctica. Si un registro no ha tenido actividad ni asociaciones abiertas en una ventana que tenga sentido para su ciclo de ventas, archívelo fuera del CRM. Podrá recuperarlo si surge un uso. Lo que no se puede hacer con facilidad es descontaminar un portal activo una vez que los representantes han creado hábitos sobre él.
La atribución es la excepción. Los datos de fuente y las marcas de tiempo del primer contacto son muy difíciles de reconstruir a posteriori, y los campos mal tratados suelen aflorar más tarde como tráfico clasificado como directo, un patrón que describimos en cómo las referencias de IA terminan como tráfico directo en HubSpot.
Automatizaciones y lógica de facturación: reconstruya a partir del resultado
Copiar una automatización de Salesforce en HubSpot copia también sus rarezas. El calendario de facturación de un cliente es un buen ejemplo: las ventas cerradas el día 15 se facturaban la mitad en ese momento y la otra mitad el primer día del mes siguiente, y Salesforce lo resolvía de forma torpe. Lo correcto no es recrear ese parche torpe. Es decidir cuál debe ser el resultado financiero y construir después el camino más corto hacia él en el sistema nuevo.
Mi impresión es que cerca de un tercio de las automatizaciones antiguas de una organización madura existen solo por una restricción del pasado. Esa cifra es una estimación propia de trabajo basada en proyectos, no un estudio. Cuando liste las automatizaciones, escriba el resultado junto a cada una. Toda automatización sin un resultado vigente es candidata a retirarse.
Informes: reconstruya a partir de las preguntas que hace la dirección
Un informe migrado sin cambios es un informe construido sobre una definición antigua de etapa, de fuente o de lead "calificado". Parta de las cinco o seis preguntas que su dirección hace cada semana y reconstruya primero esas sobre el nuevo modelo de datos. Luego compárelas con las cifras antiguas y documente cada diferencia que pueda explicar.
Esa comparación importa más que el dashboard en sí. Si la cifra del nuevo pipeline es un 8% menor que la anterior, conviene saber si la causa es la deduplicación, un cambio en la definición de una etapa o un error. Sin ese análisis, la primera reunión de forecast tras la puesta en marcha se convierte en una discusión sobre la herramienta.
Lo que realmente cuesta una migración de Salesforce a HubSpot más allá de las licencias
Los resultados de búsqueda que veo sobre este tema suelen detenerse en plazos y mapeo de campos. Dejan fuera el costo total. Este es un ejemplo con mis supuestos, no un benchmark: un equipo de 12 representantes pierde dos horas por semana cada uno durante seis semanas mientras reaprende el sistema y corrige registros. Son unas 144 horas, antes de contar el tiempo de consultores o el retrabajo de integraciones. Si suma una reconstrucción de informes que nadie definió en el scope, la factura de lo que no se transfirió supera la factura de la migración.
La adopción en los primeros 90 días sigue la misma lógica. Los representantes usan el CRM nuevo cuando las etapas reflejan cómo venden y los datos del registro son algo en lo que pueden confiar. Eso es un resultado de la reconstrucción, no de la capacitación.
Cuándo quedarse en Salesforce
No tengo una regla clara para esto. Las jerarquías de territorios complejas, los modelos de permisos profundos y los objetos muy personalizados son lugares donde HubSpot puede no igualar lo que usted tiene. A veces la recomendación honesta es quedarse o migrar por fases. Si un partner nunca dice eso, pregúntele por qué.
La lista de verificación de casos de éxito para una migración de Salesforce a HubSpot cubre qué pruebas exigir antes de firmar, y nuestra matriz de evaluación de partners de implementación de HubSpot explica cómo evaluar a quienes hacen el trabajo. Si ya migró y el portal no funciona como debería, la siguiente lectura es cómo distinguir un portal roto de un presupuesto de reconstrucción. Para ver cómo ejecutamos estos proyectos, consulte nuestro servicio de migración de Salesforce a HubSpot y la práctica de revenue operations.
Mi recomendación: en cualquier migración de Salesforce a HubSpot, trate las seis semanas como la parte fácil y dedique su atención a la clasificación.