Was kostet eine Liferay-Migration? Zahlen und Erfahrungswerte aus 50+ Projekten

Was treibt die Kosten einer Liferay-Migration?

Zwei Blöcke, und der erste wird fast immer unterschätzt: der Zustand der Datenbank und der Umfang des eigenen Codes. Der Versionsabstand wirkt auf beide, ist aber selbst nicht der Kostentreiber.

• Ist die Datenbank überhaupt upgradefähig? Bei Portalen, die über Jahre oder Jahrzehnte gewachsen sind, lautet die Antwort oft: nicht ohne Vorarbeit.
• Wie viele eigene Module gibt es – und womit wurden sie gebaut? Zehn Standard-Liferay-Portlets sind ein anderes Projekt als drei Vaadin-Anwendungen.
• Wie tief greift der Code in die Plattform ein? EXT-Plugins und Hooks sind die teuersten Zeilen im Projekt.

Was dagegen selten der Treiber ist: die reine Datenmenge. Ein Portal mit 50.000 Inhalten migriert kaum langsamer als eines mit 5.000 – solange die Daten sauber sind.

Warum ist der Zustand der Datenbank der größte Einzelposten?

Weil sich Schäden über Jahre unbemerkt ansammeln und erst beim Upgrade sichtbar werden. Im laufenden Betrieb stört eine verwaiste Referenz niemanden – das Upgrade-Skript stolpert darüber und bleibt stehen.

Typische Funde in gewachsenen Portalen, besonders in der Community Edition, wo über die Jahre seltener konsolidiert wurde:

• Verweise auf nicht existente groupIds. Sites wurden gelöscht, ihre Inhalte blieben in den Tabellen zurück.
• Web-Content-Leichen. Artikel ohne Struktur, Strukturen ohne Template, Versionen ohne Artikel.
• Kaputte Portlet-Preferences. Konfigurationen von Portlets, die es längst nicht mehr gibt.
• Inkonsistente Ressourcen-Berechtigungen zu Objekten, die gelöscht wurden.
• Gemischte Zeichensätze und Kollationen aus verschiedenen Datenbankgenerationen.

Diese Altlasten lassen sich bereinigen, aber der Aufwand dafür steht vor der Analyse nicht fest. Deshalb ist die Vorab-Analyse kein Formalismus, sondern der Schritt, der aus einer Schätzung einen Festpreis macht: Erst ein Testlauf auf einer Kopie zeigt, was das Upgrade tatsächlich vorfindet.

Eine gesunde Datenbank migriert in Stunden. Eine kranke kann Wochen kosten – und niemand weiß vorher, welche der beiden vor ihm steht, bevor der erste Testlauf gefahren wurde.

Wie viel Aufwand steckt in welchem Versionssprung?

Der Grundaufwand besteht aus zwei Posten: dem Aufsetzen des Workspace und der Datenbankmigration. Die folgenden Werte stammen aus über 50 abgeschlossenen Liferay-Projekten seit 2008 und gelten für eine Datenbank ohne größere Altlasten:

• Liferay 7.4 → 2026.x: Workspace 0,5 bis 1 Personentag, Datenbank maximal 2 Stunden.
• Liferay 7.0 / 7.1 / 7.2 / 7.3 → 2026.x: Workspace 1 bis 2 Personentage, Datenbank 0,5 bis 1 Personentag.
• Liferay 6.0 / 6.1 / 6.2 → 2026.x: Workspace 3 bis 4 Personentage, Datenbank 3 bis 4 Personentage.
• 2026.Qx → 2026.Qy (etwa Q1 auf Q3): rund 1 Personentag inklusive Probelauf, Sicherung und Prüfung.

Ein Sprung von 7.4 auf die aktuelle Version ist damit an einem Tag machbar. Von 6.2 aus liegt allein der Grundaufwand bei sechs bis acht Personentagen – bevor ein einziges eigenes Modul angefasst wurde.

Findet der Testlauf Datenbankschäden, kommt deren Bereinigung obendrauf. Diese Position ist die einzige, die sich seriös erst nach der Analyse beziffern lässt.

Was kostet die Migration der eigenen Module?

Das hängt weniger an der Anzahl als an der Bauweise. Vier Fragen entscheiden über den Aufwand je Modul:

• Womit wurde es gebaut? Standard-Liferay-Portlets lassen sich fortschreiben. Module auf Basis von JSF oder Vaadin sind der teuerste Fall: Diese Technologien spielen heute keine Rolle mehr, es gibt keinen Migrationspfad, sie werden neu gebaut.
• Wie viele EXT-Plugins gibt es? EXT greift direkt in den Liferay-Kern ein. Es existiert in modernen Versionen nicht mehr – jedes EXT-Plugin ist ein Neubau, oft mit vorgelagerter Frage, ob die Funktion überhaupt noch gebraucht wird.
• Wie viele Hooks? Hooks gibt es nur noch in stark eingeschränkter Form. Ein Teil lässt sich auf Bordmittel abbilden, ein Teil auf Client Extensions, der Rest wird neu entwickelt.
• Wie viele Aufrufe auf APIs, die es nicht mehr gibt? Das ist der Posten, der beim Überschlagen am häufigsten vergessen wird. Manche APIs wurden entfernt, andere funktionieren heute anders – beides fällt erst beim Kompilieren oder, schlimmer, im Test auf.

Dazu kommt bei Sprüngen ab 7.4 die Umstellung von Java EE auf Jakarta EE: Jeder Import von javax.servlet muss auf jakarta.servlet wechseln. Mechanisch, aber in jedem Modul – und gut automatisierbar.

Warum sinken die Kosten manchmal auf null?

Weil ein Teil der Eigenentwicklung durch die Plattform überflüssig geworden ist. Das ist der angenehmste Befund einer Analyse und tritt häufiger auf, als Betreiber erwarten.

Ein Beispiel aus der Praxis: Ein Modul, das mehrsprachige Friendly URLs nachrüstet, war in älteren Versionen eine sinnvolle Eigenentwicklung. Seit Liferay 7.4 ist diese Funktion Bordmittel. Das Modul wird nicht migriert, sondern ersatzlos gestrichen – die Funktion bleibt, der Wartungsaufwand entfällt dauerhaft.

Ähnliches gilt für Suchfunktionen, Formularbausteine, Berechtigungslogiken und Navigationselemente, für die es heute Fragmente, Liferay Objects oder Standardwidgets gibt. Jedes so aufgelöste Modul senkt nicht nur die Migrationskosten, sondern auch die des übernächsten Upgrades.

Portalworks erstellt vor jedem Angebot eine Vorab-Analyse mit Testlauf auf einer Datenbankkopie und gibt darauf ein Festpreisangebot, statt nach Aufwand abzurechnen. Das Erstgespräch ist kostenlos.

Migrieren oder neu bauen – was ist bei alten Portalen günstiger?

Bei Liferay 6 lohnt sich diese Frage fast immer, und die Antwort fällt häufiger zugunsten des Neubaus aus, als Betreiber erwarten. Der Grund liegt nicht in Liferay, sondern darin, wie sich Entwicklung seither verändert hat.

Ein Portal aus dem Jahr 2014 besteht aus schwergewichtigen Portlets, weil es damals nichts anderes gab. Jede Kachel, jede Liste, jedes Formular war ein Java-Modul mit eigenem Deployment-Zyklus. Heute deckt die Plattform denselben Bedarf mit deutlich leichteren Mitteln ab:

• Client Extensions statt Eingriffen in die Plattform – sie überleben Versionswechsel weitgehend unbeschadet.
• Fragmente und Style Books statt eigener Theme-Logik – Layout und Gestaltung entstehen ohne Java-Code.
• Liferay Objects statt selbst gebauter Datenmodelle – Entitäten, Formulare und Listen entstehen im Low-Code-Ansatz.
• Headless-APIs statt tief verdrahteter Frontends.

Daraus folgt eine unbequeme, aber ehrliche Rechnung: Wer vierzig Portlets aus 6.2 eins zu eins nach 2026 überträgt, bezahlt vierzig Neubauten – und bekommt ein Portal, das architektonisch aus dem Jahr 2014 stammt und beim nächsten Upgrade dieselben Kosten erneut verursacht.

Die richtige Frage bei Liferay 6 lautet nicht „Wie migrieren wir das?", sondern „Was davon brauchen wir überhaupt noch?"

In der Praxis fällt bei dieser Prüfung regelmäßig ein erheblicher Teil des Altbestands weg: Funktionen, die niemand mehr nutzt; Eigenentwicklungen, die heute Bordmittel sind; Module, die nur existieren, weil eine bestimmte Version eine bestimmte Lücke hatte. Was bleibt, wird auf der aktuellen Architektur gebaut – und ist beim nächsten Versionswechsel deutlich billiger.

Drei Kriterien sprechen für einen Neubau statt einer Fortschreibung:

• Die Ausgangsversion ist 6.x – die Anpassungen müssen ohnehin neu entstehen.
• Ein spürbarer Teil der Eigenentwicklung ist heute Standardfunktion oder wird nicht mehr genutzt.
• Das Portal soll ohnehin fachlich überarbeitet werden – dann zahlt man die Migration sonst zweimal.

Für eine Fortschreibung spricht: eine Ausgangsversion ab 7.0, überschaubare Eigenentwicklung, eng verdrahtete Integrationen, die stabil laufen – und ein Portal, das fachlich bleiben soll, wie es ist.

Warum wird eine Migration teurer, je länger man wartet?

Nicht, weil Liferay komplizierter wird – sondern weil der eigene Code altert und die Zwischenschritte zunehmen. Vier Effekte wirken zusammen:

• Die Zahl der Sprünge steigt. Liferay unterstützt Upgrade-Pfade, aber sehr alte Stände brauchen Zwischenstationen. Jede kostet Zeit zum Durchlaufen und Prüfen.
• Eigener Code veraltet mit. Wer 2019 stehen blieb, trifft heute nicht nur auf OSGi, sondern zusätzlich auf die Jakarta-EE-Umstellung – und auf APIs, die es in dieser Form nicht mehr gibt.
• Die Datenbank sammelt weiter. Jedes Betriebsjahr produziert neue verwaiste Referenzen und Karteileichen. Der Bereinigungsaufwand wächst mit der Zeit, nicht mit der Nutzung.
• Sicherheit läuft weg. Die Community Edition ist eingestellt, 7.4.3.132 war das letzte Release. Es gibt keine Sicherheitsupdates mehr.

Die teuerste Migration ist die, die man dreimal verschoben hat. Nicht wegen des Sprungs – sondern wegen allem, was in der Zwischenzeit um das Portal herum gebaut wurde.

Wie schnell läuft eine Migration innerhalb der 2026er-Versionen?

An einem Tag, inklusive Vorbereitung und Prüfung. Ein konkretes Beispiel: Portalworks hat die eigene Website portalworks.de am 28. August 2026 von Liferay DXP 2026.Q1.2 auf 2026.Q3.1 gehoben.

• 485 Datenbanktabellen, 216 MB Dokumente, eigenes Theme, eigene Module
• Datenbank-Upgrade und Serverstart zusammen: 61 Sekunden
• Null Fehler im Upgrade-Protokoll
• Die Seite war während des Fensters kurz nicht erreichbar, danach schneller als vorher

Möglich war das, weil die Migration vorher zweimal lokal durchgespielt wurde – einmal auf einer neueren Datenbankversion, einmal auf exakt der Version des Produktivservers. Beide Läufe brachten Erkenntnisse, die im Ernstfall Stunden gekostet hätten:

• Das Tomcat-Bundle führt das Datenbank-Upgrade nicht automatisch aus. Ohne upgrade.database.auto.run=true bricht der Start mit einer Schema-Meldung ab – sauber, aber überraschend, wenn man es nicht erwartet.
• Der kostenlose Aktivierungsschlüssel trägt die Produktversion 2026.Q1, wird aber auch von 2026.Q3 akzeptiert. Ein neuer Schlüssel war nicht nötig.
• Ein Datenbank-Upgrade war nicht erforderlich. Liferay 2026.Q3 läuft auf MariaDB 10.3 ohne Beanstandung.

Was macht eine Migration schnell – und was macht sie teuer?

Der Unterschied zwischen einem Tag und mehreren Wochen liegt selten an Liferay, sondern an Entscheidungen, die Jahre vorher getroffen wurden. Wer heute baut und in fünf Jahren günstig migrieren will, hält sich an fünf Regeln:

• Kein gepatchter Core. Wer Liferay-Klassen überschreibt, zahlt bei jedem Upgrade erneut.
• Client Extensions statt Eingriffen in die Plattform. Sie überleben Versionswechsel weitgehend unbeschadet.
• Standard-Fragmente statt eigener Theme-Logik. Je weniger Sonderweg im Frontend, desto weniger Nacharbeit.
• Headless statt tief integriertem Frontend. Ein über die APIs angebundenes Frontend ist von einem Portal-Upgrade kaum betroffen.
• Regelmäßig upgraden. Zwei kleine Sprünge sind zusammen deutlich günstiger als einer über dieselbe Distanz.

Was leistet KI bei einer Liferay-Migration wirklich?

Sie verkürzt die mechanische Arbeit erheblich, ersetzt aber keine Architekturentscheidung. Über den Liferay MCP Server lassen sich Inhalte, Strukturen und Konfigurationen von KI-Agenten lesen und schreiben – das verändert vor allem drei Bereiche:

• Content-Migration. Das Zuordnen alter Strukturfelder auf neue Modelle ist Fleißarbeit, die Agenten zuverlässig übernehmen. Portalworks hat dazu einen Fachartikel auf der Website von Liferay veröffentlicht.
• Code-Umstellungen. Der Wechsel von javax auf jakarta ist regelbasiert und damit gut automatisierbar.
• Prüfung. Der Abgleich von hunderten Seiten vor und nach der Migration lässt sich automatisiert fahren, statt stichprobenartig per Hand.

Was KI nicht abnimmt: die Entscheidung, welche Eigenentwicklung ersatzlos entfällt, welche durch Bordmittel ersetzt wird und welche neu gebaut werden muss. Genau dort liegt bei alten Portalen der Hauptaufwand – und genau dafür braucht es jemanden, der beide Versionsstände kennt.

Wie kommt man zu einer belastbaren Zahl?

Über eine Vorab-Analyse. Portalworks sieht sich dafür an, welche Liferay-Version im Einsatz ist, wie viele eigene Module existieren, welche Integrationen bestehen und wie das Frontend gebaut ist. Daraus entsteht ein Migrationsplan mit Festpreis.

Sinnvoll ist dieser Schritt auch dann, wenn die Migration noch nicht ansteht: Er zeigt, welche Altlasten den späteren Aufwand treiben – und welche sich vorher günstig auflösen lassen.

Unser Migrationsrechner (siehe unten) erlaubt es Ihnen, grob zu kalkulieren, wieviel Aufwand wir hinter Ihrer Migration sehen werden.