El escenario
Un sistema transaccional del Estado chileno, crítico para la operación diaria de miles de funcionarios, corriendo sobre JBoss 5 con Java 7. Doce años de parches, configuraciones manuales en servidores físicos y un equipo reducido que apenas daba abasto con el mantenimiento correctivo.
El problema no era solo técnico: cualquier falla impactaba directamente a ciudadanos. Y la plataforma ya no recibía parches de seguridad del vendor.
El diagnóstico
Entramos con un sprint de diagnóstico de 2 semanas. Encontramos esto:
- 320 archivos Java sin comentarios y cero documentación arquitectónica
- Lógica de negocio mezclada con SQL directamente en servlets — ni siquiera había una capa de servicios
- Dependencias imposibles: librerías que ya no existían en ningún repositorio público
- Tiempo de startup del servidor: 22 minutos — debido a configuraciones duplicadas y recursos mal asignados
- Sin tests automatizados. Cero. El único "testing" era el grito del usuario cuando algo fallaba
Lección temprana: La tentación de reescribir todo desde cero era fuerte. Pero en el sector público, con presupuestos acotados y procesos de licitación, eso significaba 2+ años. Optamos por cirugía, no trasplante.
La estrategia: Strangler Fig + reverse engineering con IA
Paso 1 — Mapeo automatizado del ecosistema
Usamos modelos de lenguaje (Claude + GPT-4) para procesar en paralelo los 320 archivos fuente y generar un mapa de dependencias. En 3 días teníamos un grafo completo de: flujos de datos, entidades de negocio, endpoints y dependencias entre módulos. Algo que manualmente habría tomado 6 semanas.
Paso 2 — Extraer el core sin tocar el perímetro
Identificamos el 20% de la funcionalidad que generaba el 80% del tráfico. Ese 20% se convirtió en el primer módulo independiente. Usamos API gateway con patrón Strangler Fig: las nuevas rutas apuntaban al módulo modernizado, las viejas seguían en JBoss. Transparente para el usuario.
Paso 3 — Contenerización progresiva
Mientras el módulo core se pasaba a Java 17 + Spring Boot, empaquetamos el JBoss legacy en un contenedor Docker con el mínimo necesario. No era la solución ideal, pero quitó la dependencia del servidor físico y nos permitió hacer rolling deployments sin cortar servicio.
Resultados
- Migración sin downtime: 0 interrupciones de servicio durante toda la transición (6 meses)
- Tiempo de startup reducido de 22 min a 45 segundos en el módulo modernizado
- 3 módulos legacy migrados a contenedores, con plan de migración para los 7 restantes
- Deuda técnica documentada por primera vez: backlog priorizado con 42 items críticos y 89 mejoras
- Equipo interno capacitado en el nuevo stack — no quedaron dependientes de nosotros
Dato concreto: La reducción de tiempo de startup sonaba a mejora cosmética, pero significó que los deploys que antes requerían ventana de 1 hora los sábados pasaron a hacerse en cualquier momento. El equipo recuperó control de su propio software.
Lo que aprendimos
- No rewrite, sí refactor. Reescribir es sexy en una presentación, pero caro en la realidad. El patrón Strangler Fig existió antes de la IA y sigue siendo la mejor estrategia para sistemas legacy críticos.
- La IA acelera el reverse engineering, pero no reemplaza el criterio. El grafo de dependencias lo generó una máquina; decidir qué cortar y en qué orden fue trabajo de ingeniería.
- La contenedorización del legacy es un paso intermedio válido. No es el destino, pero te permite desacoplar infraestructura de código. Una vez que el legacy está en Docker, migrar a cloud es trivial.
- En sector público, la continuidad del servicio no es negociable. Cada decisión técnica tiene que responder a esa prioridad. Si el patrón Strangler Fig no existiera, habría que inventarlo.