Liferay DXP Migration: Der praxisnahe Leitfaden für ein sicheres Upgrade (inkl. CE zu DXP & 2026.Q1 LTS)

Eine Liferay DXP-Migration ist selten „nur ein Update“. In der Praxis ist sie ein strukturiertes Modernisierungsvorhaben: Datenbank-Upgrade, Anpassung von Custom Code, Überprüfung der Infrastruktur (Java/App-Server), Regressionstests, Cutover-Planung - und danach ein Update-Regime, das dauerhaft funktioniert.

Warum dieser Leitfaden? Viele Artikel erklären den Prozess grob in Phasen. Das ist hilfreich, aber oft fehlen die entscheidenden Details, die in echten Projekten über Kosten, Risiko und Zeitplan entscheiden (z. B. Version-/LTS-Strategie, Jakarta-Umstieg, Client Extensions als Upgrade-Hebel, Testdesign, Rollback). Genau diese Lücken schließen wir hier, praxisnah und umsetzbar.

Spätestens seit 2026 ist „einfach bei CE bleiben“ für viele Organisationen keine nachhaltige Option mehr: Liferay stellt mit dem 2026er Release Model auf eine einheitliche Plattform um, bei der Fähigkeiten über einen Activation Key freigeschaltet werden (statt separater CE-/DXP-Distributionen).

Konsequenz für Ihre Migrationsplanung:

• Upgrade-Entscheidungen sind stärker mit Betriebsmodell, Support und Security verknüpft.
• Der Sprung auf 2026.Q1 LTS ist für viele ein sinnvoller strategischer Fixpunkt (Modernisierung + planbarer Supportpfad).

Wenn Sie CE einsetzen, lesen Sie ergänzend unseren Beitrag "Liferay  CE endet"

Liferay liefert quartalsweise Releases; Q1 ist jedes Jahr das LTS-Release (Long-Term Support) mit deutlich längerer Supportlaufzeit als Q2–Q4.

Best Practice für die Roadmap:

• Zielversion definieren (z. B. „Landing auf LTS“ statt „beliebiges, aktuelles Quartal“)
• Zweiteilige Strategie prüfen: Stabil landen (LTS), danach kontinuierlich modernisieren (kleinere Updates).
• „Upgradeability“ als Produktziel etablieren: Weniger Overrides, klare Erweiterungsstrategie, CI/CD, automatisierte Tests.

Typische Migrationspfade, die wir in Projekten sehen:

• Liferay 6.2 → DXP (7.4/Quarterly):  
  Technisch am aufwändigsten (Alt-Architektur, Themes, Plugins, Daten).
• Liferay 7.0–7.3 → 7.4:  
  Meist gut planbar, aber Custom Code & Themes sind der Engpass.
• Liferay 7.4 → 2026.Q1 LTS:  
  Oft getrieben durch Plattformstrategie, Jakarta/Runtime-Wechsel und Infrastruktur-Modernisierung.
• CE → DXP:  
  Oft weniger „Rewrite“ als gedacht, aber Versions-Alignment und Build-/Dependency-Umstellung sind kritisch.
• On-Prem → Liferay Cloud:  
  Zusätzlich relevant: Datenfreeze, Artefakt-/Config-Migration, Betriebsprozesse

1) Assessment & Inventur (Scope, Risiko, Timeline)

Im ersten Schritt ist das Ziel, einen Überblick zu bekommen. Dazu ist die Erstellung einer „Migration Map“ sinnvoll, mit folgendem Inhalt:

• Customizations-Katalog (Module, Themes, Fragment-/JSP-Overrides, Hooks, Scheduler, SSO, Search, Commerce, Objects)
• Integrationen (IAM, CRM, DMS, SAP, Payment, Versand, E-Mail)
• Betriebsartefakte (Configs, Secrets, JVM-Flags, DB-Settings, Monitoring)
• Content-/Datenvolumen (DLStore, Index, Strukturen, Versionierung)

Deliverable: Architektur- und Migrationskonzept + Risikomatrix.

Gerade bei Sprüngen Richtung 2026 ist die Kompatibilitätsmatrix Pflichtlektüre: unterstützte Kombinationen aus App-Server, DB und Java-Version ändern sich über die Jahre.

Deliverable: „Certified Stack“-Entscheidung inkl. Hostingmodell (On-Prem/Cloud) und Betriebsanforderungen (HA, DR, RPO/RTO).

Aus der Erfahrung von vielen Migrationen ist der häufigste Zeitfresser nicht die Datenbank, sondern Custom Code, der an interne APIs oder UI-Details gekoppelt ist.

Der Hebel für weniger Upgrade-Stress sind Client Extensions. Diese erlauben Erweiterungen ohne Deploy von Java-Code in Liferay und sind dadurch lockerer gekoppelt (API-first) – ein großer Vorteil für zukünftige Upgrades.

Deliverable: Refactoring-Backlog (Must/Should/Could), inkl. Plan, welche Anpassungen zu Client Extensions, welche als OSGi bleiben – und welche eliminiert werden.

Planen Sie hier besonders sorgfältig:

• Backups & Restore-Proben durchführen (sonst ist ein „Rollback“ nur Theorie)
• Upgrade-Runbooks erstellen (Schrittfolge, Laufzeiten, Logs, Stop/Go-Kriterien)
• Validierung: Stichproben + automatisierte Checks (Counts, Schlüsselobjekte, Berechtigungen, Workflows)
• Ggf. kommen – je nach Umfang der Migration und der Betriebsprozesse – ein „Freeze Window“ und eine zweistufige Datenübernahme (DB + Document Library) dazu

Wichtige Tests, das in Liferay-Projekten wirklich zählt:

• Smoke Tests für Kern-Journeys (Login/SSO, Suche, Download, Formulare …)
• Regression der wichtigsten Rollen/Berechtigungen
• Performance-Baseline (vorher/nachher)
• Security Checks (Headers, Session, Permissions, Audit-relevante Funktionen)

Deliverable: Abnahmeprotokoll + Go-Live-Freigabe (inkl. „Known Issues“ und Workarounds).

Ein professioneller Cutover enthält:

• klare Downtime-Kommunikation
• Datenfreeze-Regeln
• „Last Sync“-Schritte (wenn relevant)
• Rollback-Punkt (bis wann möglich?)
• Hypercare (Monitoring, Error-Budget, Hotfix-Fenster)

Migration von älteren Versionen – zwei bewährte Pfade

Pfad A: Risiko splitten / Jakarta separat

Teams können das Risiko reduzieren, indem sie im ersten Schritt auf eine aktuelle LTS migrieren (bspw. 2025.Q1 LTS) und den (ggf. größeren) Jakarta-/Runtime-Sprung erst danach planen.

Pfad B: Direkt auf 2026.Q1 LTS

Dieser Pfad ist sinnvoll, wenn Sie ohnehin Ihre Infrastruktur modernisieren müssen und den großen Sprung einmal sauber (inkl. Tests/Refactoring) machen wollen. 2026.Q1 LTS ist offiziell verfügbar; prüfen Sie Release Notes und die Kompatibilitäts-Matrix.

• DSGVO ist die Basis für Datenschutzanforderungen (z. B. Zugriffskontrolle, Datenminimierung, Lösch-/Auskunftsfähigkeit).
• DORA (EU) 2022/2554 gilt seit 17.01.2025 in der Anwendung und macht u. a. ICT-Risiko- und Betriebsresilienz in regulierten Umfeldern noch relevanter.

Praktischer Migrations-Tipp: Nehmen Sie Compliance nicht „nach dem Go-Live“ auf. Bauen Sie Anforderungen direkt in Zielarchitektur, Logging / Monitoring, Berechtigungskonzept und Betriebsprozesse ein.

Eine Liferay DXP-Migration wird dann wirklich erfolgreich, wenn sie nicht nur „ins Ziel“ führt, sondern dauerhaft upgradefähig macht: klare LTS-Strategie, zertifizierter Stack, stabilere Customizations auf Basis von Client Extensions, saubere Tests und ein alltagstaugliches Update-Regime.