Se pasa de una hoja de cálculo a una base de datos cuando la hoja se ha quedado corta: cuando varias personas necesitan escribir a la vez, cuando ha crecido tanto que va lenta o se rompe, o cuando las fórmulas ya no las entiende ni quien las escribió. El salto se da en cuatro movimientos: separar las cosas de las que hablas en tablas (clientes, pedidos, productos), limpiar los datos antes de importarlos, montar una pantalla para no tocar las tablas a pelo, y migrar en paralelo unas semanas hasta confiar en el nuevo sistema.
Si tu hoja es pequeña, la usa una persona y no te da guerra, no cambies nada. Una base de datos es más potente y también más aparatosa. La regla no es «la base es mejor», es «la base compensa cuando la hoja empieza a fallar por lo que es, no por cómo la usas».
¿Cuándo se queda corta una hoja de cálculo?
Cuando aparece al menos una de estas tres señales. Con una ya conviene planteárselo; con dos, el salto casi siempre compensa.
- Varios a la vez. Dos personas abren la hoja y se pisan: una guarda encima de lo que la otra acaba de escribir. Aparecen «copia de copia (2) FINAL_buena.xlsx» y nadie sabe cuál es la verdadera. Una hoja está pensada para un dueño; una base, para varios que escriben sin destrozarse el trabajo.
- Demasiado grande. La hoja pasa de unas pocas miles de filas, tarda en abrir, se cuelga al recalcular o un día se corrompe y pierdes media mañana. Las hojas guardan bien cientos o miles de líneas; no decenas de miles con fórmulas por todas partes.
- Fórmulas imposibles. Tienes ocho pestañas enlazadas con BUSCARV, celdas que dependen de otras que dependen de otras, y cuando algo da mal nadie se atreve a tocar por miedo a romper el resto. Cuando la hoja se ha vuelto un programa frágil escrito en fórmulas, es que pedía ser un programa de verdad.
Si no aparece ninguna, quédate en la hoja. La mejor base de datos es la que no tienes que montar.
¿Qué necesitas tener claro antes de empezar?
Dos cosas, y ninguna es instalar nada.
La primera es de qué cosas habla tu hoja. Mírala y apunta los sustantivos que se repiten: cliente, pedido, producto, factura. Cada uno de esos será una tabla. Hoy seguramente los tienes todos mezclados en una sola hoja: en la misma fila está el cliente, el pedido y el producto, y el nombre del cliente aparece repetido cien veces con tres formas de escribirlo distintas. Modelar es separar eso: una tabla de clientes (cada cliente una vez), una de pedidos, y un enlace entre ellas.
La segunda es qué relación hay entre esas cosas: un cliente tiene muchos pedidos, un pedido tiene muchas líneas de producto. Ese «tiene muchos» es lo que una base de datos hace bien y una hoja hace a duras penas. No hace falta que sepas la jerga; basta con que lo dibujes en una servilleta: cajas y flechas.
¿Cómo se hace, paso a paso?
Seis pasos, en este orden:
- Confirma que la hoja se ha quedado corta. Repasa las tres señales de arriba. Si no aparece ninguna, no sigas: te ahorras la obra.
- Separa las cosas de las que hablas. Los sustantivos que se repiten (clientes, pedidos, productos) se convierten en tablas. Cada dato, en un solo sitio: el teléfono del cliente vive en la tabla de clientes, no repetido en cada pedido.
- Limpia antes de importar. Unifica formatos de fecha, quita duplicados, decide qué haces con los huecos y con los «pendiente / PDTE / -». Importar basura a una base solo te da basura ordenada, y luego cuesta más sacarla.
- Elige la base según el caso. Airtable o Baserow (este lo puedes alojar tú) si quieres algo visual, con tablas y formularios, sin programar. PostgreSQL o SQLite con una pequeña aplicación encima si el volumen es alto o hay reglas propias. Lo más simple que aguante.
- Pon una pantalla delante. Nadie debería escribir directo en las tablas. Un formulario sencillo valida lo que entra —que el email tenga forma de email, que el importe sea un número— y evita que alguien borre media base de un tirón.
- Migra en paralelo. Hoja y base funcionando a la vez unas semanas. Metes los datos en las dos o comparas que dan lo mismo. Solo apagas la hoja cuando confías en la base. Nunca el primer día.
El paso que la gente se salta es el tercero, y es el que decide si el proyecto sale bien. Todo el mundo quiere importar ya y ver la base llena. Pero una base llena de datos sucios es peor que la hoja: parece seria y miente igual.
¿Hoja de cálculo o base de datos? Cuándo cada una
No es que una sea mejor. Sirven para momentos distintos:
| Hoja de cálculo | Base de datos | |
|---|---|---|
| Quién la usa | Una persona, o pocas por turnos | Varias a la vez sin pisarse |
| Tamaño cómodo | Cientos o pocos miles de filas | Decenas de miles en adelante |
| Datos repetidos | El mismo cliente escrito muchas veces | Cada dato una sola vez, enlazado |
| Cómo se entra | Escribes en la celda directamente | Por un formulario que valida |
| Fuerte en | Empezar rápido, cálculos sueltos, prototipos | Crecer, compartir, mantener el orden |
Muchos negocios viven años con hojas y hacen bien. El problema no es usar hojas; es seguir usándolas cuando ya crujen por los cuatro costados.
¿Cuánto cuesta y cuánto se tarda?
Depende de por dónde entres. Con una herramienta tipo Airtable o Baserow, una persona con maña monta las tablas y un par de formularios en unos días, y el coste es la cuota mensual (o cero si alojas Baserow tú). Con una base a medida —tablas relacionales más una aplicación encima— se va de un par de semanas a un mes según cuántas entidades y reglas haya, pero luego es tuya, sin cuotas y sin límites de terceros.
Lo que se ahorra no es solo tiempo: es dejar de tener tres versiones del mismo dato peleándose y dejar de perder mañanas cuando la hoja se corrompe. Un dato en un solo sitio vale más que el mismo dato en cinco.
¿Cuándo NO merece la pena?
- Cuando la hoja es pequeña y de una persona. Si funciona, no da problemas y no la comparte nadie, cambiarla es meterse en obras por gusto.
- Cuando lo que te falta es ver, no guardar. Si tus datos están bien en la hoja pero no consigues sacar conclusiones, no necesitas otra base: necesitas un dashboard sobre la propia hoja. Cambiar de sistema no te va a dar la vista que buscas.
- Cuando nadie va a mantener la pantalla. Una base sin formulario delante acaba siendo una hoja peor: la gente escribe a pelo, mete lo que quiere y en tres meses está tan sucia como estaba. Si no hay quien sostenga la entrada, no des el salto todavía.
¿Qué errores se cometen normalmente?
Casi todos vienen de tratar la base como si fuera una hoja con otro nombre.
- Copiar la hoja tal cual. Volcar la hoja gigante a una sola tabla enorme no es migrar; es mudar el problema de sitio. Si no separas en tablas, no has ganado nada.
- Importar sin limpiar. Las fechas en cuatro formatos, los nombres con y sin tildes, los duplicados: si entran así, se quedan así, y encima ahora cuesta más corregirlos.
- Dejar entrar a pelo. Sin formulario que valide, la base se ensucia sola. Alguien escribe «Madird», otro pone el importe con letras, y adiós al orden que tanto costó.
- Apagar la hoja el primer día. Confiar en la base antes de haberla comprobado es la forma más rápida de perder datos. Paralelo unas semanas, siempre.
Preguntas frecuentes
¿Cuándo se queda corta una hoja de cálculo?
Cuando aparece una de estas tres señales: varias personas necesitan escribir a la vez y se pisan; la hoja ha crecido tanto que va lenta, se cuelga o se corrompe; o las fórmulas y pestañas enlazadas se han vuelto imposibles de entender y mantener. Con una sola señal ya conviene planteárselo; con dos, el salto suele compensar.
¿Qué base de datos elijo para empezar?
Si quieres algo parecido a una hoja pero de verdad multiusuario, Airtable o Baserow (que puedes alojar tú) te dan tablas, formularios y permisos sin programar. Si el volumen es alto o hay reglas de negocio propias, una base relacional como PostgreSQL o SQLite con una pequeña aplicación encima escala mejor. Empieza por lo más simple que aguante tu caso.
¿Voy a perder mis datos al migrar?
No, si migras en paralelo. La clave es no apagar la hoja el primer día. Mantienes hoja y base funcionando a la vez unas semanas, compruebas que dan los mismos números y solo cuando confías en la base dejas de usar la hoja. La hoja original se guarda de todas formas como copia congelada.
¿Cuándo NO merece la pena cambiar de hoja a base de datos?
Cuando la hoja es pequeña, la usa una sola persona y no da problemas: cambiarla es meterse en obras sin necesidad. Y cuando lo que en realidad te falta es ver los datos, no guardarlos mejor: ahí lo que necesitas es un dashboard sobre la propia hoja, no cambiar de sistema.
La hoja no es el enemigo; seguir en ella cuando ya cruje, sí
Se pasa a una base de datos cuando la hoja falla por lo que es: varios a la vez, demasiado grande, fórmulas imposibles. Entonces se separa en tablas lo que antes estaba amontonado, se limpian los datos antes de importar, se pone una pantalla que valide la entrada y se migra en paralelo hasta poder apagar la hoja con tranquilidad.
Si tu hoja es pequeña y de una persona, quédate en ella. Y si lo que te falta es ver los datos, no guardarlos mejor, lo tuyo es un dashboard, no una mudanza. Cambia de sistema solo cuando el sistema es el problema.
¿Tu hoja de cálculo ya cruje?
Si tenéis varios peleándose por el mismo archivo, la hoja tarda en abrir o las fórmulas ya no las entiende nadie, se puede mirar tu caso y decirte si te vale con una herramienta tipo Airtable o si pide una base a medida. Si con la hoja aún vas bien, te lo digo y no tocamos nada. Cuéntame cómo trabajáis hoy con esos datos.
Ver el servicio de software a medida Hablemos de tu caso