Modernizar sistemas legacy sin detener la operación

Casi toda empresa con más de diez años de operación tiene un sistema legacy en el corazón de su negocio. Funciona — esa es la parte buena. Pero cada nueva integración cuesta el doble de lo razonable, los desarrolladores que lo escribieron ya no están y cualquier cambio se discute durante semanas antes de tocar el código. El sistema sostiene la operación al mismo tiempo que la frena.

El dilema del legacy

La conversación típica termina en una de dos respuestas extremas. La primera: no tocar nada, porque cualquier cambio puede romper la operación. La segunda: reescribirlo todo desde cero. Ambas son trampas. La primera congela el negocio. La segunda casi siempre fracasa.

Por qué el big bang rewrite falla

Reescribir un sistema completo en paralelo a la operación suena ordenado en una presentación. En la práctica, el alcance crece, los requisitos se mueven, el sistema viejo sigue evolucionando mientras se construye el nuevo y, cuando llega el día del corte, las dos versiones ya no se parecen en nada. Los proyectos de reescritura total tienden a entregar tarde, sobre presupuesto o nunca.

“El sistema viejo es la documentación más actualizada del negocio. Si lo apagas antes de entenderlo, apagas reglas que nadie sabía que existían.”

El enfoque incremental: strangler fig

Tomamos prestada una imagen de Martin Fowler: el patrón strangler fig. Una higuera estranguladora rodea al árbol original, lo envuelve y, poco a poco, lo reemplaza desde afuera sin tirar la estructura. Aplicado a software:

• Se pone una capa nueva — un API gateway, un proxy, un módulo de enrutamiento — delante del sistema legacy.
• Se identifica un módulo bien delimitado (por ejemplo, facturación, o el módulo de inventario) y se reimplementa por separado.
• El gateway redirige las llamadas de ese módulo al sistema nuevo, dejando el resto intacto.
• Cuando el módulo nuevo está validado en producción, se elimina el viejo y se avanza con el siguiente.

El negocio nunca queda en un estado donde el sistema viejo y el nuevo no funcionen al mismo tiempo. Si algo sale mal, se revierte el routing y se sigue operando.

Pruebas de caracterización primero

Antes de tocar código legacy lo primero es escribir pruebas que describan cómo se comporta hoy — no cómo debería comportarse. Esas pruebas de caracterización son la red de seguridad: cualquier refactor que las rompa nos dice que cambiamos algo importante sin querer. Sin esa red, modernizar es apostar.

Migración de datos sin pérdida

Los datos son la parte más sensible. Trabajamos siempre con tres principios: respaldos verificados antes de cualquier paso destructivo, dual-write durante la transición (escribir simultáneamente al sistema viejo y al nuevo para validar consistencia) y un cutover en ventanas controladas con plan de rollback documentado. Nada se mueve a producción sin un ambiente espejo donde haya corrido completo.

Dónde encaja Claude Code

Entender código viejo es donde Claude Code marca la mayor diferencia. Una base de cien mil líneas en un lenguaje que ya nadie del equipo domina se puede mapear en horas: dependencias, flujos críticos, lugares donde el comportamiento es ambiguo. Lo que tradicionalmente requería semanas de arqueología técnica pasa a ser una conversación dirigida sobre el código real.

Esa misma velocidad acelera la escritura de pruebas de caracterización, la traducción de módulos a tecnologías modernas y la documentación que el sistema viejo nunca tuvo. El cuello de botella deja de ser técnico y vuelve a ser de negocio: qué módulo prioriza la modernización.

Resultado típico

Un proyecto de modernización bien planteado deja tres cosas: un sistema más rápido y barato de operar, una documentación viva del negocio que antes vivía solo en la cabeza de dos personas, y un equipo interno que entiende su propio software. La modernización deja de ser un evento traumático y se vuelve una capacidad continua.