Spring Boot
Evolución de aplicaciones Java existentes hacia Spring Boot para facilitar el desarrollo de servicios, APIs y nuevas funcionalidades backend.
Pedir diagnóstico gratuitoEl reto
La evolución hacia Spring Boot puede abordarse de distintas formas dependiendo de la arquitectura existente, las dependencias, el servidor de aplicaciones y las necesidades del proyecto. Antes de decidir una estrategia conviene analizar el punto de partida.
En bastantes casos la opción razonable no es migrar el monolito entero, sino levantar los servicios nuevos en Spring Boot y desplazar funcionalidad poco a poco, manteniendo las dos partes en producción mientras dure la transición.
Qué se analiza
Tecnologías relacionadas
Conviene separarlas desde el principio, porque tienen riesgos y calendarios muy diferentes.
Una es llevar una aplicación Java EE o Spring clásico hacia Spring Boot. Ahí el trabajo es de arquitectura: cambia cómo arranca la aplicación, cómo se configura y cómo se empaqueta. El código de negocio se toca poco.
La otra es subir de Spring Boot 2 a Spring Boot 3. Ahí el trabajo es de compatibilidad: Spring Boot 3 exige Java 17 como mínimo y arrastra el cambio de javax a jakarta en toda la aplicación. Se parece mucho más a una migración de Jakarta EE que a un cambio de framework.
La confusión sale cara cuando se planifican como si fueran una sola. Lo habitual es que una organización necesite las dos, pero en orden: primero llegar a Spring Boot 2 con la versión de Java adecuada, y después dar el salto a 3.
Esta tabla decide el orden del trabajo: la versión de Java es un requisito previo, no una consecuencia.
| Spring Boot | Spring Framework | Java mínimo | Espacio de nombres |
|---|---|---|---|
| Spring Boot 2.5 y 2.6 | 5.3 | Java 8 | javax |
| Spring Boot 2.7 | 5.3 | Java 8 | javax |
| Spring Boot 3.0 a 3.2 | 6.0 y 6.1 | Java 17 | jakarta |
| Spring Boot 3.3 y posteriores | 6.1 y posteriores | Java 17 | jakarta |
Spring Boot 2.7 es la última puerta antes del salto: es el punto desde el que conviene migrar a 3, porque es donde las rutas de actualización están mejor documentadas y donde aparecen los avisos de lo que va a romperse.
Más allá del renombrado de paquetes, hay cambios que no dan error de compilación y fallan en ejecución.
El más silencioso es el de la estrategia de nombres de Hibernate: si el esquema de base de datos no coincide con lo que genera la versión nueva, la aplicación arranca y falla al consultar.
ClassNotFoundException: javax.servlet.FilterCausa: Queda una dependencia en la variante javax dentro de un proyecto que ya corre sobre Spring 6.
Qué se hace: Buscar la transitiva culpable con mvn dependency:tree y sustituirla por su versión jakarta o excluirla si ya no hace falta.
Cannot resolve configuration property spring.redis.hostCausa: Una propiedad renombrada en Spring Boot 3. La antigua no da error: simplemente deja de aplicarse, y la aplicación arranca con el valor por defecto.
Qué se hace: Pasar por el analizador de propiedades antes de migrar y revisar el fichero de configuración entero, no solo lo que falle al arrancar.
Table not found tras migrar a Hibernate 6Causa: Hibernate 6 cambió cómo deriva los nombres de tablas y columnas a partir de los nombres de las entidades.
Qué se hace: Fijar de forma explícita la estrategia de nombres, o declarar el nombre real con @Table y @Column en las entidades afectadas. Es preferible lo segundo: deja de depender de una convención.
No qualifying bean of type WebSecurityConfigurerAdapterCausa: La clase desapareció en Spring Security 6 y la configuración pasa a declararse mediante beans.
Qué se hace: Reescribir la configuración de seguridad como cadena de filtros declarada por beans. Conviene hacerlo antes del salto, estando todavía en Spring Boot 2.7, donde ya está soportado.
Dentro de la misma generación, sin cambiar de espacio de nombres ni de versión de Java. Es un paso barato que deja la aplicación en el mejor sitio posible para saltar.
La configuración de Spring Security por beans y la sustitución de APIs marcadas como obsoletas se pueden hacer todavía en la versión 2.7. Cuanto menos quede para el salto, más fácil es aislar la causa cuando algo falle.
Es requisito de Spring Boot 3, así que se resuelve antes y por separado. Mezclar el cambio de JDK con el de framework hace imposible saber cuál de los dos provocó cada fallo.
Renombrado de paquetes, actualización de dependencias y revisión de propiedades, en un bloque acotado y con las pruebas verdes al terminar.
Comparar las consultas que produce Hibernate 6 con las de la versión anterior sobre los flujos críticos. Que compile y arranque no demuestra que consulte lo mismo.
No toda aplicación necesita moverse entera. En muchos casos lo sensato es levantar los servicios nuevos en Spring Boot y dejar que convivan con la aplicación existente, decidiendo después qué se mueve y en qué orden.
Eso exige que las fronteras estén claras: quién consume qué, con qué contrato y qué pasa si una de las dos partes cambia. Es el mismo trabajo de límites que hay detrás de un diseño de APIs REST mantenible, y sin él la convivencia se convierte en dos sistemas acoplados por la base de datos.
La ventaja es que cada servicio nuevo entrega valor desde el primer día y la migración deja de ser un proyecto con fecha única. La alternativa, reescribir de golpe, es la opción más cara y la de mayor riesgo, y solo compensa cuando el sistema actual ya no se puede sostener. Cuando ese es el caso, el punto de partida es el análisis previo de la aplicación legacy.
Preguntas frecuentes
No. Java 17 es el mínimo obligatorio de Spring Boot 3, no una recomendación. Por eso la subida de versión de Java se aborda antes y como trabajo independiente.
El artefacto sí, porque el espacio de nombres es uno u otro. La aplicación entendida como sistema no: es frecuente levantar servicios nuevos en Spring Boot y dejar que convivan con lo anterior mientras se decide qué se mueve.
El renombrado es cuestión de horas con las herramientas adecuadas. Lo que consume el tiempo son las dependencias sin versión compatible, las propiedades renombradas que fallan en silencio y la revisión de Hibernate 6. El inventario previo es el que da la cifra.
No. Un monolito modular, bien probado y desplegable es una arquitectura legítima, y para muchas aplicaciones empresariales es la correcta. Trocear un sistema que nadie entiende del todo suele multiplicar el problema en lugar de resolverlo.
El camino habitual es reconstruir el arranque y la configuración sobre Spring Boot manteniendo el código de negocio, que suele necesitar pocos cambios. Lo que más trabajo da es la configuración XML heredada y las integraciones que dependían del servidor de aplicaciones.
Sí, si cada fase se despliega. Llegar a la versión 2.7, adelantar lo compatible y subir Java son pasos que llegan a producción por separado. El salto final queda así acotado a un cambio pequeño y reversible.
¿Tienes este reto?
Dime la versión actual, la de Java y qué dependencias no se pueden tocar. Con eso se ve si el camino es un salto directo o dos fases.
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