Todo proyecto de modernización de sistemas legacy empieza con la misma idea tentadora: congelar el desarrollo de funcionalidades, reescribir el sistema bien esta vez, y hacer el corte una vez esté terminado. Casi todos esos proyectos terminan disparando el calendario, se cancelan antes de salir, o entregan una reescritura que ya está desactualizada en el momento de su lanzamiento. La alternativa, la modernización incremental, es menos satisfactoria de planificar, pero tiene muchísimas más probabilidades de llegar realmente a producción.
Por qué fracasa la reescritura big-bang
Un sistema legacy codifica años de casos límite, reglas de negocio y arreglos silenciosos que nadie documentó. Una reescritura tiene que redescubrir todo eso desde cero, normalmente sin el contexto original, mientras el negocio sigue cambiando por debajo. Para cuando el nuevo sistema alcanza la paridad de funcionalidades con los requisitos del sistema anterior de hace dieciocho meses, el sistema antiguo ya ha seguido evolucionando, y el negocio también.
El patrón strangler fig
En lugar de sustituir todo el sistema de una vez, enruta el tráfico de una capacidad a la vez hacia una nueva implementación, mientras el sistema legacy sigue gestionando todo lo demás. Con el tiempo, el nuevo sistema crece alrededor del antiguo hasta que nada depende ya del código legacy, y este puede retirarse con seguridad, de la misma forma en que una higuera estranguladora (strangler fig) crece alrededor de un árbol huésped. Cada paso es lo bastante pequeño como para probarlo, lanzarlo y revertirlo de forma independiente.
Secuencia por riesgo y valor, no por lo más fácil
La tentación es modernizar primero el módulo más fácil para generar impulso. Normalmente es mejor secuenciar según dónde el sistema legacy está causando más dolor: el módulo que más se rompe, o el que bloquea más elementos del roadmap, aunque sea el más difícil. Ahí es donde la modernización realmente se gana su presupuesto, y donde los stakeholders ven el valor lo bastante pronto como para seguir respaldando el proyecto.
Los cortes sin downtime son una práctica, no una esperanza
Cada paso de migración debería lanzarse detrás de un mecanismo que te permita enrutar el tráfico gradualmente y revertir al instante si algo falla: feature flags, releases canary, o una capa de proxy capaz de repartir un porcentaje del tráfico entre la implementación antigua y la nueva. Combina eso con pruebas de paridad exhaustivas entre lo viejo y lo nuevo antes del corte completo, y el downtime se convierte en algo que planificas evitar, no en algo que esperas que no ocurra.
El negocio sigue entregando mientras modernizas
La mayor ventaja práctica de la modernización incremental es que no exige congelar las funcionalidades. Como solo cambia una porción del sistema a la vez, el resto del equipo sigue entregando trabajo de producto en paralelo, lo cual también es lo que mantiene el proyecto financiado el tiempo suficiente para terminarlo.
La deuda técnica no se acumuló de golpe, y rara vez hace falta saldarla de golpe tampoco. Los equipos que logran retirar con éxito un sistema legacy son los que trataron la modernización como una disciplina de ingeniería continua, no como un proyecto heroico de una sola vez.