Migrar entre versiones mayores de Liferay DXP no es simplemente actualizar una dependencia en el build.gradle. Cada version introdujo cambios arquitectonicos significativos que afectan desde la capa de persistencia hasta el frontend, pasando por el modelo de despliegue y la infraestructura de temas. He participado en migraciones desde 7.1 hasta 7.4 en proyectos de distintas escalas, y la experiencia me ha ensenado que entender el contexto de cada version es tan importante como conocer los pasos tecnicos.
Liferay 7.1 fue la version que consolido la transicion de Liferay 6.x al modelo OSGi. Sus caracteristicas definitorias:
Temas con Velocity y FreeMarker: los temas se construian con plantillas FreeMarker (o aun Velocity en proyectos legacy migrados de 6.x). El Theme SDK generaba la estructura de archivos y las plantillas base. La personalizacion requeria editar archivos .ftl y entender el sistema de template context variables de Liferay.
Portlets JSP dominantes: aunque la plataforma ya soportaba modulos OSGi, la mayoria de portlets custom se escribian con JSP como tecnologia de vista. Los MVCPortlets con JSP eran el patron estandar. Los taglibs de Liferay (<liferay-ui:search-container>, <aui:form>) eran omnipresentes.
AlloyUI: la libreria JavaScript propia de Liferay, basada en YUI3 de Yahoo. AlloyUI proporcionaba componentes de UI, manejo de eventos y utilidades DOM. Todo el JavaScript custom en 7.1 interactuaba con AlloyUI de alguna forma.
Service Builder como unica opcion: para entidades personalizadas con persistencia, Service Builder era la herramienta. No existian alternativas dentro de la plataforma.
Personalizacion limitada: la personalizacion de contenido se basaba en User Segments simples. No habia un motor de personalizacion robusto ni experiencias A/B.
La version 7.2 marco un punto de inflexion en la estrategia frontend de Liferay:
JS Portlets: la introduccion de portlets basados en JavaScript puro. Podias escribir un portlet con React, Angular o Vue, empaquetarlo como un modulo OSGi, y desplegarlo en Liferay. Esto abrio la puerta a que equipos frontend trabajaran con tecnologias modernas.
SPA Navigation mejorado: Liferay 7.2 mejoro significativamente la navegacion SPA (Single Page Application) integrada. Las transiciones entre paginas eran mas fluidas y el sistema de carga parcial de portlets se optimizo.
Segment-based Personalization: se introdujo un motor de segmentacion de usuarios mas sofisticado. Podias definir segmentos basados en multiples criterios (rol, organizacion, datos custom) y personalizar la experiencia de cada pagina segun el segmento.
Content Sets: precursores de las Collections de 7.3/7.4. Permitieron agrupar contenido web y mostrarlo de forma dinamica basada en criterios.
Deprecacion progresiva de AlloyUI: Liferay comenzo a mover componentes internos de AlloyUI a Metal.js (su framework JavaScript propio basado en incrementalDOM). Esto genero una etapa de transicion donde coexistian ambas librerias.
La version 7.3 introdujo cambios fundamentales en como se construyen las paginas:
Content Pages y Page Builder: el editor visual de paginas basado en drag-and-drop se convirtio en la forma principal de construir paginas. Los Widget Pages pasaron a segundo plano.
Master Pages: plantillas maestras que definen la estructura comun de las paginas (header, footer, layout), asegurando consistencia visual sin modificar el tema.
Fragmentos: piezas de UI reutilizables que se arrastran a las Content Pages. Cada fragmento tiene HTML, CSS, JavaScript y configuracion. Reemplazaron muchos casos de uso donde antes necesitabas un portlet custom.
App Builder: herramienta low-code para crear aplicaciones de datos sin codigo. Fue el precursor directo de Objects en 7.4.
Collections y Collection Display: evolucion de Content Sets con filtros avanzados y templates personalizables.
La version 7.4, especialmente con sus actualizaciones trimestrales, represento el salto mas grande:
Client Extensions (CEs): el cambio de paradigma mas significativo. Las CEs permiten extender Liferay sin desplegar codigo dentro de la plataforma. El objetivo: desacoplar las personalizaciones del core.
Objects: permite definir entidades de datos, relaciones, validaciones y APIs REST sin escribir Java. Para CRUD simple, elimina la necesidad de Service Builder.
StyleBooks: sistema de design tokens para controlar la apariencia visual desde un panel centralizado sin tocar CSS.
Remote Applications: mecanismo para registrar aplicaciones externas como widgets disponibles en el Page Builder.
Headless APIs mejoradas: APIs REST auto-generadas para Objects, GraphQL mejorado y Batch Engine para operaciones masivas.
Cada salto de version introduce cambios que rompen compatibilidad. Los mas impactantes que he encontrado en migraciones reales:
7.1 a 7.2:
MVCPortlet con liferay-portlet.xml necesitan migrar a anotaciones OSGi @Component.UserLocalService y GroupLocalService cambiaron firmas de metodos.7.2 a 7.3:
7.3 a 7.4:
@Reference es ahora el mecanismo recomendado de inyeccion de dependencias OSGi, reemplazando a @BeanReference. Service Tracker sigue funcionando pero DS es el estandar.He visto ambos enfoques en proyectos reales, y cada uno tiene su contexto:
Migracion incremental (version por version): cada salto es mas pequeno y los problemas son mas faciles de diagnosticar, pero multiplicas el esfuerzo de testing.
Migracion directa (7.1 a 7.4): Liferay lo soporta oficialmente. Solo haces un ciclo de testing, pero diagnosticar fallos es mas dificil con mas variables en juego.
Mi recomendacion: la migracion directa es viable pero requiere analisis previo exhaustivo. Siempre ejecuto el upgrade en un ambiente de prueba primero y documento cada problema antes de tocar produccion.
El proceso de upgrade de la base de datos sigue un patron consistente entre versiones:
Backup completo: base de datos, Document Library (filesystem o S3), y configuracion de portal. Esto no es negociable.
Ejecutar la herramienta de upgrade: ubicada en tools/portal-tools-db-upgrade-client/ del bundle de Liferay 7.4. Configuras las propiedades de conexion a base de datos y del portal, y ejecutas db_upgrade.sh. La herramienta procesa todos los upgrade steps secuencialmente.
Verificacion post-upgrade: revisar el log de upgrade buscando errores. Los warnings son normales; los errores requieren atencion.
Limpieza: ejecutar los procesos de limpieza de datos deprecados que Liferay recomienda para cada version.
La migracion frontend es frecuentemente la parte mas costosa porque implica cambios en la experiencia de usuario visible:
AlloyUI a JavaScript moderno: si tienes codigo JavaScript que usa AUI(), Liferay.fire() con AlloyUI, o componentes AUI, necesitas reescribirlo. No hay herramienta de migracion automatica. En mi experiencia, este es el trabajo mas intensivo en migraciones desde 7.1 o 7.2.
JSP Portlets a Fragmentos o Client Extensions: los portlets JSP que renderizan UI simple (formularios, listas, tarjetas) pueden reemplazarse con fragmentos. Los que tienen logica compleja pueden convertirse en Client Extensions con React o Angular.
Temas FreeMarker a temas con StyleBooks: los temas de 7.4 deben exponer variables CSS que los StyleBooks puedan controlar. Un tema migrado de 7.1 funciona en 7.4, pero no aprovecha StyleBooks hasta que se adapta su estructura.
Basado en mi experiencia con migraciones reales, estos son los puntos mas importantes:
No saltes el analisis de compatibilidad: antes de migrar, ejecuta el Upgrade Planner de Liferay (disponible en LDS) que analiza tu codigo y reporta APIs deprecadas y cambios necesarios.
Prioriza el testing automatizado: si no tienes tests, escribelos antes de migrar. Necesitas una forma de verificar que la funcionalidad critica sigue funcionando despues del upgrade.
Planifica la migracion frontend por separado: el upgrade de base de datos y backend es un proyecto; la modernizacion del frontend es otro. Pueden hacerse en fases distintas.
El futuro es Cloud y CEs: Liferay esta moviendo su estrategia hacia Liferay Cloud (PaaS con actualizaciones automaticas) y Client Extensions como modelo de personalizacion. Si estas en 7.1 o 7.2, migrar a 7.4 no es solo una actualizacion tecnica: es posicionarte para la siguiente decada de la plataforma.
Las migraciones de Liferay son proyectos complejos que requieren planificacion, conocimiento profundo de la plataforma y paciencia para resolver los problemas inevitables que surgen en el camino. Pero el resultado es una plataforma mas moderna, con mejor rendimiento y un modelo de desarrollo significativamente mas productivo.