Desarrollo Java
Desarrollo backend a medida y evolutivos sobre aplicaciones empresariales Java.
Ver servicio →Modernización Java · Spring Boot · APIs REST
Moderniza tu aplicación de Java 8 a 17 o 21, sin parar producción
Para empresas con un backend en Java 8, javax o Spring antiguo que no puede dejar de dar servicio. Lo llevo a Jakarta EE y Spring Boot 3 por fases que llegan a producción, y también desarrollo servicios y APIs REST nuevos en Java. Trabajo desde Gran Canaria, en remoto para equipos de toda España.
Llamada de 30 minutos, sin coste. Respondo en menos de 48 horas.
- Java 8 → 17 / 21Jakarta EE y Spring Boot 3 incluidos
- El análisis es tuyoTe lo quedas aunque después no sigamos
- Cada fase se despliegaSin ramas de migración abiertas meses
El primer paso
Qué incluye el diagnóstico gratuito
Una llamada de 30 minutos para entender tu sistema antes de hablar de plazo o precio. Sin compromiso: si no puedo ayudarte, te lo digo.
- Qué me cuentas
- Tu stack y qué te está bloqueando, con tus palabras. Te respondo en menos de 48 horas con preguntas o una cita.
- En la llamada
- Versión de Java, framework, servidor, build y despliegue, y qué es lo que duele hoy.
- Al colgar
- Sabes si se puede hacer, por dónde empezaría y qué riesgos veo.
- Si seguimos
- Propuesta de análisis con alcance y precio cerrados. El documento es tuyo aunque después no sigamos.
Riesgos que conviene ver antes de estimar
javax.* → jakarta.*, respuesta en las preguntas frecuentesmarca el ritmoMecánico en el código propio. Lo que decide si son semanas o meses son las librerías de terceros sin versión compatible.
Hibernate 5 → 6, respuesta en las preguntas frecuentescambia resultadosEl motor de HQL se reescribió: una consulta que compila puede devolver otra cosa. Se compara el SQL generado antes y después.
JBoss EAP antiguo, respuesta en las preguntas frecuentesfija el techoLas versiones antiguas no soportan las LTS actuales de Java. El servidor decide hasta dónde se puede subir y en qué orden.
Pocas pruebas, respuesta en las preguntas frecuentesva primeroSin una red que demuestre que el comportamiento se mantiene, construirla es la primera fase, no un extra.
Ejemplos generales del ecosistema Java, no de un cliente.
Cuándo tiene sentido llamarme
¿Tu aplicación Java necesita evolucionar?
- El proveedor original ya no está. La documentación es el propio código y cada cambio da respeto porque no se sabe qué más toca.
- La versión de Java bloquea lo demás. Las librerías que necesitáis ya no publican versiones para Java 8.
- Cada despliegue es un evento. Fin de semana, plan de vuelta atrás y media plantilla pendiente: es un problema de arquitectura y de pruebas.
- Hace falta algo nuevo que conviva con lo que hay. Un servicio en Spring Boot o una API REST que no obligue a migrar todo de golpe.
Cómo trabajo
Entender el sistema, acotar el riesgo y entregar por fases
Llamada de diagnóstico, sin coste
30 minutos para entender qué hay y decirte si puedo ayudarte. Si la respuesta es no, te lo diré.
Análisis técnico con alcance cerrado
Inventario de dependencias, incompatibilidades detectadas, riesgos ordenados por impacto y un plan por fases con el esfuerzo estimado de cada una. Es un trabajo acotado y el documento es tuyo aunque después no sigamos juntos.
Ejecución por fases que se despliegan
Incrementos que llegan a producción. Cada fase deja la aplicación funcionando y con sus pruebas, sin ramas de migración que luego nadie se atreve a fusionar.
Traspaso al equipo
Documentación de qué se ha cambiado y por qué, decisiones registradas y una sesión con tu equipo. El objetivo es que podáis seguir sin mí.
Qué no hago
- No propongo reescribir desde cero por defecto. Rehacer un sistema que hoy funciona es la opción más cara y la de mayor riesgo. A veces es la correcta, y entonces lo diré con los motivos delante, pero no es el punto de partida.
- No migro a ciegas. Si no hay pruebas suficientes para demostrar que el comportamiento se mantiene, construirlas es la primera fase, no un extra opcional.
- No pongo fecha antes del análisis. Una estimación dada en la primera llamada no es una estimación: es una cifra que nos va a incomodar a los dos dentro de tres meses.
- No hago administración de sistemas. Si tu proyecto lo necesita, te lo digo en la primera llamada.
Modernización
Modernizar una aplicación Java que no puede pararse
Las aplicaciones empresariales no siempre pueden sustituirse desde cero. Estos son los cuatro caminos de modernización más habituales, cada uno con lo que implica y por dónde se empieza.
Migración Java EE
Java EE → Jakarta EE
Evolución de aplicaciones Java EE hacia Jakarta EE, analizando compatibilidad, dependencias y servidores.
Ver reto →Java LegacyJava Legacy
Qué se analiza antes de modernizar: inventario, deuda técnica, riesgos y por dónde empezar.
Ver reto →Spring BootMigración a Spring Boot
Evolución de aplicaciones Java hacia Spring Boot y arquitecturas backend más actuales.
Ver reto →Versiones JavaActualización de versiones Java
Análisis de compatibilidad y evolución hacia versiones más actuales de Java.
Ver reto →Servicios
Consultoría, desarrollo y migraciones Java
Cuatro formas de trabajar sobre un backend Java: construir lo que falta, modernizar lo que bloquea, o las dos cosas por fases.
Spring Boot
Desarrollo de servicios y APIs con Spring Boot, desde cero o sobre lo que ya existe.
Ver servicio →APIs REST
Diseño y desarrollo de APIs REST para integrar aplicaciones y servicios.
Ver servicio →Modernización Java
Consultoría de modernización: análisis, migración progresiva y refactorización por fases.
Ver servicio →Tecnologías
Stack de backend empresarial Java
No es una lista de logos: son las cuatro capas donde suelen aparecer los problemas cuando hay que evolucionar una aplicación Java con años encima.
La plataforma: Java, Java EE y Jakarta EE
- Java 8 / 11 / 17 / 21
- Java EE
- Jakarta EE
- Maven
- JDK / JVM
El salto de Java 8 a 17 o 21 rara vez se queda en cambiar el JDK: el sistema de módulos, la retirada de APIs que antes venían incluidas y el fin de soporte del servidor arrastran a las dependencias. En Jakarta EE 9 el cambio de javax.* a jakarta.* afecta a todas las librerías, no solo al código propio.
Spring y Spring Boot
- Spring Framework
- Spring Boot 2 / 3
- Spring MVC
- Spring Data
- Spring Security
La mayoría de aplicaciones no necesitan una migración completa de golpe: los servicios nuevos se levantan en Spring Boot y conviven con lo anterior mientras se decide qué se mueve y en qué orden. El salto de Spring Boot 2 a 3 arrastra el mismo cambio de espacio de nombres y exige una versión de Java con soporte.
Persistencia: JPA e Hibernate
- JPA
- Hibernate 5 / 6
- Spring Data JPA
- HQL / JPQL
- SQL
Es donde más suele doler una modernización. Mapeos que arrastran decisiones de hace diez años, consultas N+1 que no se notaron hasta que la tabla creció, LazyInitializationException en los bordes de la transacción, y el salto de Hibernate 5 a 6 con el cambio a jakarta.persistence y la reescritura del motor de HQL.
El trabajo consiste en revisar el modelo, aislar las consultas problemáticas y hacer el cambio comparando el SQL generado antes y después.
Servidores, integración y APIs
- JBoss / WildFly
- Tomcat
- REST
- JAX-RS
- JSON
El servidor de aplicaciones condiciona hasta dónde se puede subir de versión, y las integraciones existentes marcan qué se puede cambiar sin avisar a nadie. Antes de mover una pieza hay que saber quién la está consumiendo y con qué contrato.
Preguntas frecuentes
Lo que suelen preguntarme antes de empezar
¿Cuánto cuesta el diagnóstico?
Nada. Es una llamada de 30 minutos, sin coste y sin compromiso. Si después tiene sentido seguir, te envío una propuesta de análisis con alcance y precio cerrados antes de empezar, para que decidas con la cifra delante.
¿Y si después del análisis no seguimos?
El documento del análisis es tuyo: inventario de dependencias, incompatibilidades, riesgos ordenados por impacto y un plan por fases. Puedes ejecutarlo con tu equipo o con otro proveedor.
¿Trabajas con empresas de Canarias?
Sí. Trabajo desde Gran Canaria, en remoto, para empresas de Canarias y del resto de España. Con equipos de la península solo hay que tener en cuenta la hora de diferencia al cuadrar llamadas y ventanas de despliegue.
¿Se puede migrar de Java EE a Jakarta EE sin parar el desarrollo?
Normalmente sí. El cambio de javax.* a jakarta.* es mecánico en el código propio; lo que marca el ritmo son las dependencias de terceros que todavía no han publicado una versión compatible. Ese inventario es lo primero que se hace, porque es lo que decide si la migración dura semanas o meses.
¿Hay que cambiar de servidor de aplicaciones para subir de versión de Java?
Depende de la combinación concreta. Las versiones recientes de WildFly y Tomcat soportan las versiones LTS actuales de Java; las versiones antiguas de JBoss EAP no. Forma parte de la matriz de compatibilidad que sale del análisis inicial, junto con las dependencias y el build.
¿Qué pasa con Hibernate al pasar a jakarta.persistence?
Hibernate 6 es el que trae el cambio de espacio de nombres, y además reescribió el motor de consultas: HQL que antes funcionaba puede comportarse de otra manera. Se aborda comparando el SQL generado antes y después sobre las consultas críticas, no confiando en que compile.
¿Cuánto dura una migración de este tipo?
Depende del inventario, y por eso existe el análisis inicial: 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.
¿Hace falta ir a microservicios?
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.
¿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.
Contacto
Pide tu diagnóstico gratuito
Cuéntame el caso en unas líneas. La llamada dura 30 minutos, no tiene coste y no te compromete a nada.
Qué pasa después
- Te respondo en menos de 48 horas, con preguntas concretas o una propuesta de hora.
- Hablamos 30 minutos: versión de Java, framework, servidor y qué duele hoy. Si no puedo ayudarte, te lo digo.
- Si tiene sentido seguir, te envío una propuesta de análisis con alcance y precio cerrados. Sin compromiso de continuidad.