Tu Liferay ya no tiene soporte. Lo llevamos a una versión que sí.

Para empresas y administraciones con un portal o una intranet en una versión de Liferay que ya no recibe parches. También para quien lleva varias versiones de retraso y no sabe por dónde empezar.

El portal funciona, pero la versión ya no tiene soporte. No llegan parches de seguridad. Los desarrollos a medida los hizo un proveedor que ya no está y nadie sabe qué se rompe si se actualiza. Cada año que pasa, el salto es más grande y da más miedo.

Antes de tocar producción, ensayamos la migración con una copia de tus datos. Así sabes qué se rompe y cuánto trabajo hay antes de decidir. Después adaptamos los desarrollos, migramos los contenidos y pasamos a producción con una vuelta atrás preparada. El portal queda en una versión con soporte y en condiciones de seguir actualizándose.

Primero revisamos el portal y te entregamos los riesgos por orden de prioridad, con una propuesta de alcance cerrado. Después ensayamos la migración en un entorno aparte, sin tocar producción. Tu equipo prueba el portal migrado en un entorno de pruebas y aprueba el paso a producción. Trabajamos con entregas cortas que se pueden ver.

Hemos llevado un portal desde Liferay 6.2 hasta la versión 7.4 a lo largo de más de diez actualizaciones, y otro desde Liferay 7.4 hasta Liferay DXP 2026.Q2.1 con sus desarrollos reescritos. Están en los casos publicados.

La migración se ensaya en contenedores Docker con una copia de la base de datos y del repositorio de documentos. El proceso de actualización de Liferay se ejecuta ahí las veces que haga falta, hasta que termina limpio y el portal arranca con los datos reales.

Los desarrollos antiguos se revisan uno a uno. Cuando compensa, los despliegues WAR pasan a client extensions en React y las entidades de Service Builder a Liferay Objects, que es el modelo que recomienda Liferay DXP. Así la siguiente actualización cuesta menos que esta.

Con la versión suele cambiar lo que hay debajo: la versión de Java, el motor de búsqueda Elasticsearch y la base de datos. Lo actualizamos en el mismo proyecto y dejamos los despliegues automatizados con CI/CD en GitLab, por entornos y con vuelta atrás.

Ningún cambio llega a producción sin pasar por cuatro agentes de revisión (seguridad, accesibilidad, calidad y funcionalidad) y por una persona. La puerta de calidad es la de todos nuestros proyectos: 80 % de cobertura mínima de tests y 0 incidencias en SonarQube.