Cómo Migrar Excel a una Base de Datos

Conviene decirlo antes que nada: una base de datos es almacenamiento. Guarda los datos de forma confiable, fuerza tipos y relaciones, y permite que muchas personas lean y escriban a la vez. No le da a tu equipo una forma de trabajar. En cuanto los datos viven en una base, alguien necesita una interfaz para cargar, editar y revisar — por eso la mayoría de las migraciones termina construyendo una aplicación encima, y no solo un esquema.

Una planilla es un solo rectángulo plano. Una base de datos son varias tablas relacionadas. El primer trabajo es ver dónde termina una tabla y empieza otra, y la pista es la repetición:

• Un nombre de cliente repetido en 400 filas es una tabla de clientes, referenciada por id
• Columnas tipo Ítem 1, Ítem 2, Ítem 3 son una tabla hija con una fila por ítem, no tres columnas
• Una pestaña por mes o por sucursal es una tabla con una columna de fecha o de sucursal, nunca una tabla por pestaña
• Una columna que guarda dos cosas ("ACME-2024-FAC-003") son varias columnas
• Un color que significa algo es una columna de estado que nunca se escribió

Ese último punto importa más de lo que parece. El significado codificado en el formato — filas resaltadas, negrita, una celda que alguien siempre deja vacía — es lógica de negocio real que ninguna importación va a trasladar. Se encuentra preguntándole a quien mantiene el archivo qué significa cada convención visual.

Este es el paso que determina si el proyecto sale bien. Toda planilla que corrió un proceso durante años acumuló lógica en tres lugares, y solo el primero es fácil de encontrar:

Escribí las reglas en lenguaje simple antes de diseñar nada. Los equipos que llegan a una consulta con ese documento obtienen proyectos más cortos y más baratos, porque el relevamiento es la incógnita más cara de cualquier cotización.

Una base de datos va a rechazar datos que la planilla aceptaba sin problema. Ese rechazo es el punto, y también es el trabajo:

• Fechas guardadas como texto, como número y en dos órdenes distintos en la misma columna
• Números con símbolo de moneda, separador de miles o espacios al final
• El mismo cliente escrito de cuatro formas, ninguna coincidente con el CRM
• Celdas combinadas, que no significan nada en una tabla
• Filas vacías usadas como separador visual, y filas de totales mezcladas con los datos
• "N/A", "-", "pendiente" y vacío significando lo mismo en una sola columna

Decidí deliberadamente cuánto historial llevar. Migrar tres años en vez de diez suele eliminar semanas de limpieza de registros que nadie consulta. Lo viejo se puede archivar tal cual, sin limpiar.

Para la enorme mayoría de los procesos de negocio que salen de una planilla, la respuesta es PostgreSQL: es gratis, maduro, maneja bien datos relacionales y lo soporta cualquier proveedor. Elegí distinto solo por una razón concreta:

1. 1Importá el historial al esquema nuevo y verificá totales contra la planilla — no muestreos, sumas reales sobre las cifras que la empresa reporta.
2. 2Que el equipo cargue en los dos durante dos a cuatro semanas. Sí, es trabajo doble, y es el seguro más barato disponible.
3. 3Compará resultados a diario al principio. Cada diferencia es un error de migración o una regla que nadie mencionó en el paso 2 — las dos conviene encontrarlas ahora.
4. 4Migrá recién cuando un ciclo completo de reportes coincida de punta a punta.
5. 5Dejá la planilla en solo lectura en vez de borrarla. Guardala unos meses como referencia que nadie pueda editar.