La mayoría de las migraciones de Salesforce a HubSpot se definen como un ejercicio de mapeo. Alguien exporta la lista de campos de Salesforce, la pega junto a la lista de propiedades de HubSpot, traza líneas entre ambas y reserva una ventana de importación. Eso no es una migración; es la traducción de la deuda técnica existente a un nuevo dialecto. El trabajo real de pasar de Salesforce a HubSpot es un triaje a nivel de campo: decidir, fila por fila, si un campo recibe un lugar en HubSpot, se transforma antes o no sobrevive al cutover. La hoja de mapeo es el resultado de esa decisión. No es la decisión en sí.
Por qué importa ahora
Las instancias de Salesforce en etapa Series B o posterior acumulan cientos de campos personalizados, y la cantidad de campos es la parte menor del problema. La parte mayor es que menos de la mitad de los datos estructurados de esos campos se usa activamente en alguna decisión, un hallazgo documentado en el trabajo sobre estrategia de datos de Harvard Business Review que ha envejecido bien en los años posteriores. Trasladar campo por campo a HubSpot lleva consigo la mitad sin uso junto con la útil, y el equipo arrastra ese lastre a la nueva plataforma. La ventana de migración es el único momento del lifecycle del CRM en el que eliminar un campo es barato. Si se omite, la siguiente persona que toque el esquema lidiará con la herencia en lugar de construir hacia adelante.
La hoja de triaje, no el documento de mapeo
El artefacto que impulsa una migración de Salesforce a HubSpot es una hoja de cálculo con una fila por cada campo de Salesforce y tres columnas de decisión: keep, edit, delete. Es el mismo marco keep / edit / delete que rige la auditoría brownfield más amplia de una instancia heredada, pero aplicado a un objetivo más acotado: el campo, no el workflow ni el informe. La versión a nivel de instancia de este mismo marco está en nuestro artículo complementario sobre cómo heredar una instancia de HubSpot o Salesforce. Para cada campo, la fila registra el nombre de API de Salesforce, el tipo de campo, la tasa de completitud sobre los registros modificados en los últimos noventa días, la propiedad propuesta en HubSpot, la transformación y el responsable con nombre que firma la fila.
Una instancia de Salesforce típica en etapa intermedia termina el triaje con aproximadamente un tercio de campos eliminados, un cuarto editados y el resto conservados sin cambios. Las cifras importan menos que la disciplina: cada campo es una decisión, y cada decisión lleva un nombre al lado.
Tipos de campo de Salesforce vs. tipos de propiedad de HubSpot
Los dos sistemas no comparten un sistema de tipos, y en esas diferencias se cometen la mayoría de los errores de migración a nivel de campo. Las categorías que realmente importan:
Picklists vs. desplegable / radio / casilla de verificación
Los picklists de selección múltiple de Salesforce no tienen un equivalente limpio en HubSpot. Las propiedades de casillas múltiples de HubSpot cubren el caso estructural, pero los valores de picklist específicos por tipo de registro en Salesforce a menudo se expanden en propiedades separadas en HubSpot cuando los valores no comparten realmente la misma semántica. El momento de la migración es el momento de consolidar. Los picklists con más de veinte valores, la mitad de los cuales no se ha seleccionado en los últimos seis meses, se editan hasta quedar con los valores que aparecen en registros reales.
Campos de fórmula
Los campos de fórmula de Salesforce no se migran. Se desarman en una de tres opciones en HubSpot: una propiedad de cálculo si la fórmula es una función pura de otras propiedades del mismo registro, un workflow que escribe en una propiedad normal a partir de un disparador, o una eliminación si la lógica subyacente ya no se necesita. El criterio de diagnóstico es si la fórmula lee de campos que a su vez son keep, edit o delete. Un campo de fórmula cuyos insumos van todos a delete es un delete por transitividad.
Relaciones lookup y master-detail
Los lookups de Salesforce se traducen a asociaciones de HubSpot, pero la traducción no es 1:1. Las etiquetas de asociación de HubSpot llevan semántica («firmante principal» vs. «comprador económico» vs. «champion») que Salesforce suele codificar como un campo lookup personalizado con un picklist de roles aparte. La migración limpia consolida el patrón lookup más rol en una única asociación etiquetada, que es más corta de mantener y menos frágil para reportar. Las relaciones master-detail plantean otra pregunta: si el objeto hijo debe ser un custom object de HubSpot o si los registros pertenecen a otro objeto estándar con el padre como asociación.
Campos de propietario, cola y reglas de uso compartido
Las reglas de uso compartido y la propiedad por colas de Salesforce suelen esconder lógica de visibilidad dentro de campos que parecen inocuos. «Account Region», «Deal Pod» y «Owner Role» con frecuencia existen no para reportar, sino para accionar una regla de uso compartido tres capas más abajo. Antes de eliminar cualquiera de ellos, rastree el radio de impacto de la regla de uso compartido. El modelo de permisos de HubSpot es más superficial y más declarativo; algunos de estos campos se disuelven en la pertenencia a equipos y en reglas de partición del nuevo sistema, pero solo después de mapear la dependencia.
La cuestión de los datos históricos
Toda migración de Salesforce a HubSpot se topa con la pregunta de cuánto historial trasladar. La respuesta honesta rara vez es «todo». El criterio por defecto que mantenemos es: los últimos noventa días de historial de actividad, el lifecycle completo de cualquier oportunidad abierta sin importar su antigüedad y el registro de closed-won de cualquier deal que siga en ciclo de renovación. Todo lo demás queda en un archivo de solo lectura en Salesforce que el equipo puede consultar pero no editar. La razón para trazar la línea con firmeza es que los datos de actividad histórica son lo que más tiempo suma a la migración y lo que menos aporta a las decisiones a futuro. Un equipo que importa cinco años de tareas de actividad de antiguos representantes obtiene una instancia de HubSpot más lenta y aproximadamente la misma precisión de forecast.
Un patrón visto en campo
Un equipo B2B SaaS de EMEA, en etapa Series B, llegó a nosotros a mitad de la migración con una instancia de Salesforce que tenía poco más de seiscientos campos personalizados entre los objetos Account, Contact y Opportunity. El scope original era un mapeo de campos 1:1: cada campo de Salesforce recibe una propiedad en HubSpot, se ejecuta la importación, el equipo se reentrena. La primera pasada de triaje marcó para eliminación directa aproximadamente el treinta y cinco por ciento de los campos, la mayoría campos personalizados completados en unos pocos cientos de registros años atrás para una campaña que nadie del equipo actual recordaba. Otro veinticinco por ciento eran ediciones: consolidaciones de picklists, desarmes de fórmulas, traducciones de lookup a asociación y un puñado de campos de fecha que debían aterrizar en el manejo de zonas horarias más estricto de HubSpot. El cuarenta por ciento restante se conservó sin cambios. El portal de HubSpot salió a producción con alrededor de doscientas cuarenta propiedades personalizadas, una superficie que el equipo podía mantener realmente, y el primer trimestre de forecast sobre él fue el primero en dos años que no necesitó una revisión manual de integridad de datos antes de la reunión.
Resolución: el playbook de triaje
Para cualquier equipo que esté por ejecutar una migración de Salesforce a HubSpot:
- Obtenga el inventario de campos antes de trazar cualquier línea de mapeo. Una fila por cada campo personalizado de Salesforce en cada objeto estándar y personalizado. Incluya nombre de API, tipo de campo, tasa de completitud en registros modificados en los últimos noventa días y los metadatos dependientes: reglas de workflow, reglas de validación, referencias de fórmulas, reglas de uso compartido.
- Ejecute la pasada keep / edit / delete. Cada fila recibe una decisión y un responsable con nombre. Los campos con completitud inferior al diez por ciento en registros recientes pasan a delete por defecto, a menos que alguien los defienda por escrito.
- Consolide los picklists antes de mapear. Edite los valores del picklist hasta dejar lo que aparece en registros reales y luego mapee la lista consolidada a HubSpot. No importe valores muertos.
- Desarme los campos de fórmula en cálculos, workflows o eliminaciones. Ningún campo de fórmula se migra tal cual. Cada uno se reimplementa, se redirige o se descarta.
- Traduzca los lookups a etiquetas de asociación de HubSpot. Los patrones de lookup más rol se colapsan en asociaciones etiquetadas. Los custom objects solo justifican el traslado si el modelo de datos realmente los necesita del lado de HubSpot.
- Mapee el radio de impacto de las reglas de uso compartido antes de eliminar cualquier campo que cargue visibilidad. Los campos de propietario, región, pod y rol que accionan reglas de uso compartido de Salesforce no pueden simplemente desaparecer; se traducen en equipos de HubSpot, reglas de partición o permisos basados en roles, y la traducción se documenta campo por campo.
- Firme la hoja antes de ejecutar la importación. La hoja de triaje es el artefacto del cutover. La importación a HubSpot es una función de esa hoja, no un ejercicio paralelo. Si un campo no está firmado, no se mueve.
Los pasos uno a siete son el ochenta por ciento del proyecto. La importación en sí es una tarde de viernes.
Dónde entra Checkpoint
El triaje a nivel de campo es el trabajo que determina si una migración de Salesforce a HubSpot sale limpia o sale con la misma instancia bajo un logo nuevo. Hacemos este ejercicio en cada migración de CRM en la que participamos, y es la columna vertebral de cómo abordamos las implementaciones de HubSpot posteriores a un sistema heredado. Si el triaje es el proyecto, el modelo operativo que usa la instancia resultante es lo que lo hace duradero, y eso es el trabajo de revenue operations que viene después. Si está definiendo una migración de Salesforce a HubSpot y la conversación parte de una hoja de mapeo, hable con nosotros antes de reservar la ventana de importación.
Fuentes
- «What's Your Data Strategy?» Harvard Business Review, May–June 2017. hbr.org
- Lemkin, Jason. «Which CRM Should You Use in 2026/2027? Follow the Agents.» SaaStr, April 2026. saastr.com