Java Legacy
Qué implica modernizar una aplicación Java legacy
Qué se mira antes de tocar una aplicación Java con años encima: inventario, incompatibilidades, riesgos y en qué orden conviene abordarlos.
Pedir diagnóstico gratuitoEl reto
El código legacy puede convertirse en un freno para evolucionar
Aplicaciones Java con años de evolución pueden combinar versiones antiguas, frameworks, servidores, configuraciones y componentes difíciles de mantener. La modernización debe adaptarse al contexto real de la aplicación y puede abordarse de forma progresiva.
La señal de alarma no suele ser la antigüedad del código, sino el miedo a desplegarlo. Cuando cada cambio exige un fin de semana y media plantilla pendiente, el problema ya no es la versión de Java: es que no hay pruebas suficientes para saber qué se rompe.
Qué se analiza
Qué se mira para saber por dónde empezar
- Análisis técnico de aplicaciones Legacy
- Identificación de deuda técnica
- Actualización progresiva de componentes
- Refactorización de código Java
- Evolución de arquitecturas existentes
- Modernización de aplicaciones JBoss y WildFly
- Reducción del riesgo técnico
- Preparación para nuevas versiones de Java
Tecnologías relacionadas
Dónde suele acumularse la deuda técnica
- Java
- Java EE
- Jakarta EE
- Spring
- Spring Boot
- Hibernate
- JBoss
- WildFly
- Maven
Qué convierte a una aplicación en legacy
No es la edad. Hay sistemas de quince años que se tocan sin miedo y aplicaciones de tres que ya nadie quiere abrir.
Lo que define a una aplicación legacy es la distancia entre hacer un cambio y saber si ese cambio está bien. Cuando esa distancia es grande, cada modificación se convierte en una apuesta y el equipo empieza a evitar zonas del código. A partir de ahí la degradación es rápida, porque lo que no se toca tampoco se entiende.
Eso tiene consecuencias que se notan fuera del equipo técnico: las estimaciones se inflan por precaución, los despliegues se agrupan en ventanas de fin de semana y las funcionalidades nuevas tardan cada vez más aunque el negocio no haya cambiado.
La buena noticia es que el problema casi nunca está repartido por igual. En la mayoría de sistemas hay un núcleo pequeño que concentra el riesgo, y acotarlo es la diferencia entre una modernización dirigida y una reescritura completa.
Del síntoma que se nota a la causa que hay que mirar
Los síntomas que llegan a negocio y lo que suele haber detrás en el código.
| Síntoma | Causa habitual | Qué se analiza |
|---|---|---|
| Cada despliegue necesita ventana y plan de vuelta atrás | Ausencia de pruebas automáticas y despliegue manual | Cobertura real sobre flujos críticos y pasos del despliegue |
| Nadie sabe qué hace un módulo | Rotación de equipo y documentación inexistente | Puntos de entrada, dependencias internas y uso real en producción |
| No se puede subir una librería | Versión de Java antigua y dependencias sin mantenimiento | Árbol de dependencias y fecha de última publicación de cada una |
| La aplicación va lenta según crecen los datos | Consultas N+1 y mapeos de persistencia heredados | SQL generado en los flujos más usados y modelo de entidades |
| Un cambio pequeño rompe algo lejano | Acoplamiento a través de la base de datos o de estado compartido | Fronteras reales entre módulos frente a las declaradas |
Qué recoge el inventario inicial
Es un trabajo acotado y su resultado es un documento. Sin esto, cualquier estimación es una apuesta.
- Versión de Java, framework, servidor de aplicaciones y sistema de construcción.
- Dependencias directas y transitivas, con su estado de mantenimiento.
- Cobertura de pruebas real, separando las que prueban comportamiento de las que solo ejecutan código.
- Puntos de integración: quién consume la aplicación y a quién consume ella.
- Zonas de código con más cambios recientes, que son las que de verdad duelen.
- Modelo de persistencia y consultas de los flujos más usados.
- Pasos manuales del despliegue y configuración que vive fuera del repositorio.
De ahí sale una matriz de riesgos ordenada por impacto y un plan por fases. Es el punto de partida del servicio de modernización de aplicaciones Java, y el documento es del cliente aunque después no se siga trabajando juntos.
Por dónde se empieza cuando casi no hay pruebas
Fijar el comportamiento actual
Se escriben pruebas que demuestren qué hace hoy la aplicación, aunque sean feas y de grano grueso sobre los flujos críticos. No prueban que el comportamiento sea correcto: prueban que no cambia. Esa distinción es la que hace que sirvan.
Aislar el núcleo que concentra el riesgo
El historial del repositorio dice qué ficheros se tocan una y otra vez. Ahí está el trabajo que rinde, no en el módulo que lleva cinco años sin cambios y funciona.
Levantar fronteras antes de mover nada
Poner una interfaz propia delante de lo que se va a sustituir permite cambiar la implementación sin tocar a quien la usa. Es lo que convierte una sustitución arriesgada en un cambio reversible.
Sustituir por partes, con la aplicación en producción
Cada pieza nueva convive con la antigua hasta que se demuestra que hace lo mismo. Es más lento sobre el papel y mucho más rápido en la práctica, porque no acumula riesgo.
Retirar el código muerto
Una vez sustituido, se borra. Dejar la implementación antigua por si acaso devuelve la aplicación al punto de partida, con dos caminos y ninguna certeza sobre cuál se usa.
Por qué reescribir desde cero casi nunca es la respuesta
Una reescritura completa parte de una premisa optimista: que se conoce todo lo que hace el sistema actual. En una aplicación legacy esa premisa es falsa por definición, porque si se conociera no sería legacy. Lo que se acaba reescribiendo es lo que alguien recuerda, y las reglas de negocio olvidadas aparecen meses después, en producción.
Además hay un coste que no suele aparecer en la estimación: durante la reescritura hay dos sistemas que mantener. El viejo sigue recibiendo correcciones, y cada una hay que replicarla en el nuevo o aceptar que ya no son equivalentes.
Eso no significa que reescribir sea siempre un error. A veces es la opción correcta, y entonces conviene decirlo con los motivos delante. Pero no es el punto de partida: el punto de partida es entender el sistema, y eso pasa por el inventario y por una actualización de la versión de Java que suele desbloquear buena parte del resto.
Preguntas frecuentes
Dudas frecuentes sobre modernizar una aplicación legacy
¿Por dónde se empieza si la aplicación casi no tiene pruebas?
Por construir las que demuestren que el comportamiento actual se mantiene, aunque sean pruebas de caracterización feas sobre los flujos críticos. Sin esa red no hay forma de distinguir un cambio correcto de uno que rompe algo que nadie estaba mirando.
¿Se puede modernizar sin parar la aplicación?
Es el planteamiento por defecto. Cada fase deja el sistema funcionando y desplegado, y las piezas nuevas conviven con las antiguas hasta que se demuestra que hacen lo mismo. Una modernización que exige parar es una reescritura con otro nombre.
¿Cuánto cuesta saber en qué estado está la aplicación?
El análisis es un trabajo con alcance cerrado y precio cerrado, independiente de lo que venga después. Su resultado es un documento con el inventario, los riesgos ordenados por impacto y un plan por fases con el esfuerzo estimado de cada una.
¿Y si el equipo que la construyó ya no está?
Es el caso más habitual y no impide el análisis. La información sale del código, del historial del repositorio y de lo que se observa en producción. Que nadie recuerde por qué se tomó una decisión no impide ver qué hace hoy el sistema.
¿Hace falta cambiar de arquitectura?
Casi nunca al principio. Lo que suele hacer falta es poder desplegar con confianza, y eso depende de las pruebas y de las fronteras internas, no del estilo arquitectónico. Cambiar de arquitectura sin resolver eso antes traslada el problema en lugar de arreglarlo.
¿Cuánto dura una modernización de este tipo?
Depende del inventario, y por eso el inventario va primero: para responder con datos en vez de con una cifra al aire. Cualquiera que dé un número antes de mirar el código y las dependencias se lo está inventando.
¿Tienes este reto?
¿Tenéis una aplicación que nadie quiere tocar?
Cuéntame qué hace, cuántos años tiene y qué es lo que más duele hoy. El análisis inicial sirve para responder con datos en vez de con suposiciones.
Pedir diagnóstico gratuitoLlamada de 30 minutos, sin coste. Respondo en menos de 48 horas.
En la llamada: versión de Java, framework, servidor y qué duele hoy. Si no puedo ayudarte, te lo digo. Qué incluye el diagnóstico