Liferay CE endet: Was Sie zur Plattform wissen müssen

Für viele Liferay-CE-Anwender ist die Ankündigung vom März 2026 ein böses Erwachen. Bedeutet sie doch das Ende der Liferay Community Edition (CE): Ab 2026.Q1 stellt Liferay von getrennten Installationen für CE und DXP auf eine einheitliche, modulare Plattform um.  

Künftig wird also nicht mehr zwischen Distributionen unterschieden; alle betreiben denselben „Liferay-Core“ und Funktionen werden über einen Activation Key freigeschaltet. Für CE-Anwender wird es dafür einen kostenlosen Activation Key geben.  

Wer darüber hinaus Support, Updates oder zusätzliche Leistungen benötigt, kann auf einen Subscriber Activation Key wechseln, ohne Neuinstallation oder Editions-Migration. Gleichzeitig erhalten Nicht-Subscriber Zugriff auf die jeweils erste Version eines Quarterly Releases (z. B. 2026.Q1.0, 2026.Q2.0). 

So positiv Liferay diese Veränderung darstellt, ist für Bestandsanwender eine Einordnung wichtig: Für Teams, die heute Liferay CE produktiv einsetzen, bedeutet diese Umstellung das Ende von CE als eigenständiger Edition/Distribution, zukünftig werden keine offiziellen CE-Builds mehr bereitgestellt.  

Open Source bleibt ausdrücklich Bestandteil des Modells; der Quellcode ist also weiterhin verfügbar und kann bei Bedarf auch selbst gebaut werden. Dennoch verschiebt sich damit die praktische Ausgangslage: Die Frage ist nicht mehr, ob man „CE einfach weiterlädt“, sondern wie man Betrieb, Update-Strategie, Security und Upgrade-Fähigkeit unter dem neuen Modell sauber organisiert. 

Wer Liferay CE produktiv betreibt und Verfügbarkeit, Sicherheit sowie Audit- und Compliance-Anforderungen zuverlässig erfüllen muss, der braucht daher eine tragfähige Strategie für den Weg in die neue Liferay-Welt ab 2026.Q1. Fragestellungen betreffen die Reduktion von Risiken, die planbare Weiterentwicklung und der stabile langfristige Betrieb der Plattform - ohne vorschnell auf eine andere Lösung auszuweichen. 

Die Umstellung auf eine einheitliche Plattform ab 2026.Q1 zwingt Organisationen, die ihre CE-Installation bislang eher evolutionär weiterbetrieben haben, die eigene Betriebs- und Upgrade-Strategie bewusst zu überprüfen. 

Auslöser ist der Wegfall der bisherigen CE-Logik als Distribution: Es gibt keine offiziellen CE-Builds mehr, stattdessen gibt es einen klaren Weg in Richtung des neuen Modells.  

Das Release 2026.Q1 ist ein sinnvoller Fixpunkt, um eine moderne Basis (inkl. Jakarta/aktueller Java-Unterstützung) herzustellen und danach wieder in ein planbares Update-Regime zu kommen. 

Gleichzeitig gibt es natürlich Fragen: Wie groß ist der Aufwand bei vielen Custom-Modulen und Integrationen? Welche Downtime ist zu erwarten? Wie werden Security und Bugfixes abgedeckt, wenn man zunächst ohne Subskription startet? Und wie lässt sich vermeiden, dass ein Upgrade-Projekt zum monatelangen Sonderprogramm wird, das Produktteams ausbremst? 

Schließlich wirkt auch Gewohnheit: Viele Liferay-Installationen sind historisch aus 6.2 heraus „mitgewachsen“ und wurden primär technisch aktuell gehalten – ohne die Plattform als Produkt (mit klarer Update-Strategie, Governance und Modernisierungsleitplanken) zu betrachten.  

Die neue Liferay-Delivery-Logik macht genau diesen Punkt sichtbar: Wer Liferay langfristig erfolgreich betreiben will, muss die Plattform nicht nur updaten, sondern gezielt upgradefähig machen. 

Für bestehende CE-Teams ist die wichtigste Konsequenz: Das neue Modell verändert weniger die grundsätzliche Nutzbarkeit der Plattform, aber deutlich die operativen Spielregeln rund um Bereitstellung, Updates und Verantwortlichkeiten. Statt „CE herunterladen und betreiben“ wird Liferay ab 2026.Q1 als einheitliche Installation verstanden, deren Funktionsumfang über Activation Keys gesteuert wird - auch im Community-Kontext. 

Aus Anwendersicht lassen sich die Handlungsoptionen auf drei Wege reduzieren. Welche Variante passt, hängt vor allem von Kritikalität, Compliance-Anforderungen, Customizing-Grad und internen Kapazitäten ab. 

Option 1: Weiter selbst bauen (Build from source / maximale Eigenverantwortung) 

Diese Variante bietet maximale Kontrolle und Unabhängigkeit. Gleichzeitig übernehmen Sie vollständig Build- und Release-Engineering, Security-Bewertung, Patch-Management, Regressionstests und Rollback – inklusive der Nachweisführung, die in vielen Organisationen (Audit/Compliance) erforderlich ist. Das kann funktionieren, setzt aber eine bewusst akzeptierte Risikoposition sowie entsprechende personelle und prozessuale Reife voraus. Wir empfehlen diese Option daher ausdrücklich nicht. 

Option 2: Unified Platform mit kostenlosem Activation Key (Non-Subscriber) 

Sie nutzen offizielle Artefakte und den Quarterly-Release-Takt ohne Subscription. Für produktive, geschäftskritische Umgebungen ist diese Option jedoch häufig nur eingeschränkt geeignet: Non-Subscriber erhalten nur die .0-Version je Quartal, und damit einen Stand, bei dem erfahrungsgemäß nicht alle Themen aus der frühen Nutzung bereits durch nachgelagerte Fixes adressiert sind. Zusätzlich empfehlen wir, die damit verbundenen vertraglichen Nutzungs- und Betriebsrahmenbedingungen (EULA) und deren praktische Auswirkungen frühzeitig zu klären.  

Option 3: Subscriber Activation Key (Support & Updates) 

Diese Option schafft die höchste Planbarkeit: geregelte Update-Strategie, Supportfähigkeit und verlässliche Reaktionswege im Incident-Fall. Wichtig ist zudem: Mit der Subskription wird auch die Einbindung von Liferay-Partnern als Support- und Umsetzungspartner deutlich sinnvoller und belastbarer. 

Empfehlung: Aus unserer Sicht ist die einzig realistische Option für produktive, geschäftskritischen Plattformen Option 3. Option 1 ist eine bewusste Ausnahmeentscheidung; Option 2 eignet sich eher für Evaluation, Entwicklung oder Szenarien mit geringer Kritikalität und klar akzeptierten Einschränkungen. 

Warum 2026.Q1 als Zielrelease 

Wenn ein Liferay CE-System ohnehin strategisch neu aufgestellt werden muss, sollte das Zielrelease so gewählt werden, dass es nicht nur „kompatibel“ ist, sondern die Plattform für die nächsten Jahre tragfähig macht. 2026.Q1 ist dafür ein sehr sinnvoller Zielpunkt: Es ist der Start der unified Plattform und bietet zugleich eine moderne technische Basis, insbesondere durch die Umsetzung der Jakarta-Umstellung sowie Unterstützung zeitgemäßer Java-Versionen. 

Damit ist 2026.Q1 nicht nur ein Upgrade-Schritt, sondern ein geeigneter Fixpunkt, um Upgrade-Fähigkeit wiederherzustellen: klare Release-Logik, bessere Planbarkeit für Folgeupdates und eine solide Grundlage für moderne Erweiterungs- und Integrationsmodelle (z. B. stärker entkoppelt mit Client Extensions). 

Unsere Empfehlung: Für produktive Plattformen sollte das Zielbild auf 2026.Q1 ausgerichtet und frühzeitig mit einem Assessment abgesichert werden, insbesondere bei hohem Customizing- und Integrationsgrad. 

So wird aus der Entscheidung ein umsetzbarer Plan

Gerade bei Liferay-Installationen mit vielen Custom-Modulen, Themes und Integrationen ist ein Upgrade auf 2026.Q1 weniger ein „Standard-Upgrade“ als ein planbares Transformationsvorhaben. Der pragmatischste Weg ist daher ein Assessment-first Ansatz, der Unsicherheit reduziert und Entscheidungen belastbar macht, bevor Implementierungsaufwände entstehen. 

Typische Ergebnisse eines solchen Assessments sind: 

• Inventarisierung aller Module, Themes, Client Extensions (falls vorhanden), Konfigurationen und Integrationen inkl. Kritikalität und Ownership 
• Jakarta-/Java-Readiness: Code- und Dependency-Check, Build-/CI-Analyse, Risikoklassen und Quick Wins 
• Custom-to-Standard Plan: Kandidatenliste, welche Speziallösungen sinnvoll auf Standardfunktionen zurückgeführt werden können (mit Aufwand/Nutzen) 
• Upgrade-Pfad & Cutover-Konzept: Teststrategie, Migrationsschritte, Downtime-/Rollback-Plan 
• Betriebszielbild: On-Prem, Kubernetes oder perspektivisch Liferay PaaS – inkl. Leitplanken für Observability und Deployment 

So entsteht aus der grundsätzlichen Entscheidung eine umsetzbare Roadmap mit klaren Risiken, Prioritäten und nächsten Schritten. 

Mit dem neuen, modularen Plattformmodell rückt bei Liferay weiterhin ein cloud-natives Zielbild stärker in den Vordergrund: „Cloud“ bedeutet dabei nicht zwingend Public Cloud, sondern kann ebenso eine eigene (private) Cloud bzw. eine standardisierte Container-Plattform sein.  

Praktisch eröffnen sich damit abgestufte Betriebsoptionen – von Self-Hosted über Kubernetes-basierte Deployments und cloud-providerfähige Setups bis hin zu managed PaaS bzw. voll gemanagten SaaS-Ansätzen. Der gemeinsame Vorteil: moderne Betriebsprozesse (Automatisierung, reproduzierbare Umgebungen, Observability, schnellere Rollouts) lassen sich konsistent etablieren und skalieren. 

Die Umstellung auf die einheitliche Liferay-Plattform ab 2026.Q1 ist für viele CE-Anwender ein Wendepunkt: Nicht, weil Liferay an Relevanz verliert - im Gegenteil -, sondern weil Betrieb, Updates und Erweiterungen künftig bewusster und professioneller organisiert werden müssen. Unsere klare Empfehlung für produktive, geschäftskritische Plattformen ist daher, den Weg Richtung 2026.Q1 mit Subscription/Support sowie einem Assessment-first Vorgehen abzusichern. 

Als Liferay Platinum Partner mit 15+ Jahren Erfahrung und einem großen Team unterstützen wir Sie von der Entscheidungsfindung bis zur Umsetzung (Upgrade, Custom-to-Standard, Betrieb On-Prem/Kubernetes/PaaS). Sprechen Sie uns für ein kurzes Orientierungsgespräch oder ein Upgrade-Readiness-Assessment an.