Una plantilla de mapeo de datos documenta cómo se convierte cada campo de origen en un campo de destino: de dónde procede el valor, qué transformación se permite y qué ocurre si no puede utilizarse. Una línea entre «ID de cliente» e «ID» es un comienzo, pero no basta para implementar ni probar una importación.
El siguiente ejemplo transforma un pequeño CSV de clientes en una nueva tabla de clientes. Incluye las reglas de cada campo, un registro aceptado, entradas rechazadas y un formato reutilizable de ficha de mapeo. Todas las organizaciones y los registros del ejemplo son ficticios.
Qué debe documentar un mapeo de origen a destino
Empieza por las definiciones del origen y el destino, no solo por capturas de las cabeceras. Para cada campo, registra el tipo de dato, si es obligatorio u opcional, la transformación, los valores válidos y el tratamiento de errores. Puedes organizar los campos de origen, las reglas y los campos de destino en un lienzo compartido de diagramación en Boardmix, para que quienes suministran y reciben los datos revisen el mismo mapeo.
El diagrama documenta el acuerdo sobre cómo deben trasladarse los datos. No ejecuta la migración. Un script de importación o una herramienta de integración debe implementar las reglas y generar los registros aceptados y retenidos.
Distingue estos tres documentos relacionados:
- Un diagrama entidad-relación describe las entidades, los atributos y las relaciones del modelo de datos.
- Un diagrama de flujo de datos explica cómo circulan los datos entre procesos, almacenes y participantes externos.
- Un mapeo de origen a destino especifica qué ocurre con cada campo durante la transferencia.
Pueden estar uno junto al otro, pero una relación entre Cliente y Pedido no explica cómo convertir un antiguo código de estado en un valor nuevo.
Ejemplo completo: cinco campos de una importación de clientes
Supongamos que un sistema antiguo exporta una fila por cliente. El sistema nuevo necesita cinco campos. Se trata de una importación única a un destino vacío, no de una actualización o fusión con registros existentes.
| Campo del CSV de origen | Campo y tipo de destino | Significado |
|---|---|---|
| source_ref | customer_id — texto | Identificador estable del cliente |
| company_label | display_name — texto | Nombre de la organización mostrado a los usuarios |
| country | country_code — texto | Código de la lista de países admitidos por el destino |
| joined | joined_date — fecha | Fecha de incorporación, sin componente de hora |
| state | account_status — texto | Clasificación de la cuenta como activa o inactiva |
En este ejemplo, los cinco campos de destino son obligatorios. Solo se admiten los códigos de país GB, JP y ES, y los estados active e inactive. Son listas pequeñas elegidas para explicar el caso, no una recomendación de limitar un sistema real a tres países.
El identificador es texto aunque contenga únicamente dígitos. Convertir «0017» en el número 17 cambiaría el identificador. Los tipos de datos tienen significado; no son simples preferencias de formato.
Especifica la transformación y el tratamiento de errores de cada campo
| Mapeo | Transformación | Retener la fila cuando… |
|---|---|---|
| source_ref → customer_id | Eliminar espacios iniciales y finales; conservar el resto, incluidos los ceros iniciales. | El resultado está vacío o aparece más de una vez en el archivo de entrada. |
| company_label → display_name | Eliminar espacios iniciales y finales; conservar los espacios interiores, la escritura y los acentos. | El resultado está vacío. |
| country → country_code | Tras quitar espacios exteriores, convertir United Kingdom → GB, Japan → JP y Spain → ES. | El valor no figura en esta lista exacta de equivalencias. |
| joined → joined_date | Tras quitar espacios exteriores, aceptar una fecha válida con el formato YYYY-MM-DD. | La fecha falta, es ambigua, no existe o utiliza otro formato. |
| state → account_status | Tras quitar espacios exteriores, convertir A → active e I → inactive. | El código falta o no es A ni I. |
Los valores desconocidos no se corrigen automáticamente. Una «a» minúscula hace que la fila quede retenida porque la especificación de origen solo permite A e I mayúsculas. Si el equipo quiere ignorar las diferencias entre mayúsculas y minúsculas, debe cambiar la regla y añadir el caso de prueba correspondiente. No dejes esa decisión en manos de un valor predeterminado de la herramienta.
Del mismo modo, no debe interpretarse «03/09/26» según la configuración regional de quien ejecuta la importación: puede representar fechas diferentes. Pide al responsable del origen que proporcione el formato acordado o documenta un formato de origen conocido antes de convertirlo.
Relacionar nombres de campos y convertir tipos de datos son tareas diferentes. La documentación de Microsoft sobre mapeo de esquemas y tipos de datos muestra esa distinción en una herramienta concreta. La configuración cambia según la plataforma, pero el acuerdo sobre los campos debe definir el resultado antes de configurar la integración.
Sigue un registro desde la entrada hasta la salida
Este es un registro de origen completo. Las comillas permiten ver los espacios de los extremos; no forman parte de los valores almacenados.
- source_ref: « 0017 »
- company_label: «Orion Studio »
- country: «United Kingdom»
- joined: «2026-09-03»
- state: «A»
Si ninguna otra fila tiene el identificador 0017 después de eliminar los espacios exteriores, el registro de destino aceptado es:
- customer_id: «0017»
- display_name: «Orion Studio»
- country_code: «GB»
- joined_date: 2026-09-03
- account_status: «active»
Esta transformación no divide el nombre de la empresa, no lo traduce al inglés ni convierte el identificador en número. Esas operaciones serían reglas adicionales, no una limpieza inocua. Conserva la fila original en los registros de la importación para poder rastrear cada resultado hasta su entrada.
Incluye los registros retenidos en el diseño
Un mapeo que solo muestra filas correctas deja sin definir una parte importante del trabajo. En este ejemplo, un único campo inválido retiene la fila completa. No se escribe un registro de cliente parcial.
| Problema de entrada | Tratamiento esperado | Etiqueta del motivo |
|---|---|---|
| joined contiene «2026-02-30» | Retener la fila; no desplazar la fecha a marzo. | INVALID_JOINED_DATE |
| country contiene «UK» | Retener la fila; UK no aparece en la lista de origen del ejemplo. | UNMAPPED_COUNTRY |
| state está vacío | Retener la fila; no suponer que la cuenta está activa. | MISSING_STATUS |
| Dos filas producen customer_id «0017» tras quitar espacios | Retener ambas hasta que el responsable del origen resuelva el duplicado. | DUPLICATE_CUSTOMER_ID |
La etiqueta identifica el problema, pero la salida de registros retenidos también necesita una referencia a la fila original y al campo afectado. Evita introducir datos personales innecesarios en los mensajes de error. En una migración real, utiliza datos de muestra aprobados y los controles de acceso de la organización, en lugar de copiar registros de clientes en una pizarra sin restricciones.
El tratamiento de duplicados debe definirse por separado de la conversión de campos. «Conservar la última fila» parece sencillo, pero hace depender el resultado del orden del archivo. Si una marca de tiempo verificada u otra regla de negocio determina cuál es el registro correcto, documenta también cómo resolver empates. Si no existe ese criterio, detén los registros en conflicto en vez de elegir arbitrariamente.
Copia esta ficha de mapeo para cada campo
Una hoja de cálculo ancha facilita revisar muchos campos; una ficha pequeña resulta más cómoda para discutir una transformación difícil. Esta ficha contiene la misma información esencial:
- ID del mapeo: M-03
- Origen: customer_export.country, texto
- Destino: customer.country_code, texto obligatorio
- Significado: clasificación de país utilizada por el destino
- Regla: quitar espacios exteriores y aplicar United Kingdom/GB, Japan/JP y Spain/ES
- Valor ausente o no reconocido: retener la fila de origen completa
- Ejemplo: « Japan » se convierte en «JP»; «JPN» queda retenido
- Responsable de aclaraciones: la persona responsable de los valores de país en el origen
Si una transformación depende de varios campos, registra todas las entradas en la misma ficha. Un full_name construido a partir de given_name y family_name no equivale a dos mapeos directos independientes. Define juntos el orden, los separadores y qué ocurre si falta una parte. Si hay una búsqueda en otra tabla, indica la clave y el comportamiento cuando se encuentran cero o varias coincidencias.
Revisa un lote aceptado y otro con errores con tu equipo
En Boardmix, coloca el esquema de origen a la izquierda y el de destino a la derecha. Sitúa las fichas entre ambos, con conectores etiquetados para los campos que requieren conversión. Deja el registro aceptado debajo del flujo principal y los registros retenidos en una zona separada. Así se ve dónde está el desacuerdo: en el nombre del campo, en su significado o en un valor inválido.
Pide al responsable del origen que explique los valores y al responsable del destino que detalle los requisitos del sistema receptor. Después, sigue los registros de ejemplo a través de cada regla. Si una persona espera que «UK» se acepte y otra que se retenga, resuelvan la lista de equivalencias antes de ejecutar la importación.
En la primera prueba de implementación, comprueba que el número de filas de entrada coincide con la suma de filas aceptadas y retenidas. En este ejemplo, cada fila debe aparecer exactamente en uno de esos dos grupos. Compara también los identificadores y valores: unos totales correctos no detectarían que un cliente recibió el estado equivocado.
Abre Boardmix para construir y revisar tu mapa de origen a destino y entrega las reglas acordadas y los resultados de ejemplo a quien implemente la migración. El mapa documenta el acuerdo; la prueba de importación demuestra si la implementación lo cumple.
