Mapear Campos Entre Sistemas Heredados y Nuevos

El mapeo de campos es la parte de una migración de CRM que parece simple hasta que no lo es. "First Name mapea a First Name" — claro. Pero ¿qué sucede cuando su sistema de origen tiene un solo campo de Nombre Completo y su destino requiere Nombre y Apellido por separado? ¿O cuando Lead Status en Salesforce tiene 8 valores y el destino soporta 5? ¿O cuando Annual Revenue se importa como campo de texto en lugar de campo de moneda, rompiendo todos los informes de ingresos el primer día?

Ese último escenario no es hipotético. Ocurre todo el tiempo. Y es prevenible — si construye el documento de mapeo de campos antes de la primera ejecución de importación, no durante ella.

Esta guía detalla el proceso completo de mapeo de campos: primero el mapeo a nivel de objeto, luego los campos estándar, luego los casos difíciles (campos personalizados, valores de lista de selección, campos de relaciones, discordancias de tipo). Trabaje estos pasos en orden antes de tocar el CRM de destino.

Paso 1: Mapeo a Nivel de Objeto Primero

Antes de mapear un solo campo, mapee los objetos. Cada CRM usa una terminología ligeramente diferente para los mismos conceptos, y el mapeo de objetos desalineado corrompe los datos de relaciones a escala.

Mapeo de Objetos Estándar

Sistema de origen	Objeto de origen	Concepto de destino	Notas
Salesforce	Lead	Contact (pre-conversión)	Los Leads de Salesforce se convierten en Contact + Account + Opportunity
Salesforce	Contact	Contact	Mapeo directo
Salesforce	Account	Company
Salesforce	Opportunity	Deal
Salesforce	Activity (Task/Event)	Activity
HubSpot	Contact	Contact	Mapeo directo
HubSpot	Company	Company	Mapeo directo
HubSpot	Deal	Deal	Mapeo directo
HubSpot	Ticket	Ticket / Support Case	Depende del destino
Pipedrive	Person	Contact
Pipedrive	Organization	Company
Pipedrive	Deal	Deal	Mapeo directo
Pipedrive	Activity	Activity
Zoho CRM	Lead	Contact (pre-conversión)	Similar al modelo de Lead de Salesforce
Zoho CRM	Contact	Contact
Zoho CRM	Account	Company

El problema de conversión de Lead en Salesforce: Salesforce tiene tanto Leads como Contacts. Los Leads son pre-conversión; los Contacts son post-conversión. La mayoría de los otros CRM tienen solo Contacts (con etapas del ciclo de vida). Antes de mapear cualquier cosa, decida: ¿está migrando los Leads de Salesforce como Contacts con una etapa del ciclo de vida "Lead", o solo está migrando Contacts convertidos? Esta decisión afecta miles de registros. Cambiar de Salesforce a Rework explica cómo se desarrolla esta conversión de Lead a Contact específicamente en el modelo de datos de Rework.

Cuando el modelo de objeto no coincide: Si su origen tiene un objeto personalizado sin equivalente en el destino, documéntelo explícitamente. No fuerce datos de objeto personalizado en un objeto estándar — crea confusión. Ya sea que lo migre como objeto personalizado en el destino, o decida que no vale la pena migrar.

Paso 2: Mapeo de Campos Estándar

Los campos estándar parecen sencillos. A menudo no lo son.

First Name / Last Name vs. Full Name: Salesforce almacena nombre y apellido por separado. Algunos sistemas almacenan un solo campo de "Nombre Completo". Si migra a un sistema que requiere nombres separados desde un origen que solo tiene Nombre Completo, necesitará una transformación de división — y es imperfecta (¿qué hace con "Dr. María José García-López"?).

Multiplicidad del campo de teléfono: Los Contacts de Salesforce tienen Phone, MobilePhone, OtherPhone, HomePhone, AssistantPhone — cinco campos de teléfono separados. La mayoría de los CRM tienen un teléfono primario y uno secundario. Decida antes de la importación qué campos de origen mapean a cuáles de destino. No descarte números de teléfono sin documentar esa decisión.

Multiplicidad del email: El mismo problema. Salesforce tiene Email y un email secundario vía métodos de contacto. HubSpot admite múltiples emails por contacto. Si el destino admite solo un email primario, necesita una regla sobre cuál gana.

Campo de sitio web: Los formatos de URL inconsistentes causan errores de validación. Algunos registros tienen "ejemplo.com", algunos tienen "https://www.ejemplo.com", algunos tienen "www.ejemplo.com/productos/pagina". Decida un formato objetivo y agréguelo como regla de transformación.

Paso 3: Inventario de Campos Personalizados

Aquí es donde la mayoría de las migraciones se atascan. Cada CRM maduro tiene docenas de campos personalizados acumulados durante años de procesos cambiantes. La mayoría no vale la pena migrar.

Exporte todos los campos personalizados de su origen:

Salesforce: Configuración > Object Manager > Seleccionar objeto > Fields & Relationships. Exporte como lista. La documentación de Salesforce Data Loader cubre cómo Data Loader exporta el esquema de campos junto con los datos de registro, útil para construir el inventario junto con su exportación.
HubSpot: Configuración > Propiedades. Filtre por "Creado por" = su equipo para ver las propiedades personalizadas. La documentación de importación de HubSpot lista qué propiedades son requeridas en la importación, útil para decidir qué campos de destino crear primero.
Pipedrive: Configuración > Campos de Datos. Los campos personalizados se listan por objeto.
Zoho CRM: Configuración > Personalización > Campos.

Para cada campo personalizado, aplique la prueba de tres preguntas. La guía de campos personalizados profundiza en convenciones de nomenclatura, opciones de tipo de campo y el proceso de gobernanza para la creación de campos personalizados en el destino, vale la pena leer antes de comenzar a construir campos en producción:

¿Reporta sobre él? Si no hay ningún informe que use este campo, probablemente no está aportando valor de negocio.
¿Segmenta por él? Si ningún workflow, secuencia o filtro de lista hace referencia a este campo, puede estar inactivo.
¿Automatiza desde él? Si ningún disparador de automatización usa este campo, considere si necesita migrar.

Si la respuesta a las tres es no, archívelo en el sistema de origen. No cree el campo en el destino.

Documente la decisión de mantener/omitir para cada campo personalizado. Cuando un representante de ventas pregunte en la semana tres por qué desapareció su campo "Tipo de Socio", querrá un registro escrito de por qué se tomó esa decisión, no un encogimiento de hombros.

Plantilla de Inventario de Campos Personalizados

Nombre del campo	Objeto	Tipo	Informes que lo usan	Uso en segmentación	Uso en automatización	Decisión	Notas
Partner Type	Contacto	Lista de selección	Sí (1 informe)	Sí (1 lista)	No	Migrar	Usado en informes de socios
Legacy Territory	Cuenta	Texto	No	No	No	Archivar	Reemplazado por nuevo modelo de territorio
MQL Score (manual)	Contacto	Número	No	No	No	Omitir	Reemplazado por puntuación automatizada
Referral Source Detail	Contacto	Texto	Sí (2 informes)	No	No	Migrar

Paso 4: Transformación de Valores de Lista de Selección

Los campos de lista de selección son el tipo de campo de mayor riesgo en cualquier migración. Parecen simples pero esconden complejidad — los valores de origen a menudo no coinciden con los valores de destino, y los valores no coincidentes se importan en blanco o generan un error.

El proceso:

Exporte todos los valores distintos para cada campo de lista de selección del origen
Exporte todos los valores permitidos para el campo coincidente en el destino
Construya un mapeo explícito de valor a valor
Decida qué hacer con los valores de origen que no tienen equivalente en el destino

Plantilla de Mapeo de Lista de Selección

Ejemplo: Lead Status / Lifecycle Stage

Valor de origen	Cantidad	Valor de destino	Manejo
New	1.450	Lead	Mapeo directo
Working	680	Lead	Mapear a Lead
Nurturing	320	Lead	Mapear a Lead
Marketing Qualified	290	MQL	Mapeo directo
Sales Accepted	175	SQL	Mapeo directo
Sales Qualified	210	SQL	Combinar con el anterior
Demo Scheduled	88	SQL	Mapear a SQL + agregar nota de actividad
Proposal Sent	62	SQL	Mapear a SQL
Customer	2.400	Customer	Mapeo directo
At Risk	155	Customer	Mapear a Customer, agregar etiqueta "en riesgo"
Churned	310	Customer	Mapear a Customer (inactive)
Dead	890	Disqualified	Mapear a Disqualified
Not Interested	430	Disqualified	Mapear a Disqualified

Qué hacer con valores que no tienen equivalente en el destino: No los deje en blanco. Mapéelos al valor de destino más cercano (con una nota en el documento de transformación) o cree un campo personalizado en el destino para preservar la distinción. Los valores en blanco en la etapa del ciclo de vida significan que esos registros no serán capturados por automatizaciones que filtren por etapa del ciclo de vida.

Paso 5: Mapeo de Campos de Relaciones

Las relaciones son la parte del mapeo de campos que falla con más frecuencia y es más difícil de corregir después del hecho.

Asociaciones Account → Contact (Salesforce): Cada Contact en Salesforce está vinculado a una Account vía el lookup AccountId. En la mayoría de los CRM de destino, esto se convierte en una asociación Contact → Company. La herramienta de importación necesita resolver esa relación — normalmente haciendo coincidir el nombre de la empresa del registro de Contact con un registro de Company existente.

El orden de operaciones importa: Importe las empresas primero, luego los contactos. Si importa Contacts antes de que existan Companies en el destino, la relación no puede establecerse.

Asociaciones Deal → Contact: Un Deal en Salesforce (Opportunity) tiene un Contact Principal y puede tener contactos adicionales vía el Opportunity Contact Role. Verifique si su CRM de destino admite múltiples asociaciones de contactos por deal, y decida qué contactos migrar.

Registros de múltiples relaciones: Algunos contactos están asociados con múltiples empresas (consultores, miembros de junta directiva). La mayoría de los CRM manejan esto de manera diferente a Salesforce. Documente cómo se importarán y pruebe específicamente un puñado de estos registros en su importación sombra.

Jerarquías de cuenta padre-hijo: Las Cuentas de Salesforce pueden tener Cuentas padre (para relaciones de subsidiarias). No todos los CRM de destino admiten esto de forma nativa. Sepa antes de mapear si las jerarquías padre-hijo sobrevivirán la migración.

Paso 6: Discordancias de Tipo de Campo

Las discordancias de tipo de campo son el problema de mapeo más peligroso porque a menudo se importan sin error — el tipo incorrecto simplemente corrompe silenciosamente los datos.

Tabla de Referencia de Conversión de Tipos

Tipo de origen	Tipo de destino	¿Seguro?	Transformación necesaria
Texto	Texto	Sí	Ninguna
Texto	Lista de selección	Arriesgado	Los valores deben coincidir con la lista; los no mapeados fallan
Lista de selección	Texto	Sí	Los valores se importan como están
Número	Texto	Sí	Ninguna
Texto	Número	Arriesgado	Cualquier carácter no numérico causa error de importación
Moneda	Número	Arriesgado	Eliminar símbolo de moneda y separadores de miles
Número	Moneda	Sí	Ninguna
Fecha	DateTime	Sí	Agregar T00:00:00Z
DateTime	Fecha	Sí	Eliminar componente de hora
Texto (con formato de fecha)	Fecha	Arriesgado	Debe convertir a ISO 8601 primero
Checkbox (Booleano)	Texto	Sí	True/False como cadenas
Texto	Checkbox	Arriesgado	Debe estandarizar a True/False exactamente
Lookup (ID)	Asociación	Arriesgado	Requiere lógica de resolución — la mayoría de las herramientas de importación no lo manejan automáticamente

El problema de Annual Revenue: Surge constantemente. Salesforce almacena Annual Revenue como campo de moneda. Algunos CRM de destino lo almacenan como un Número simple. Si importa una cadena de moneda con formato como "$1.250.000,00" en un campo Número, la importación fallará. Elimine el signo de dólar y las comas antes de importar: transforme $1.250.000,00 a 1250000. Para una visión más amplia de cómo difieren los modelos de datos de CRM entre plataformas, incluido el manejo de tipos de campo, Rework vs. HubSpot CRM es una referencia útil antes de finalizar las reglas de conversión de tipos.

Campos Checkbox: Los diferentes sistemas representan los valores booleanos de manera diferente. Salesforce exporta True/False. Algunos CRM importan 1/0. Algunos requieren "Sí"/"No". Sepa qué espera su herramienta de importación y transforme en consecuencia.

Paso 7: El Documento de Reglas de Transformación

Para cada campo que no sea un mapeo directo, anote explícitamente la regla de transformación. Este documento se convierte en su guía de importación — la persona que ejecuta la importación la sigue sin necesidad de tomar decisiones sobre la marcha.

Notación de Transformación

Use un formato consistente para todas las reglas de transformación:

SI [campo_origen] = "[valor_origen]"
ENTONCES [campo_destino] = "[valor_destino]"
SI NO [comportamiento_predeterminado]

Ejemplos:

SI lead_status = "Dead" O "Not Interested"
ENTONCES lifecycle_stage = "Disqualified"

SI annual_revenue = formato de texto "$N.NNN.NNN,NN"
ENTONCES annual_revenue = REEMPLAZAR("$","") + REEMPLAZAR(",","") [solo numérico]

SI phone = cualquier formato
ENTONCES phone = formato E.164 (+CC + número de abonado, sin separadores)

SI close_date = NULL
ENTONCES close_date = [dejar en blanco, no usar ninguna fecha predeterminada]

SI contact.account_id NO ES NULL
ENTONCES [resolver AccountId → Company mediante coincidencia de company_name en destino]
SI NO [crear contacto independiente sin asociación de empresa]

Escriba una regla para cada mapeo no trivial. Si no puede escribir la regla, aún no ha tomado la decisión — y ese es exactamente el problema que está tratando de evitar.

Paso 8: Valide el Mapa de Campos con 100 Registros de Prueba

Antes de ejecutar la importación completa, valide cada decisión de mapeo contra su muestra de prueba de 100 registros.

Ejecute la importación de prueba usando su herramienta exacta. No pruebe con un método de importación diferente al que usará el día del cutover. El objetivo es detectar errores en su documento de mapeo, no en su herramienta de importación.

Verifique cada campo mapeado en la salida:

¿Los campos de texto tienen los valores correctos?
¿Los campos de lista de selección muestran los valores del destino (no los valores del origen)?
¿Los campos de fecha se muestran en el formato correcto?
¿Los campos de moneda/número se importan como números, no como texto?
¿Los campos de relaciones se resuelven a los registros correctos de empresa/deal?

Busque errores silenciosos: Una ejecución de importación que se completa sin errores no es lo mismo que una ejecución de importación correcta. Abra 10 registros manualmente y compárelos campo a campo con el origen. El QA automatizado pasa por alto los errores silenciosos de conversión de tipo que parecen limpios en el registro de importación.

Si encuentra errores en la importación de prueba, corrija primero el documento de mapeo. No corrija los registros manualmente en el destino — eso parcha el síntoma y deja la causa raíz en su archivo de mapeo, donde causará el mismo error para los próximos 10.000 registros.

Errores Comunes

Mapear campos personalizados sin decidir si aún se necesitan. El paso de inventario de campos personalizados existe por una razón. Migrar un campo que nadie usa agrega ruido al CRM de destino y confunde a los representantes que ven campos que no reconocen.

Ignorar las discordancias de tipo de campo. "Probablemente estará bien" es como Annual Revenue se convierte en un campo de texto que rompe sus dashboards de ingresos el primer día. Verifique explícitamente cada discordancia de tipo.

No documentar las reglas de transformación y luego olvidarlas. Pasará 90 minutos trabajando en el mapeo de valores de la etapa del ciclo de vida. Tres semanas después, cuando alguien pregunte por qué los Leads aparecen como "Unknown" en un informe, querrá ese documento. Escríbalo mientras está fresco. Para las definiciones de etapa del ciclo de vida que anclan este trabajo de mapeo, etapas del ciclo de vida de leads cubre la progresión estándar y donde la mayoría de los equipos diverge de ella.

Tratar los campos de lookup/asociación igual que los campos regulares. Los campos de relaciones requieren que el registro asociado ya exista en el destino. Si importa Contacts antes de Companies, todas las asociaciones de Company fallan silenciosamente. El orden de importación es parte de la decisión de mapeo de campos.

Probar solo con registros limpios. Su muestra de prueba debe incluir casos extremos: registros con valores nulos, registros con longitud máxima de campo, registros con caracteres inusuales. Un mapeo que funciona con datos limpios fallará con datos reales si omite los casos complicados.

Qué Hacer Después

Exporte los esquemas de objetos de origen esta semana. La mayoría de los CRM tienen una manera de descargar una lista de campos con información de tipo:

Salesforce: Schema Builder (visual) o llamadas describe() vía Salesforce Workbench — Workbench le da una lista completa de campos con nombres de API y tipos en una sola exportación
HubSpot: Configuración > Propiedades > Exportar
Pipedrive: Configuración > Campos de Datos
Zoho: Configuración > Personalización > Campos. Los recursos de migración de CRM de Zoho documentan el esquema completo de objetos si necesita una referencia para los tipos de campo

Cree una hoja de cálculo con cada campo de origen y comience a completar la columna de campo de destino. En esta etapa, incluso un primer borrador aproximado es valioso — descubrirá los casos difíciles (las discordancias de lista de selección, los conflictos de tipo, los campos sin equivalente de destino) y podrá comenzar a tomar decisiones antes de que se conviertan en crisis el día del cutover. Una vez que el mapeo de campos esté completo y probado, implementación y adopción del CRM cubre cómo preparar al equipo para el primer día, porque una importación limpia no garantiza una adopción sin problemas.

Data Migration Guide