Bases de datos heredadas: modernizar sin tirarlo todo

El sistema “viejo” que una empresa quiere tirar suele ser, precisamente, el que mejor conoce su negocio. Nos pasa a menudo: llega un gerente convencido de que su base de datos heredada hay que reemplazarla entera. Años de operación metidos en hojas de cálculo, en un FileMaker antiguo o en un Access que ya nadie recuerda quién montó, y que “ya no aguanta más”.

Casi siempre, la primera idea es la de tirarlo todo y empezar de cero con algo nuevo. Y casi siempre, ese es el camino más caro y el más arriesgado.

Nuestra forma de abordarlo es la contraria: modernizar sin tirar lo que funciona.

Por qué el “big bang” sale caro

Cuando una empresa lleva años operando sobre el mismo sistema, aunque sea uno hecho a mano en Excel o en una base de datos antigua, ese sistema tiene metida dentro una cantidad enorme de lógica de negocio que nadie ha documentado en ningún sitio. Reglas de descuentos, excepciones para ciertos clientes, formas de calcular un precio que solo tienen sentido si conoces la historia detrás. Sustituirlo todo de golpe significa reconstruir esa lógica desde cero, adivinando, con el riesgo real de perder matices que llevan años funcionando bien.

Además, mientras se hace esa reconstrucción completa, la empresa tiene que seguir operando. Un proyecto de “todo o nada” suele significar meses sin ver ningún resultado, con el negocio funcionando a la vez sobre el sistema viejo, sin saber si lo nuevo va a cubrir de verdad todos los casos que el viejo sí cubría.

Qué significa “entender el sistema actual”

Este paso suele subestimarse porque no se ve: no produce ninguna pantalla nueva, ningún informe que enseñar. Consiste en sentarse con las personas que usan el sistema cada día y preguntar, casi caso por caso, por qué se hace así. Por qué este cliente tiene una tarifa distinta, por qué este campo se rellena a mano en lugar de calcularse solo, por qué existe ese paso intermedio que nadie recuerda haber diseñado a propósito.

Casi siempre aparecen dos tipos de respuesta. Una es la excepción real: una regla de negocio legítima que nadie escribió en ningún sitio porque se aprendió a base de errores pasados, y que hay que respetar en el sistema nuevo si no se quiere volver a cometer el mismo error. La otra es el parche que ya no hace falta: una solución que tenía sentido con las herramientas de hace diez años y que hoy solo añade pasos. Distinguir una de la otra antes de tocar nada es lo que evita el error más caro de una modernización, que es simplificar por error una regla que sí importaba.

Cómo lo hacemos: por capas

Lo primero, antes de tocar nada, es entender qué hace el sistema actual de verdad, no lo que la gente cree que hace. Esa diferencia existe casi siempre, y encontrarla es la parte más importante del trabajo: esos años de lógica acumulada valen oro, y hasta ese momento nadie los ha puesto por escrito.

A partir de ahí, modernizamos por capas: una interfaz nueva encima de los datos existentes, una integración por API con otro sistema, la automatización del proceso más doloroso de todos, sin parar la operación del día a día. Cada capa que se sustituye o se añade aporta valor por sí sola, sin depender de que el proyecto entero termine para empezar a notarse.

Y lo más importante: conservamos el dato y la lógica que sí funcionan, y reescribimos solo lo que de verdad estorba. No hace falta rehacer lo que ya resuelve bien un problema solo porque el sistema alrededor sea antiguo.

Lo hemos aplicado construyendo CRMs y aplicaciones de gestión a medida en FileMaker para clientes que partían de hojas de cálculo y sistemas dispares: en lugar de un cambio radical para toda la empresa, una migración por fases donde cada paso ya aporta algo por sí mismo, sin obligar a nadie a aprender un sistema completamente nuevo de un día para otro.

Por qué esto también es una decisión de riesgo, no solo de coste

Además del coste, hay una razón de riesgo para preferir las fases frente al cambio radical: cada capa que se pone en marcha se puede validar por separado, con datos reales y con la gente que va a usarla todos los días, antes de construir la siguiente. Si algo no funciona como se esperaba, el error se detecta y se corrige a tiempo, sobre una parte pequeña del sistema, en lugar de descubrirse al final de un proyecto largo, cuando ya está todo construido sobre una base equivocada.

Esto importa especialmente cuando el sistema heredado es crítico para la operación diaria: una empresa no puede permitirse parar la facturación, la gestión de pedidos o el seguimiento de proyectos mientras se reconstruye todo desde cero. Modernizar por fases significa que en todo momento hay un sistema funcionando, sea el viejo, el nuevo, o los dos conviviendo mientras se completa la transición.

Qué preguntar antes de decidir tirarlo todo

Si estás en esa situación (un sistema que funciona pero frena, y la tentación de sustituirlo entero) hay preguntas que conviene hacerse antes de decidir:

¿Qué parte del sistema actual falla de verdad, y qué parte simplemente “se ve vieja”? No son lo mismo, y confundirlas lleva a rehacer cosas que funcionaban bien.

¿Qué pasaría si solo se sustituyera la parte que más duele, dejando el resto tal cual por ahora? Muchas veces esa única capa ya resuelve el problema que motivó la conversación.

¿Hay alguien en la empresa que entienda de verdad toda la lógica que hay metida en el sistema actual, o se ha ido perdiendo con el tiempo? Si la respuesta es la segunda, ese es motivo de más para no reconstruir a ciegas.

Lo que nos llevamos de esto

Modernizar no es empezar de cero. Casi nunca lo es. Es respetar lo que el negocio ya sabe hacer bien y quitarle la fricción que le sobra, un paso cada vez. Si tienes un sistema heredado que te está frenando y no sabes por dónde empezar, en cómo trabajamos explicamos el proceso que seguimos para entenderlo antes de tocar nada.