Cómo ensayar una importación CSV antes de cambiar datos reales

Pasar clientes o solicitudes desde una hoja de cálculo a un sistema empresarial modifica datos; no consiste solo en cargar un archivo. El archivo puede abrirse correctamente mientras los identificadores pierden ceros iniciales, las fechas cambian de significado y algunos clientes se duplican. Un ensayo debe detectar esos resultados antes de tocar registros reales.

Empieza con un CSV pequeño de datos ficticios, un mapeo acordado y una vista previa de los cambios. El resultado será una decisión sobre si las reglas de importación permiten continuar, respaldada por registros que puedas revisar.

Define el formato antes de elegir el archivo

Enumera las columnas, su significado, cuáles son obligatorias y la codificación y el separador esperados. Indica si hay una cabecera. Trata como texto los códigos cuyo contenido exacto importa. Decide cómo se distingue una celda vacía de una orden para borrar un valor existente.

El RFC 4180 describe un formato CSV común y el uso de comillas en campos con comas, saltos de línea o comillas internas. Es un documento informativo que reconoce diferencias entre implementaciones. Decir “CSV” no constituye por sí solo un acuerdo completo entre el sistema que exporta y el que importa.

Escribe un ejemplo junto a cada columna ambigua. Una fecha como 04/05/2027 no basta sin una convención. Acuerda un formato inequívoco y qué debe hacer el importador con los valores que no lo respeten.

Prepara un archivo que ponga a prueba las reglas

Utiliza personas y registros inventados. Combina filas normales con casos que permitan descubrir errores de interpretación o de reglas de negocio:

• Un código como 00042, que debe conservar sus ceros iniciales.
• Un nombre de empresa con una coma y un contacto cuyo nombre tenga tilde.
• Una nota entre comillas que contenga un salto de línea.
• Un identificador obligatorio ausente y una fecha imposible.
• Dos filas con el mismo identificador de coincidencia y teléfonos distintos.
• Una fila que corresponda a un cliente de pruebas existente y otra de un cliente nuevo.
• Un campo opcional vacío que corresponda a un registro de destino con ese dato completo.

Anota el resultado esperado de cada caso en una ficha separada. No corrijas todas las filas difíciles antes de ensayar: necesitas saber si el importador las rechaza, explica el problema o las procesa incorrectamente.

Decide cómo se reconocen los registros existentes

Elige la clave de coincidencia con el responsable del negocio. Un nombre puede cambiar y dos personas pueden compartirlo. Un correo puede faltar o pertenecer a varias personas. Si origen y destino utilizan identificadores diferentes, documenta su correspondencia en lugar de adivinarla.

Define los resultados de inserción, actualización, sin cambios y rechazo. Si dos filas apuntan al mismo destino, decide si se detiene todo el lote o si esas filas requieren revisión. Evita que prevalezca silenciosamente la última, salvo que sea un requisito explícito.

Para un teléfono vacío, una política posible es conservar el existente si no hay una instrucción expresa de borrado. Otro proceso puede necesitar una regla distinta. El criterio de aceptación es demostrar la política elegida y documentarla, no imponer la misma a todos los negocios.

Revisa los cambios antes de aplicarlos

La vista previa del ensayo debe mostrar qué registros se insertarían, cambiarían, omitirían o rechazarían, con referencia a la fila y su motivo. En las actualizaciones, el revisor autorizado debería poder comparar valores anteriores y propuestos. Los totales deben corresponder al número de filas de datos interpretadas.

Examina un registro representativo de cada categoría. Revisa el código, la fecha, el nombre con tilde, la nota de varias líneas y el comportamiento de los campos vacíos. Comprueba que un error de interpretación no haya desplazado datos entre columnas.

Define también qué ocurre al fallar. Si el proceso se detiene a mitad, ¿revierte el lote, conserva un resultado parcial identificado o puede reanudarse? Ejecuta esa interrupción en pruebas. Una promesa de “todo o nada” necesita evidencia del importador concreto.

Concilia y ensaya la recuperación

Después de aplicar el lote, compara los identificadores esperados con los del destino. Los totales no descubren un registro ausente compensado por un duplicado. Inspecciona los valores modificados y confirma que las filas rechazadas no alteraron datos existentes.

Repite el mismo archivo. Según la política acordada, debería dejar registros sin cambios o realizar actualizaciones controladas, sin duplicados accidentales. Documenta cómo reenviar una fila corregida sin repetir operaciones ajenas.

Antes de importar datos reales, identifica quién aprueba, qué registros se afectan, cómo se recuperan y quién verifica. Una marca de lote o un historial ayuda a localizar los cambios, pero la recuperación debe respetar modificaciones legítimas posteriores. No presentes un respaldo como reversión probada si nunca se ha ensayado su restauración.

Contacta con Dynelink para definir el mapeo, una vista previa revisable y una conciliación para tu migración. Los ejemplos son datos hipotéticos de prueba, no resultados de migraciones de clientes.