Convertir datos entre formatos sin perder la cabeza
Una guía práctica para migrar datos entre CSV, JSON, YAML y XML — el pipeline real para migraciones e integraciones.
Ya has estado ahí. La exportación de base de datos te da CSV. La nueva API quiere JSON. La configuración de despliegue necesita YAML. El sistema legacy solo habla XML. Y de alguna manera, tú eres quien tiene que hacer que todo se comunique.
La conversión de formatos de datos suena simple hasta que realmente lo haces. Así es cómo construir un pipeline real que no se desmorone.
El escenario: una migración real
Supongamos que estás migrando datos de usuario de un sistema viejo a uno nuevo. Esta es la situación:
- Fuente: exportación CSV de la base de datos antigua (10.000 filas, 15 columnas)
- Capa API: el nuevo sistema acepta JSON vía REST API
- Archivos de config: configuración de despliegue en YAML
- Integración legacy: un sistema socio que aún requiere feeds XML
Cuatro formatos. Un conjunto de datos. Empecemos.
Paso 1: CSV a JSON — Del export a la API
Tu CSV se ve así:
id,name,email,plan,created
1,Alice,alice@example.com,pro,2024-03-15
2,Bob,bob@example.com,free,2024-06-22
Convertido a JSON obtienes datos estructurados que tu API puede consumir:
[
{
"id": 1,
"name": "Alice",
"email": "alice@example.com",
"plan": "pro",
"created": "2024-03-15"
}
]
Cuidado con: campos entrecomillados con comas dentro, valores vacíos que deberían ser null en vez de strings vacíos, y formatos de fecha que varían entre filas. Estos bugs aparecen en la fila 4.738 cuando pensabas que todo funcionaba.
Paso 2: JSON a YAML — Para archivos de configuración
El despliegue necesita config YAML. La estructura de datos es la misma — solo cambia la sintaxis:
users:
- id: 1
name: Alice
email: alice@example.com
plan: pro
created: "2024-03-15"
YAML es más legible para archivos de config — por eso lo usan Kubernetes, Docker Compose y los pipelines de CI/CD. Pero es sensible a los espacios: una indentación mal puesta y tu despliegue se rompe a las 2 de la mañana.
Paso 3: JSON a XML — Para sistemas legacy
Ese sistema socio de 2015 necesita XML. No, no van a actualizar su API. Sí, hay que seguir soportándolo.
<users>
<user>
<id>1</id>
<name>Alice</name>
<email>alice@example.com</email>
</user>
</users>
La conversión es directa, pero XML tiene sus particularidades — atributos vs elementos, requisitos de namespace, validación de esquema. El convertidor XML maneja la transformación estructural; la lógica de negocio es cosa tuya.
Paso 4: Validar todo con el formateador JSON
En cada etapa, formatear y validar tu JSON. Un corchete mal puesto, una coma de más, una comilla sin escapar — y tu importación pierde registros silenciosamente o crashea por completo.
Antes de enviar datos convertidos a una API, formatéalos y revisa la estructura visualmente. Cinco segundos de formateo ahorran cinco horas de depurar "por qué faltan 200 registros."
Trampas comunes en migraciones de datos
Problemas de encoding: un CSV de Excel en Windows podría ser Windows-1252, no UTF-8. Los nombres de clientes con caracteres especiales se convierten en signos de interrogación. Siempre verificar el encoding primero.
Coerción de tipos: CSV trata todo como strings. 001 en CSV se convierte en 1 en JSON. Códigos postales, números de teléfono y campos de ID con ceros iniciales son las víctimas habituales.
Datos anidados: CSV es plano. JSON es anidado. Hay que decidir cómo address_street, address_city, address_zip en CSV se mapea a un objeto address en JSON.
Null vs vacío: ¿Una celda CSV vacía es null, "", o debería omitirse la clave? Definirlo antes de empezar, no cuando encuentres el bug.
El patrón del pipeline
Para cualquier migración de datos, el flujo de trabajo es:
- Exportar — del sistema fuente (normalmente CSV o dump SQL)
- Convertir — al formato de trabajo (CSV a JSON)
- Transformar — la estructura (renombrar campos, anidar objetos, corregir tipos)
- Validar — la salida (formatear y revisar)
- Convertir — al formato destino (YAML o XML)
- Importar — al sistema destino
Las herramientas manejan los pasos 2, 4 y 5. Los pasos 1, 3 y 6 son tu código. Separar "conversión" de "transformación" mantiene todo manejable.
Las migraciones de datos nunca son tan simples como parecen en el documento de planificación. Pero con herramientas de conversión fiables en cada paso, dedicas tu tiempo a los problemas reales — lógica de negocio, casos límite y calidad de datos — en lugar de pelear con la sintaxis de formatos.