Una entidad que imparte formación y servicios de salud, seguridad y medio ambiente gestiona cursos, vencimientos y evaluaciones de riesgo con una aplicación nacida en 2008 y crecida por acumulación. Dentro hay años de ley codificada en el código — normativa de seguridad laboral, acuerdos de formación, cálculos de riesgo. La pregunta era: ¿se reescribe? La respuesta honesta es no. Aquí está el porqué, y qué hicimos en su lugar.
01Por qué "reescribir desde cero" era la respuesta equivocada
Ante una aplicación vieja, la tentación es tirarla y rehacerla. Pero aquí el valor no está en la interfaz: está en las reglas normativas codificadas en el servidor — la evaluación de riesgo, los requisitos de formación por puesto, los vencimientos legales. Son reglas con valor legal, escritas en el código a lo largo de los años, sin tests y sin especificación. Reescribirlas a ciegas no es modernizar: es reintroducir errores donde un error tiene consecuencias legales.
02Qué dicen los hechos del código
El censo fotografió la situación real: un cliente Java de escritorio de cientos de miles de líneas (solo interfaz, salvo cuatro focos de lógica bien identificados) y un servidor con el verdadero valor — la capa que calcula y aplica las reglas. Los dos están soldados: hablan un protocolo antiguo y no estándar (XML-RPC, ya al final de su vida) intercambiando objetos Java serializados. No existe una API neutra: ningún cliente web, ningún otro lenguaje puede hablar ese protocolo.
Y los problemas que nadie había buscado: contraseñas en MD5 sobre datos sanitarios (un asunto del art. 9 del RGPD), secretos en claro, librerías al final de su vida, un framework de persistencia propietario y de código cerrado (riesgo de persona clave), despliegue solo Windows de 32 bits y ningún test automático — ninguna red de seguridad para cualquier cambio.
03La dirección: mantén el cerebro, rehaz la entrega
El camino elegido no es la reescritura, es el Strangler Fig: se estrangula lo viejo pieza a pieza, no se derriba.
En concreto: se mantiene el cerebro (la capa que calcula las reglas, los datos, la base de datos), se le pone delante una API REST real y neutra junto al viejo protocolo, y se rehace el cliente como web un área funcional cada vez. El viejo protocolo y la vieja interfaz se apagan los últimos, solo con la migración completada.
04El riesgo confinado donde se puede gestionar
La fuerza del Strangler está donde no llega: el núcleo normativo — las reglas con valor legal — se queda en su sitio, probado por años de uso. El cambio vive en el perímetro (la API y la interfaz), la parte sustituible sin perder reglas. Y el mapa completo "pantalla → servicio → regla → tabla" ya existe desde el censo: la especificación de la futura API no se reinventa a ciegas, se lee de ahí.
Los cuatro focos de lógica que quedan en el cliente — cálculos que el servidor no replica — se mueven al servidor como primer paso, para que la interfaz sea de verdad sustituible sin llevarse una regla.
05Se empieza por un piloto
Un proyecto así no se hace de golpe: se empieza por un área pequeña y autocontenida, se lleva a la nueva vía (API + web) junto a la vieja y se usa de verdad. Es la manera de validar el enfoque sobre el terreno antes de ampliarlo, y de sacar los problemas cuando cuestan poco. Mientras tanto, durante el trabajo de API, se arregla lo que no puede esperar: el MD5 sobre datos sanitarios, los secretos en claro, las librerías al final de su vida.
06Lo que aprendimos
1. El valor de un legacy suele ser invisible. No es la interfaz que se ve: es la ley escrita en el código. Eso se conserva, no se reescribe a ciegas.
2. Medir cierra las incógnitas. Un censo completo convirtió "quién sabe qué hay dentro" en una lista pequeña y cerrada.
3. Strangler gana al big-bang cuando hay un núcleo con valor legal: riesgo confinado al perímetro, proyecto incremental y reversible.
4. La seguridad se arregla por el camino. MD5 sobre datos sanitarios y secretos en claro no esperan al final: se cierran mientras se construye la API.