La Respuesta Breve
El Data Mapping no es simplemente una hoja de traducción entre campos, sino el documento donde la organización define el significado de cada dato que incorpora a Salesforce. Casi cualquier error de carga que parece técnico –formato de fecha, un Picklist desconocido, un vínculo roto– nace primero de una decisión de negocio no tomada.
El orden que funciona es el siguiente: primero se determinan qué entidades se migrarán, luego quién es el propietario de negocio de cada entidad, después qué campos tienen un consumidor real, y solo al final se escriben las reglas de conversión. Cuando se inicia en sentido contrario, el equipo técnico toma decisiones de negocio de forma silenciosa, y esto se descubre tres meses después del Go Live, cuando un informe de ingresos no coincide.
Los antecedentes sobre la planificación de toda la conversión se encuentran en Migración de datos a Salesforce.
Los Tres Tipos de Brechas que el Mapping Revela
| Tipo de Brecha | Ejemplo Común | Quién Decide |
|---|---|---|
| Brecha Semántica | "Cliente Activo" = compró este año en un sistema, = no bloqueado en otro sistema | Propietario del Proceso de Negocio |
| Brecha Estructural | Un cliente con cinco direcciones frente al modelo Account/Contact | Arquitecto de Datos |
| Brecha de Calidad | 18% de registros sin ID fiscal válido | Data Owner + Regulación |
La brecha semántica es la más costosa, porque no se detecta durante la carga. El dato se ingresa con éxito, la automatización se ejecuta sobre él, y el informe muestra un número erróneo que parece plausible. Las brechas estructurales se detectan durante la carga y, por lo tanto, se descubren temprano. Las brechas de calidad se descubren solo si se han definido umbrales de aceptación previamente.
La Capa de Significado: Data Dictionary Antes de la Hoja de Mapping
Antes de mapear campo a campo, es fundamental crear un diccionario de términos para cada entidad central: qué es una Cuenta (Account), qué diferencia a un Lead de un Contacto en esta organización, cuándo se cierra una Oportunidad (Opportunity). Estas definiciones son concisas –dos líneas por entidad– pero son clave para resolver disputas en lugar de solo señalar.
La prueba sencilla: pida a tres personas de tres departamentos diferentes que definan "cliente" por separado. Si las definiciones son distintas, la migración transferirá tres verdades diferentes a la misma tabla.
Anatomía de una Fila de Mapping Correcta
Cada fila de la hoja debe responder a siete preguntas: desde qué objeto y campo de origen, a qué objeto y campo en Salesforce, cuál es el tipo y longitud del dato, cuál es la regla de conversión, qué sucede con un valor nulo, cuál es el valor predeterminado, y quién lo aprobó. Una fila que carezca de alguna de estas columnas se convertirá en una pregunta en medio de una carga nocturna durante el Cutover.
Tres reglas de trabajo que evitan problemas:
- No hay conversiones silenciosas. Cualquier valor que el sistema "corrige" por sí mismo debe registrarse en un log de excepciones.
- El valor predeterminado es una decisión de negocio. Quien escribe
País = EScomo predeterminado debe ser el responsable de los informes por región. - IDs externos antes que nada. Para cada entidad, se debe preservar el ID externo del sistema de origen. Sin él, no hay Reconciliación ni segundas ejecuciones.
Transformaciones: Dónde se Cometen Errores
Las transformaciones que causan el mayor daño son precisamente las más simples. Las fechas sin zona horaria mueven los registros un día; los nombres que se normalizan con Trim y Upper sin una regla uniforme generan nuevas duplicidades justo después de haber limpiado las antiguas; los montos convertidos a una moneda única con una tasa diaria producen diferencias en los informes frente al ERP.
La regla: toda conversión numérica o monetaria se verifica comparando sumas, no comparando registros. Una cuenta idéntica no es prueba de veracidad.
Quienes aún no han resuelto la cuestión de la fuente de verdad encontrarán información en Fuente Única de Verdad en la Organización, y el proceso de migración en sí mismo en Cutover y Reconciliación en Migraciones de Salesforce.
Escenario: Empresa de Servicios con Dos Sistemas de Origen
Una organización de servicios con 90,000 clientes inició una conversión desde dos sistemas: un sistema de facturación antiguo y un sistema de servicio adquirido con una subsidiaria. La primera hoja de Mapping fue marcada como "lista" en dos semanas, con 340 campos mapeados.
En la primera ejecución de prueba (Rehearsal), el 97% de los registros se cargaron. El problema se descubrió durante la Reconciliación: el total de saldos en Salesforce era un 4.1% inferior al del ERP. La razón no fue una carga fallida, sino que todos los registros con saldos negativos (créditos) se mapearon a un campo con una Rule de Validación que impedía valores negativos, y se establecieron silenciosamente en cero.
La corrección se implementó en dos niveles: una regla de conversión explícita para los créditos, y un cambio de política para que cualquier regla que establezca un valor en cero o lo trunque deba generar una línea de excepción. En la segunda ejecución, el número de excepciones aumentó a 1,900, lo cual fue un avance: las excepciones eran visibles en lugar de ocultas. La tercera ejecución redujo las excepciones documentadas a 40, y solo entonces se fijó la fecha de Cutover.
Riesgos Comunes y Acciones Preventivas
| Riesgo | Cómo se Manifiesta en la Práctica | Acción Preventiva |
|---|---|---|
| Transferencia de toda la historia | Volumen, duplicidades e información sin valor migran al nuevo sistema | Definir Retention y umbrales de calidad |
| Mapping puramente técnico | Los campos se transfieren sin entender su significado de negocio | Data Dictionary y propietarios de negocio |
| Conversiones silenciosas | Los valores se corrigen automáticamente y nadie lo sabe | Log de excepciones obligatorio para cada regla de conversión |
| Sin Rehearsal | La ventana de inactividad se alarga y surgen sorpresas | Al menos dos ejecuciones completas |
| Sin External ID | Imposibilidad de verificar, corregir o volver a ejecutar | La clave de origen se guarda para cada entidad |
Cómo Medir el Éxito
| Área | Qué se Mide | Frecuencia de Verificación |
|---|---|---|
| Integridad (Completeness) | Tasa de campos obligatorios completados en el destino | Antes y después de cada carga |
| Reconciliación | Coherencia de conteos, sumas y relaciones con la fuente | En cada Rehearsal y en el Cutover |
| Excepciones | Número de líneas de excepción abiertas según gravedad | Diariamente durante el período de conversión |
| Campos sin consumidor | Cuántos campos transferidos no se usaron en 90 días | Una vez después del Go Live |
La última métrica es una preparación para el siguiente ciclo: enseña cuánto trabajo fue innecesario y orienta el alcance de la próxima conversión.
Las organizaciones que prefieren acompañamiento profesional en la construcción del Mapping lo hacen a través del Servicio de Integraciones y Datos.
Checklist Antes de la Primera Carga
- ☐ Diccionario de términos conciso para cada entidad central, aprobado por el negocio
- ☐ Lista de campos con un consumidor definido; el resto al archivo
- ☐ ID externo para cada entidad que se migra
- ☐ Tabla completa de Value Mapping, incluyendo valores para elementos desconocidos
- ☐ Regla explícita para cada valor nulo y para cada valor predeterminado
- ☐ Cada regla de conversión genera una línea de excepción en lugar de una corrección silenciosa
- ☐ Escenario de Reconciliación: conteo, sumatoria, relación, muestreo manual
- ☐ Umbral de excepciones acordado por encima del cual no se realiza el Cutover
- ☐ Versión y firma de la hoja de Mapping
- ☐ Plan de Rollback y de reejecución
Recursos Profesionales
- Salesforce Data 360 — https://www.salesforce.com/data/
- Salesforce Data 360 Architecture — https://architect.salesforce.com/docs/architect/fundamentals/guide/data-360-architecture.html
- HPI Pro – Integraciones y Datos — https://hpi.pro/integrations-data