Servicio de modernización de aplicaciones Java

Cómo funciona el servicio, paso a paso

La modernización no empieza tocando código: empieza sabiendo qué hay. Y eso es un trabajo con alcance y precio cerrados.

La primera fase es siempre un análisis acotado. Inventario de dependencias, incompatibilidades detectadas, riesgos ordenados por impacto y un plan por fases con el esfuerzo estimado de cada una. Es un encargo independiente: el documento es vuestro aunque después no sigamos trabajando juntos, y sirve igual si decidís ejecutarlo con vuestro propio equipo.

A partir de ahí se ejecuta por incrementos que llegan a producción. Cada fase deja la aplicación funcionando y con sus pruebas, sin ramas de migración abiertas durante meses. El objetivo no es terminar antes: es que en cualquier momento se pueda parar sin dejar el sistema a medias.

La última fase es el traspaso. Documentación de qué se ha cambiado y por qué, decisiones registradas y una sesión con vuestro equipo. El servicio está bien hecho cuando podéis seguir sin mí.

Los casos en los que este servicio encaja

• Una aplicación en Java 8 que bloquea la actualización de librerías que necesitáis.
• Un sistema que funciona pero que nadie se atreve a desplegar fuera de una ventana pactada.
• Una migración de espacio de nombres pendiente, de javax a jakarta, con dependencias dudosas.
• Un proveedor original que ya no está y una documentación que es el propio código.
• Un salto de Hibernate o de Spring que se intentó, se complicó y se dejó a medias.
• Una necesidad de funcionalidad nueva sobre una base que no admite cambios con seguridad.

Si lo que buscáis es entender el problema antes de contratar nada, las páginas de retos explican qué implica cada uno: qué supone modernizar una aplicación legacy y qué arrastra subir la versión de Java.

Cómo se estima sin inventar una cifra

Una estimación dada antes de mirar el código no es una estimación: es un número que va a incomodar a las dos partes dentro de tres meses. Por eso el análisis existe como trabajo separado y con precio cerrado, en lugar de regalarse dentro de una propuesta comercial.

Lo que se estima después no es el proyecto entero, sino cada fase por separado. Una fase es una unidad que se despliega y deja la aplicación funcionando, así que su esfuerzo se acota con mucha más precisión que el de un objetivo lejano. Y si la tercera fase resulta más cara de lo previsto, eso se sabe cuando las dos primeras ya están entregadas.

Lo que más desvía las estimaciones en este tipo de trabajo no es la complejidad del código propio, sino las dependencias de terceros sin versión compatible y la cantidad de pruebas que hay que construir antes de poder tocar nada. Las dos cosas son medibles, y las dos salen del inventario inicial.