Migración Liferay 7.2 a 7.4 (o a 2026.Q1): guía de upgrade paso a paso

El soporte de Liferay DXP 7.2 terminó el 3 de junio de 2026, según endoflife.ai [VERIFICAR en la Service Life Policy de liferay.com]. Si tu portal sigue ahí, cada vulnerabilidad nueva queda sin parche oficial, y lo que buscas en Google probablemente está en inglés: «liferay upgrade 7.2 to 7.4». Esta guía es la versión en español de ese procedimiento, escrita desde el lado de quien ejecuta el upgrade y no desde el folleto.

No repite la documentación oficial, que está en learn.liferay.com y conviene tener abierta en otra pestaña. Lo que agrega es el orden en que conviene hacer las cosas, dónde se rompen los portales reales y qué decisiones tomar antes de escribir una línea de código. Si llegaste aquí sin tener claro qué es la plataforma, empieza por qué es Liferay DXP y para qué sirve.

Ruta recomendada y duración típica

Para un portal en 7.2, la ruta recomendada es saltar directo a la quarterly release LTS más reciente (hoy, 2026.Q1) o, si tu equipo prefiere un destino más conocido, a 7.4. El upgrade de base de datos se hace en un solo salto desde 7.2 [VERIFICAR rutas soportadas en learn.liferay.com]. Lo que define la duración no es la base de datos: es la cantidad de código a medida.

Un portal de contenidos con pocos módulos propios y un tema simple es un proyecto acotado. Un portal transaccional con Service Builder, JSP sobrescritas, SSO e integraciones con sistemas internos es otro proyecto, aunque la base de datos pese lo mismo. Como no tiene sentido dar un promedio, la tabla muestra qué domina el plazo en cada caso:

Antes de empezar

Casi todos los upgrades que se complican lo hacen por algo que se podía saber antes de partir. Esta es la lista mínima, en este orden:

1. Inventario de módulos. En el repositorio, cada módulo, WAR, tema y fragment. En el servidor, lo que de verdad está desplegado: desde Gogo shell, lb lista los bundles y basta con filtrar los que no son de Liferay. Lo que aparece en el servidor y no en el repositorio es lo primero que hay que investigar.
2. Mapa de personalizaciones. JSP sobrescritas con módulos fragment, servicios sobrescritos, filtros de servlet, plantillas de contenido web en Velocity o FreeMarker y propiedades poco comunes en portal-ext.properties. Son los puntos que más se rompen y los que nadie recuerda.
3. Compatibility matrix de la versión de destino. Qué JDK, base de datos, servidor de aplicaciones y versión de Elasticsearch u OpenSearch están certificados. Es el documento que manda; si tu infraestructura no calza, se resuelve antes del upgrade, no durante.
4. Java. Un 7.2 suele correr en JDK 8. 7.4 trabaja con JDK 8 y 11, y las quarterly recientes agregan JDK 17 y 21 [VERIFICAR en la compatibility matrix de tu destino]. Cambiar de JDK es una tarea en sí misma: hazla en la fase de preparación.
5. Búsqueda. Anota la versión de Elasticsearch que usas y si está en modo remoto. Si producción corre con el Elasticsearch embebido (sidecar), el upgrade es el momento de corregirlo: ese modo es solo para desarrollo.
6. Limpieza de datos. Sitios de prueba, usuarios inactivos, miles de versiones de un mismo contenido web y datos de módulos que ya no usas alargan el upgrade sin aportar nada. Liferay trae utilidades de limpieza y de eliminación de datos en el panel de administración del servidor [VERIFICAR nombres exactos en tu versión].
7. Respaldo y copia. Una copia de la base de producción y del almacenamiento de documentos (la carpeta data/document_library o el store que uses), en un ambiente aislado donde puedas romper cosas sin consecuencias.

Upgrade de base de datos

El upgrade de base de datos convierte el esquema y los datos de 7.2 al formato de la versión de destino. Se hace con la herramienta de upgrade que trae el bundle, sobre una copia, con la indexación desactivada, y se repite hasta que corre limpio y sabes exactamente cuánto demora.

Si tienes suscripción DXP, parte por el Upgrade Planner del portal de clientes de Liferay: a partir de tu versión de origen y de destino arma una lista de tareas con los enlaces a la documentación de cada paso [VERIFICAR disponibilidad en help.liferay.com]. No reemplaza el inventario, pero ordena el trabajo.

Antes de correr la herramienta, desactiva la indexación para que el upgrade no intente escribir en Elasticsearch mientras convierte datos. Se hace con un archivo de configuración en osgi/configs:

# osgi/configs/com.liferay.portal.search.configuration.IndexStatusManagerConfiguration.config
indexReadOnly="true"

La herramienta vive en tools/portal-tools-db-upgrade-client dentro del bundle de destino y se configura con tres archivos: app-server.properties (dónde está el servidor y sus carpetas), portal-upgrade-database.properties (conexión JDBC a la copia) y portal-upgrade-ext.properties (las propiedades del portal que afectan al upgrade, como liferay.home y el tipo de almacenamiento de documentos). Con eso, la ejecución es:

cd $LIFERAY_HOME/tools/portal-tools-db-upgrade-client
./db_upgrade_client.sh -j "-Xmx8g -Dfile.encoding=UTF-8 -Duser.timezone=GMT" -l upgrade.log

Asigna memoria generosa, deja el log en un archivo y mide el tiempo. La primera corrida casi siempre falla en algún módulo propio o en un dato inconsistente; corriges, restauras la copia y vuelves a correr. Cuando termine sin errores, entra a Gogo shell y revisa con upgrade:list que no queden módulos con pasos pendientes. Para portales pequeños existe la opción de dejar que el upgrade corra al arrancar el servidor (upgrade.database.auto.run=true), pero en un portal corporativo la herramienta te da más control y un log más limpio.

El número que sale de este ensayo, el tiempo total con una copia del mismo tamaño que producción, es el dato con el que se negocia la ventana de corte.

Módulos, temas y fragments

Cada módulo propio se recompila contra la API de la versión de destino y se corrige lo que cambió. Los temas y las JSP sobrescritas son lo que más se rompe; los fragments se exportan, se revisan y se vuelven a importar.

En Liferay Workspace, el cambio de versión parte en gradle.properties, apuntando el producto a la versión de destino. Los módulos dependen de la API del producto sin fijar versión, así que al cambiar el producto todo se compila contra la nueva:

# gradle.properties (confirma la clave exacta del producto en la documentación de Liferay Workspace)
liferay.workspace.product=dxp-2026.q1.0-lts

dependencies {
    compileOnly group: "com.liferay.portal", name: "release.dxp.api"
}

Con eso compilas y aparecen los errores reales: clases eliminadas, paquetes que cambiaron, taglibs deprecadas. Para cada uno, la referencia es el documento de breaking changes de cada versión entre tu origen y tu destino. Saltar de 7.2 a 2026.Q1 obliga a leer todos los intermedios, aunque nunca los hayas instalado.

Tres puntos que conviene revisar a mano:

• JSP sobrescritas. Un módulo fragment declara en su bnd.bnd el bundle que modifica y su versión (Fragment-Host: com.liferay.login.web;bundle-version="..."). Esa versión cambia en el destino, y la JSP original probablemente también. Hay que comparar la JSP nueva con la tuya línea por línea; muchas veces la personalización ya se puede hacer por configuración o con un fragment de página.
• Temas. Un tema construido en 7.2 con el antiguo generador basado en Gulp debe recompilarse y revisar sus macros FreeMarker y su liferay-look-and-feel.xml. Antes de invertir en adaptarlo, evalúa reemplazarlo por un tema base con style books y una client extension de CSS: es la combinación que mejor sobrevive a los upgrades siguientes.
• Fragments. Expórtalos como ZIP desde el administrador de fragments, revisa los que usan configuración o editables complejos y vuelve a importarlos en el destino. Si los mantienes con el Fragments Toolkit, ojo: está deprecado desde 2024.Q1 [VERIFICAR en learn.liferay.com], así que el upgrade es el momento de cambiar de flujo.

Las plantillas de contenido web escritas en Velocity conviene pasarlas a FreeMarker antes del upgrade, en el ambiente de origen, donde todavía puedes comparar resultados.

Service Builder y Objects

Service Builder sigue soportado en 7.4 y en las quarterly releases: tus módulos se recompilan, se regenera la capa de servicio y, si cambiaste el modelo, se registran pasos de upgrade con UpgradeStepRegistrator. Pasar a Objects es una decisión opcional, que conviene para entidades simples y no para lógica transaccional compleja.

Objects, que llegó con 7.4, permite definir entidades con campos, relaciones, validaciones, permisos y acciones desde la interfaz, y Liferay genera su API REST sin código. Para un formulario con su propia tabla o un mantenedor de catálogo, es mucho menos código que mantener. Para un servicio con transacciones que tocan varias tablas o consultas SQL afinadas a mano, Service Builder sigue siendo la herramienta correcta.

Si decides migrar una entidad, el upgrade no es el mejor momento para hacerlo todo. Lo práctico es migrar primero con Service Builder tal cual, salir a producción y después mover entidad por entidad a Objects, copiando los datos con un script contra la API REST del Object.

Búsqueda: Elasticsearch u OpenSearch

Después del upgrade de base de datos, el índice de búsqueda se reconstruye desde cero. Antes de eso hay que confirmar qué versión de Elasticsearch, u OpenSearch en las quarterly más recientes, está certificada para tu destino, y medir cuánto tarda la reindexación con tu volumen real [VERIFICAR versiones en la compatibility matrix].

En 7.2 lo habitual es Elasticsearch 6.x o 7.x. El destino puede exigir otra versión, y actualizar el clúster de búsqueda es un proyecto paralelo con su propio equipo, si lo administra infraestructura. En producción, el conector debe estar en modo remoto; la configuración vive en osgi/configs [VERIFICAR nombre del archivo en tu versión de destino]:

# osgi/configs/com.liferay.portal.search.elasticsearch7.configuration.ElasticsearchConfiguration.config
productionModeEnabled=B"true"
networkHostAddresses=["http://es01:9200","http://es02:9200"]

La reindexación se lanza desde el panel de control, en la sección de búsqueda, con la acción de reindexar todos los índices. En un portal con cientos de miles de contenidos y documentos puede tardar horas; 7.4 agregó modos de reindexación que mantienen la búsqueda disponible mientras se reconstruye el índice [VERIFICAR modos disponibles en tu destino]. Mide el tiempo en el ensayo y decide si la reindexación entra en la ventana de corte o se hace con el portal abierto.

Pruebas y cutover

El corte es la ejecución de un guion que ya ensayaste. Si el día del corte hay que improvisar, faltó un ensayo.

Las pruebas previas cubren tres frentes: regresión funcional sobre los flujos críticos (login, formularios, búsqueda, publicación de contenidos, integraciones), carga con datos anonimizados en un ambiente equivalente a producción, y comparación de rendimiento y errores del log contra el portal en 7.2. Con eso aprobado, el guion del corte es este:

1. Anunciar y congelar la publicación de contenidos desde una hora acordada.
2. Respaldar la base de producción y el almacenamiento de documentos.
3. Correr el upgrade de base de datos con la configuración probada y la indexación en solo lectura.
4. Arrancar el portal de destino, revisar el log y confirmar con upgrade:list que no quedan pasos pendientes.
5. Quitar indexReadOnly y reindexar, o dejar la reindexación para después si así se acordó.
6. Pruebas de humo con una lista cerrada y un responsable por cada ítem.
7. Cambiar el balanceador o el DNS hacia el nuevo ambiente y monitorear errores y tiempos de respuesta.
8. Mantener intactos el ambiente y la base anteriores hasta que el negocio firme la salida. La regla de vuelta atrás se define antes: si a tal hora no se cumplen tales pruebas, se vuelve.

Si vienes de 7.0 (liferay upgrade 7.0 to 7.4)

El upgrade de base de datos desde 7.0 puede hacerse en un solo salto a 7.4 [VERIFICAR en learn.liferay.com], pero la distancia de código es mucho mayor que desde 7.2. Los módulos de 7.0 se compilaron contra APIs que cambiaron varias veces, los temas suelen venir del generador más antiguo y 7.0 trabajaba con Elasticsearch 2.x [VERIFICAR], así que el clúster de búsqueda casi seguro hay que reemplazarlo. Las estructuras de contenido web pasaron al Data Engine en 7.3, y el upgrade las convierte; revisa después las plantillas que dependían de detalles del formato antiguo. Presupuesta más tiempo de recompilación y regresión que para un 7.2.

Si vienes de 7.1 (liferay upgrade 7.1 to 7.4)

7.1 introdujo las páginas de contenido y los fragments, así que es probable que tengas fragments de la primera generación: revísalos uno por uno, porque el editor y las opciones de configuración cambiaron bastante hasta 7.4. El resto del trabajo se parece al de 7.2, con más breaking changes que leer. La demanda es real: en la SERP de «migración liferay 7.4» aparece una licitación del Gobierno Vasco para migrar DXP 7.1 a 7.4 y mantenerlo (informe de keywords 03, 27-10-2026).

Si vienes de 7.3 (upgrade liferay 7.3 to 7.4)

Es el salto más corto. 7.3 ya tiene master pages, style books, el Data Engine para estructuras y buena parte de las APIs de 7.4, así que el trabajo es sobre todo recompilar, leer los breaking changes y probar. Su soporte dura hasta el 12 de octubre de 2027 según endoflife.ai [VERIFICAR en liferay.com]: si estás aquí, tienes tiempo para hacerlo bien y conviene apuntar directo a una quarterly LTS.

Errores comunes

1. Correr el upgrade con la indexación activa. El proceso intenta escribir en Elasticsearch mientras convierte datos y se vuelve lento o falla a medias.
2. Ensayar con una base pequeña. El tiempo medido con una copia recortada no sirve para dimensionar la ventana de corte. El ensayo se hace con una copia del tamaño de producción.
3. No limpiar antes. Miles de versiones de contenido y sitios de prueba alargan el upgrade y la reindexación sin aportar nada.
4. Olvidar los módulos fragment de JSP. Compilan, se despliegan y quedan inactivos porque la versión del Fragment-Host ya no existe. El síntoma es que la personalización «desaparece» sin error visible.
5. Mantener el Elasticsearch embebido en producción. Funciona en desarrollo y falla con carga real.
6. Copiar portal-ext.properties completo. Varias propiedades se movieron a configuración OSGi o cambiaron de nombre entre versiones. Se revisan una por una contra la documentación del destino.
7. Olvidar el almacenamiento de documentos. La base migra, pero si la carpeta de documentos o el store no apunta al mismo contenido, aparecen imágenes y archivos rotos en todo el portal.
8. Elegir una quarterly no LTS sin plan. Su soporte es corto [VERIFICAR duración en liferay.com]; si no vas a actualizar cada trimestre, apunta a la LTS.

¿Tu versión todavía tiene soporte?

Resumen al 28-10-2026, con fechas de endoflife.ai que hay que confirmar en liferay.com: 7.0, 7.1 y 7.2 ya no tienen soporte; 2025.Q4 lo pierde el 25 de noviembre de 2026; 7.3, el 12 de octubre de 2027 [VERIFICAR las tres fechas en liferay.com]. La tabla completa, con soporte premium y limitado y qué hacer en cada caso, está en Liferay end of life: fechas de fin de soporte por versión. Si tu duda es cómo se numeran las quarterly y cuál elegir como destino, está explicado en Liferay quarterly releases: qué son y cuál es LTS.

Preguntas frecuentes

¿Se puede saltar de 7.0 o 7.1 directo a 7.4?

Sí en la base de datos: la herramienta de upgrade admite partir desde 7.0 o 7.1 hacia 7.4 en un solo salto [VERIFICAR rutas soportadas en learn.liferay.com]. El código es otra historia: los módulos deben recompilarse contra la API de 7.4 y corregirse según los breaking changes acumulados de todas las versiones intermedias, que desde 7.0 son muchos.

¿Qué versión de Java requiere Liferay 7.4?

Liferay 7.4 está certificado para JDK 8 y JDK 11; las quarterly releases recientes agregan JDK 17 y 21 [VERIFICAR en la compatibility matrix de la versión exacta]. Si tu 7.2 corre en JDK 8, actualizar a JDK 11 o superior durante la preparación evita sumar un problema más el día del corte.

¿Qué pasa con Service Builder en 7.4?

Sigue soportado. Tus módulos se recompilan, se regenera la capa de servicio con buildService y, si cambiaste el modelo, registras pasos de upgrade con UpgradeStepRegistrator. Objects es una alternativa opcional para entidades simples, con API REST generada; no hace falta migrar todo a Objects para subir de versión.

¿Conviene ir a 7.4 o directo a una quarterly release?

Si vas a invertir en un upgrade, conviene apuntar a la quarterly LTS más reciente (hoy, 2026.Q1): tiene soporte extendido y evita un segundo salto a corto plazo. 7.4 solo tiene sentido si una dependencia tuya, como un JDK o un conector, todavía no está certificada para las quarterly [VERIFICAR en la compatibility matrix].

Cuándo pedir ayuda

Si tu portal tiene pocos módulos propios y tu equipo conoce Liferay, esta guía y la documentación oficial alcanzan para hacerlo en casa. Conviene pedir ayuda cuando el inventario muestra Service Builder con lógica crítica, JSP sobrescritas que nadie documentó, integraciones con SSO o sistemas internos, o una ventana de corte que no puede pasarse de unas pocas horas.

Para esos casos ofrecemos el servicio de migración de Liferay DXP: una evaluación técnica de precio cerrado que inventaría tu portal, ensaya el upgrade de base de datos sobre una copia y termina con plazo y precio cerrado del proyecto. Si prefieres conversarlo primero, pide un diagnóstico gratis: 30 minutos por videollamada con uno de los socios, sin costo y sin compromiso.