FirstSpirit nach Liferay migrieren: Inhalte, Vorlagen und Redaktion richtig übertragen

Bei einer Migration von FirstSpirit nach Liferay werden redaktionelle Inhalte, Medien und ihre Beziehungen in ein neues Inhaltsmodell überführt. Seitenreferenzen, Vorlagen, Freigaben und öffentliche URLs benötigen eigene Zuordnungen. Entscheidend ist, ob FirstSpirit anschließend vollständig abgelöst wird oder weiterhin die Redaktion übernimmt und Liferay die Inhalte im Portal ausliefert.

Wer FirstSpirit bereits zusammen mit einem Portal betreibt, sollte diese Entscheidung vor dem ersten Export treffen. Zwei Systeme können eine sinnvolle Arbeitsteilung haben. Sie können aber auch doppelten Betriebsaufwand, getrennte Freigaben und schwer nachvollziehbare Fehler verursachen. Eine Migration lohnt sich dann, wenn das vereinbarte Liferay-Zielbild diese Probleme tatsächlich löst und die Redaktion ihre Arbeit dort zuverlässig erledigen kann.

Dieser Leitfaden beschreibt die technische Planung einer Migration von FirstSpirit in das objektbasierte Liferay CMS. Als Liferay-Partner legt Portalworks dabei besonderes Gewicht auf das Zielmodell, die Redaktionsprozesse und die Umsetzung individueller Funktionen. Eine beispielhafte Meldung zeigt, wie Inhalte, Dateien und Seitenreferenzen im Zielsystem zusammengeführt werden.

Fachlicher Stand: 23. Oktober 2026. Ziel der beschriebenen Migration ist das neue objektbasierte Liferay CMS. Welche Funktionen und Schnittstellen eingesetzt werden können, hängt vom konkreten FirstSpirit- und Liferay-Release, den installierten Modulen und der Betriebsform ab.

 

1. FirstSpirit behalten oder ablösen?

Die erste Frage lautet: Wo sollen Redakteure nach dem Projekt Inhalte erstellen, übersetzen und freigeben? Bleibt diese Arbeit in FirstSpirit, handelt es sich im Kern um eine Integration. Wechselt sie nach Liferay, müssen neben den Daten auch die redaktionellen Abläufe übertragen werden.

Für den Weiterbetrieb von FirstSpirit spricht, wenn das CMS mehrere wichtige Ausgabekanäle versorgt, umfangreiche redaktionelle Funktionen bereits eingerichtet sind oder andere Websites unabhängig vom Portal weiterlaufen. In diesem Fall wäre die Abschaltung allein wegen eines neuen Liferay-Portals möglicherweise teurer als eine klar definierte Schnittstelle.

Für die Ablösung spricht, wenn Liferay künftig die maßgebliche Plattform für Inhalte und Services ist, die Redaktion dort ihre Anforderungen abdecken kann und FirstSpirit keine verbleibende Aufgabe mehr hat. In die Rechnung gehören auch Betrieb, Wartung, Anpassungen, Schulungen und die Zeit, in der beide Systeme parallel laufen.

Bei einer Integration muss jedes Datenobjekt ein führendes System haben. Wird ein FirstSpirit-Inhalt in Liferay zwischengespeichert, braucht es Regeln für Aktualisierung, Löschung, Freigabestand und Cache-Invalidierung. Änderungen an derselben Überschrift in beiden Systemen sind ein Konfliktfall, den ein Schnittstellenkonzept ausdrücklich behandeln muss.

FirstSpirit CaaS Connect unterscheidet Vorschau- und Freigabedaten. Eine öffentliche Portalansicht darf deshalb nicht versehentlich auf den Vorschau-Datenbestand zugreifen. Bei Projekten ohne aktivierte Freigabefunktion gelten besondere Synchronisationsregeln. Die vorhandene Konfiguration muss geprüft werden, bevor CaaS als Quelle verwendet wird. Quelle: FirstSpirit CaaS Connect

2. Das Liferay-Zielmodell festlegen

Portalworks setzt bei neuen CMS-Projekten auf das objektbasierte Liferay CMS. Darauf beziehen sich die Zuordnungen in diesem Artikel. Bestehende Lösungen mit klassischen Web Contents werden bei der Bestandsaufnahme berücksichtigt, bilden hier aber nicht das Zielmodell. Liferay empfiehlt das neue CMS für neue Implementierungen; das weiterhin unterstützte Classic CMS befindet sich seit DXP 2026.Q1 im Wartungsmodus. Quelle: Liferay Classic CMS

Vor der Umsetzung wird geprüft, wie sich die benötigten Inhaltstypen, Sprachvarianten, Referenzen, Freigaben und Darstellungen im vorgesehenen Release abbilden lassen. Bei einem bestehenden Portal werden außerdem die Abhängigkeiten von bisherigen Strukturen, Templates und Integrationen aufgenommen. Verfügbarkeit und Aktivierung der benötigten Funktionen sind am tatsächlichen Zielsystem zu prüfen.

Im objektbasierten CMS organisieren Spaces Inhalte, Dateien und die Zusammenarbeit. Inhaltsstrukturen definieren die redaktionellen Felder. Die Aufteilung sollte sich an Verantwortlichkeiten und Wiederverwendung orientieren: Welche Redaktion pflegt welche Inhalte? Welche Dateien werden über mehrere Sites hinweg benötigt? Welche Bereiche brauchen getrennte Zugriffsrechte? Quelle: Speicherorte in Liferay

Das Zielmodell wird vor dem Importer festgelegt. Ein Zwischenimport in klassische Web-Content-Strukturen würde einen zusätzlichen Modellwechsel verursachen. Der Migrationsweg sollte deshalb direkt auf die vorgesehenen Inhaltsstrukturen und Spaces ausgerichtet werden. Release-Stand, Feldmodell, Beziehungen und Importoperationen werden gemeinsam dokumentiert.

3. Den FirstSpirit-Bestand richtig lesen

FirstSpirit trennt Inhalte, Website-Struktur, Medien und Vorlagen in Verwaltungsbereiche, die sogenannten Stores. Für eine Migration ist diese Trennung wesentlich: Die sichtbare Webseite entsteht aus mehreren zusammenwirkenden Objekten. Ein Export der veröffentlichten HTML-Dateien bildet nur das Ergebnis ab. Quelle: FirstSpirit-Store-Struktur

Die Bestandsaufnahme erfasst für jedes Projekt mindestens Inhaltstypen, verwendete Vorlagen, Sprachen, Freigabeverfahren, Ausgabekanäle und angebundene Systeme. Zusätzlich werden die tatsächlich veröffentlichten URLs aufgenommen. So lassen sich interne Bestände und öffentlich erreichbare Inhalte miteinander vergleichen.

Besonders zu prüfen sind Remote-Referenzen, projektübergreifend genutzte Medien, kundenspezifische Module und Datenquellen außerhalb des CMS. Ein Export kann lokal vollständig erscheinen und trotzdem auf ein Bild oder einen Datensatz in einem anderen Projekt angewiesen sein.

Die Zahl der Webseiten allein ist kein brauchbarer Maßstab für den Aufwand. Mehrere tausend gleich aufgebaute Meldungen können einfacher zu übertragen sein als wenige hundert Seiten mit unterschiedlichen Absatzvorlagen, Formularen und individuellen Ausgaberegeln. Deshalb zählen wir auch Vorlagentypen, Referenzarten und Sonderfälle.

4. Inhalte und Vorlagen zuordnen

Die folgende Tabelle beschreibt fachliche Zuordnungen. Sie ersetzt keine Prüfung der konkreten Felder und Funktionen im Zielrelease.

Im Liferay CMS können Inhaltsstrukturen für redaktionelle Inhalte und für Dateien definiert werden. Eine FirstSpirit-Vorlage wird dafür fachlich zerlegt: Welche Felder speichern Inhalt, welche steuern die Ausgabe, welche enthalten Beziehungen? Daraus entstehen das neue Formularmodell und eine gesonderte Darstellungsregel. Quelle: Liferay-CMS-Inhaltstypen

Für einen Produktdatensatz ist beispielsweise zu klären, ob er redaktionelle Beschreibung, Stammdaten oder beides enthält. Preise und Verfügbarkeiten sollten nicht allein deshalb zu CMS-Inhalten werden, weil sie bisher über FirstSpirit angezeigt wurden. Gehören sie fachlich in ein PIM, ERP oder Fachverfahren, bleibt dieses System maßgeblich. Liferay übernimmt dann die Darstellung oder den Zugriff.

5. Beispiel: eine Meldung mit zwei Seitenreferenzen

Angenommen, eine Meldung liegt im Page Store und wird über zwei PageRefs im Site Store ausgegeben: einmal unter „Unternehmen/Aktuelles“, einmal unter „Presse“. Sie besitzt eine deutsche und eine englische Fassung, ein Titelbild, einen PDF-Anhang und drei Absätze. Dieses Beispiel ist bewusst vereinfacht.

Im Zielmodell entsteht zunächst ein redaktioneller Meldungsinhalt. Titel, Teaser, Datum und Text werden als definierte Felder übernommen. Bild und PDF werden als Medien referenziert. Die beiden Einstiege in der Website werden unabhängig davon umgesetzt. Dadurch muss die Redaktion eine inhaltliche Korrektur weiterhin nur einmal pflegen.

Die beiden URLs dürfen nicht blind zusammengelegt werden. Haben die bisherigen Ansichten unterschiedliche Überschriften, Metadaten oder einen anderen fachlichen Kontext, ist zu entscheiden, welche Unterschiede erhalten bleiben. Sind sie lediglich doppelte Zugänge zum selben Inhalt, kann eine gemeinsame Zieladresse mit Weiterleitungen sinnvoll sein.

Für die Meldung wird im Liferay CMS ein Inhaltstyp mit den benötigten Feldern angelegt. Die Detailansicht wird über die im Zielrelease unterstützte CMS-Anbindung an die Site umgesetzt. Im Prototyp werden Feldzuordnung, Sprachwechsel, Medien und die beiden Seiteneinstiege gemeinsam geprüft. Eine korrekte Datenübernahme und eine funktionierende Darstellung sind zwei getrennte Abnahmepunkte.

6. Strukturiert exportieren

Für einen nachvollziehbaren Export werden Inhalte mit ihren Typen, Feldwerten, Referenzen und Sprachen benötigt. FirstSpirit stellt dafür unter anderem die Access-API bereit. Der Store-Zugriff kann den aktuellen Arbeitsstand oder den zuletzt freigegebenen Stand liefern. Welche Variante verwendet wird, ist eine fachliche Entscheidung und muss im Exportprotokoll stehen. Quelle: Zugriff auf FirstSpirit-Store-Elemente

Ein freigegebener Stand ist nicht zwingend mit dem zuletzt ausgelieferten Website-Stand identisch: Zwischen Freigabe und Deployment können weitere Schritte liegen. Für die Abnahme werden deshalb Export, Veröffentlichungsprozess und Live-Website zusammen betrachtet.

Eine vorhandene CaaS-Auslieferung kann als Datenquelle dienen, sofern sie alle benötigten Inhalte und Beziehungen enthält. Sie ist nicht automatisch ein vollständiges Projektarchiv. Vorlagen, historische Stände, redaktionelle Rechte und technische Konfigurationen benötigen gegebenenfalls einen gesonderten Export.

Auch FirstSpirit-Projektexporte und ContentTransport-Pakete dürfen nicht mit einem Liferay-Importformat verwechselt werden. Die dokumentierten Transportfunktionen übertragen FirstSpirit-Projektinhalte zwischen FirstSpirit-Projekten. Für Liferay ist eine eigene Transformation erforderlich. Quelle: FirstSpirit-Transportfunktionen

Ein herstellerunabhängiges Zwischenformat erleichtert diese Transformation. Es hält Quellidentität, Inhaltstyp, Felder, Referenzen und Exportstand getrennt. Damit lässt sich ein fehlerhafter Export von einer fehlerhaften Liferay-Zuordnung unterscheiden.

{
  "sourceKey": "fs:corporate:pagestore:4711",
  "sourceState": "released",
  "contentType": "news",
  "fields": {
    "headline": { "de_DE": "Neuer Standort", "en_GB": "New location" }
  },
  "references": {
    "heroImage": "fs:corporate:mediastore:812"
  },
  "pageReferences": [
    "fs:corporate:sitestore:9001",
    "fs:corporate:sitestore:9002"
  ]
}

Das JSON zeigt ein frei definiertes Zwischenformat, keinen direkt ausführbaren FirstSpirit-Export oder Liferay-API-Aufruf. Projektkennung, IDs, Felder und Sprachzuordnung sind Beispiele.

7. Absätze, Referenzen und Darstellung umsetzen

Die Übernahme einzelner Textfelder ist meist überschaubar. Schwieriger sind Inhalte, die mehrere Absatztypen, verschachtelte Kataloge oder projektspezifische Verweise enthalten. Hier muss die Transformation die Bedeutung der Daten verstehen.

FS_CATALOG und Absatzreihenfolgen

Ein Katalog aus Text, Bild, Zitat und Download ist eine geordnete Folge unterschiedlicher Elemente. Werden diese ohne Typinformation zu einem HTML-Feld zusammengefügt, verliert die Redaktion einen Teil ihrer Bearbeitungsmöglichkeiten. Das Zielmodell sollte festlegen, welche Elemente als strukturierte Gruppen, eigenständige Inhalte oder Seitenbausteine weitergeführt werden.

Für jedes übernommene Element werden Typ, Position und gegebenenfalls Verschachtelung gesichert. Der Probelauf muss zeigen, ob die Redaktion Reihenfolge und Varianten im Zielsystem tatsächlich bearbeiten kann. Eine optisch richtige Erstübertragung genügt dafür nicht.

FS_REFERENCE und interne Links

FS_REFERENCE kann je nach Konfiguration auf Medien, Seitenreferenzen oder andere FirstSpirit-Elemente zeigen. Ein pauschales Umwandeln in eine Zeichenkette reicht nicht. Der Importer muss den Referenztyp erkennen und die passende Ziel-ID, Inhaltsadresse oder Datei ermitteln. Auch Absatzanker können Teil des Verweises sein. Quelle: FirstSpirit FS_REFERENCE

Bei FS_INDEX wird zusätzlich geprüft, welche Datenquelle beziehungsweise welches DataAccessPlugin dahinterliegt. Ein Eintrag kann auf Daten verweisen, die gar nicht in diesem FirstSpirit-Projekt gespeichert sind. Solche Beziehungen gehören in das Integrationskonzept. Quelle: Zugriff auf FS_INDEX-Daten

Templates, Skripte und Formulare

FirstSpirit-Ausgabeanweisungen wie $CMS_VALUE(...)$ oder $CMS_REF(...)$ werden in Liferay nicht als solche ausgeführt. Formularmodell, Ausgabemarkup und darin enthaltene Logik werden getrennt betrachtet. Eine Bedingung für die Anzeige eines Teasers gehört in die neue Darstellung; eine Preisabfrage gehört gegebenenfalls in einen Backend-Service.

Die Darstellung wird passend zum objektbasierten Inhaltsmodell umgesetzt. Für jede bisherige Vorlage wird festgelegt, welche Daten sie benötigt und welche Ausgabe sie erzeugen soll. Bestehendes HTML und CSS kann dabei als Ausgangspunkt dienen; Datenzugriffe, Bedingungen und Verknüpfungen müssen zur neuen Architektur passen.

Formulare benötigen eine eigene Funktionsprüfung: Empfänger, Validierung, Uploads, Bestätigungsmails und Anbindung an Fachverfahren sind durch eine Übernahme des HTML-Markups noch nicht migriert. Dasselbe gilt für Suche, Personalisierung und geschützte Downloads.

Individuelle Logik: erst das Verhalten erfassen, dann den Code ersetzen

In gewachsenen CMS-Projekten steckt fachliches Wissen oft in kleinen Anpassungen: Ein Download erscheint nur für bestimmte Kundengruppen, eine Kontaktperson wird aus dem Standort ermittelt oder eine Meldung wird je Ausgabekanal anders zusammengestellt. Diese Regeln fallen bei einer reinen Feldmigration leicht durch das Raster.

Für jede Anpassung wird deshalb dokumentiert, welches Verhalten erhalten bleiben muss. Dazu gehören Auslöser, Eingabedaten, Ergebnis, Berechtigungen und das Verhalten bei fehlenden oder nicht erreichbaren Daten. Erst danach wird entschieden, wo die Funktion in der Liferay-Architektur hingehört.

Diese Zuordnungen sind Architekturentscheidungen, keine Zusage, dass jede Regel ohne Entwicklung konfiguriert werden kann. Der technische Prototyp muss zeigen, was das Zielrelease bereits abdeckt und welche Erweiterung erforderlich ist. Für jede Funktion wird außerdem bewusst entschieden, ob sie erhalten, vereinfacht oder abgeschafft wird.

8. Medien und Sprachen übernehmen

Bei Bildern und Dokumenten werden möglichst Originaldateien, Dateityp, Prüfsumme und relevante Metadaten exportiert. Ein Vorschaubild von der öffentlichen Website ersetzt kein Original. Liegen Dateien in einem externen DAM, wird entschieden, ob sie dort bleiben oder in Liferay übernommen werden.

Bildgrößen und redaktionelle Ausschnitte sind getrennt zu behandeln. Liferays Adaptive Media kann für Bilder der Document Library unterschiedliche Auflösungen erzeugen. Daraus folgt aber nicht, dass ein in FirstSpirit festgelegter Bildausschnitt automatisch erhalten bleibt. Solche Vorgaben müssen exportiert und in der gewählten Bildausgabe berücksichtigt werden. Quelle: Adaptive Media

Alternativtexte können von der Verwendung des Bildes abhängen. Ein zentraler Dateiname oder Bildtitel ist deshalb kein verlässlicher Ersatz. Der Import übernimmt vorhandene Alt-Texte am jeweiligen Inhaltselement und meldet fehlende Werte zur redaktionellen Prüfung.

Für Sprachen wird eine feste Zuordnung eingerichtet, beispielsweise von einer FirstSpirit-Projektsprache EN zu en_GB oder en_US. Welche Locale richtig ist, entscheidet der tatsächliche Sprach- und Länderkontext. Fehlende Übersetzungen, bewusst sprachübergreifende Felder und Ersatzsprachregeln werden getrennt erfasst. Andernfalls kann englischer Inhalt unbemerkt durch deutsche Texte ersetzt werden.

Auch die URL je Sprache und der Übersetzungsstatus gehören zum Datensatz. Eine vorhandene englische Fassung ist nicht automatisch freigegeben oder vollständig übersetzt.

9. Freigaben und Zugriffsrechte abbilden

Redaktionsrechte, Freigaberechte und Leserechte der Portalnutzer sind drei verschiedene Aufgaben. Aus der Tatsache, dass eine FirstSpirit-Redaktion einen Ordner bearbeiten darf, lässt sich kein öffentliches Leserecht für dessen Dokumente ableiten.

Für Liferay werden Rollen und Zuständigkeiten zunächst als fachliche Matrix beschrieben: Wer darf erstellen, ändern, übersetzen, freigeben und veröffentlichen? Welche Inhalte darf ein anonymer Besucher lesen, welche nur ein angemeldeter Kunde? Anschließend werden diese Regeln mit den Berechtigungen des gewählten CMS und der Site umgesetzt.

Im neuen Liferay CMS wird der Workflow an der Inhaltsstruktur festgelegt, mit möglichen Abweichungen je Space. Ordner tragen dort keine entsprechende Workflow-Konfiguration. Eine bisherige FirstSpirit-Ordnerstruktur kann deshalb nicht einfach als Freigabelogik übernommen werden. Quelle: Workflow im Liferay CMS

Ein FirstSpirit-Freigabeprozess wird fachlich nachgebaut. Laufende Aufgaben und historische Freigabeprotokolle lassen sich nicht allein durch die Übernahme eines Statusfeldes fortsetzen. Für offene Vorgänge wird entschieden: vorher abschließen, kontrolliert neu starten oder dokumentiert archivieren.

Besonders wichtig ist der Importstatus. Ein Entwurf darf nicht dadurch öffentlich werden, dass der technische Importbenutzer weitreichende Rechte besitzt. Geprüft werden deshalb auch direkte Datei-URLs, Suchtreffer, Vorschaubilder und API-Zugriffe mit unterschiedlichen Benutzerrollen.

Den Arbeitsalltag der Redaktion als Abnahmetest verwenden

Ein importierter Inhalt kann vollständig sein und sich trotzdem schlecht bearbeiten lassen. Deshalb werden Redaktionsprozesse bereits bei der Modellierung durchgespielt. Die Beteiligten bearbeiten im Prototyp typische Aufgaben mit ihren vorgesehenen Rollen: eine Meldung anlegen, einen Absatz ergänzen, eine Übersetzung nachreichen, eine Korrektur freigeben und einen Download austauschen.

Besonders aufschlussreich sind die Ausnahmen. Wer übernimmt bei Abwesenheit der freigebenden Person? Was passiert bei einer dringenden Korrektur an bereits veröffentlichtem Inhalt? Muss die englische Fassung auf die deutsche Freigabe warten? Darf eine Redaktion ein gemeinsam genutztes Bild ersetzen, wenn dadurch andere Sites betroffen sind? Diese Entscheidungen gehören in das Prozessmodell, bevor der Massenimport beginnt.

Für jeden Ablauf werden Startzustand, zuständige Rolle, Arbeitsschritte und erwarteter Endzustand festgehalten. Die spätere Abnahme erfolgt mit diesen Szenarien und den tatsächlichen Redaktionsrollen. Eine Demonstration mit einem Administratorkonto würde fehlende Rechte und unpassende Zuständigkeiten verdecken.

Auch die Einführung wird eingeplant: verständliche Feldnamen, Hilfetexte, Schulung an eigenen Inhalten und ein Ansprechpartner für die ersten Veröffentlichungen. Erst wenn die Redaktion ihre Aufgaben selbstständig erledigen kann, ist der neue Arbeitsablauf ausreichend erprobt.

10. Den Import wiederholbar aufbauen

Vor der Umschaltung braucht es mehrere Probeläufe. Der Import muss daher vorhandene Zielobjekte wiederfinden und gezielt aktualisieren können. Bei unterstützten Liferay-Endpunkten eignen sich dafür External Reference Codes. Die Dokumentation nennt die Übernahme eindeutiger Referenzen aus einem Quellsystem ausdrücklich als Anwendungsfall. Quelle: External Reference Codes

Ein sinnvoller Schlüssel enthält Quellsystem, Projekt und Objekttyp sowie eine stabile Quellkennung. Eine numerische ID allein kann bei mehreren Projekten mehrdeutig sein. Änderungen an Projektnamen oder Referenznamen dürfen diese Identität nicht unbeabsichtigt verändern.

Daneben wird eine Zuordnungstabelle geführt: Quellschlüssel, Zielobjekt, Zielbereich, exportierter Stand, Prüfsumme und Ergebnis des letzten Imports. Sie bleibt auch dann erforderlich, wenn einzelne Entitäten keinen geeigneten ERC-Endpunkt besitzen.

Für die objektbasierten CMS-Inhalte werden die verfügbaren Importoperationen anhand des API Explorers unter /o/api geprüft. Payload, Pflichtfelder, Beziehungen, Sprachwerte und Berechtigungen müssen zur OpenAPI-Beschreibung des konkreten Zielsystems passen. Ein Importer für klassische Web Contents ist dafür keine unverändert nutzbare Vorlage.

Für große Mengen kann die Batch Engine geeignet sein, sofern sie die benötigte Entität und Operation unterstützt. Ein angenommener Importauftrag ist noch kein erfolgreicher Datenimport: Abschlussstatus und Einzelfehler müssen ausgewertet werden. Quelle: Liferay Batch Engine

Als konservative Reihenfolge bietet sich an:

1. Zielbereiche, Strukturen, Taxonomien und erforderliche Berechtigungen einrichten.
2. Dateien und unabhängige Inhalte importieren und ihre Zielkennungen speichern.
3. Abhängige Inhalte anlegen; zunächst nicht auflösbare Beziehungen protokollieren.
4. Referenzen in einem weiteren Durchlauf vervollständigen.
5. Seiten, Navigation, Darstellung und URL-Regeln zuordnen.
6. Vollständigkeit, Status und Zugriffsrechte prüfen, bevor Inhalte öffentlich werden.

Diese Reihenfolge lässt sich an die Fähigkeiten des Zielreleases anpassen. Entscheidend ist, dass zyklische Referenzen, fehlgeschlagene Teilimporte und gelöschte Quellobjekte ausdrücklich behandelt werden. Ein zweiter Lauf darf keine Dubletten erzeugen und keine zwischenzeitlich freigegebenen redaktionellen Änderungen unbemerkt überschreiben.

11. URLs, Suche und Auffindbarkeit erhalten

Die Weiterleitungsliste entsteht aus den tatsächlich ausgelieferten FirstSpirit-Adressen. Projektpfade oder Referenznamen allein reichen dafür nicht aus. Einbezogen werden Sprachpfade, Download-URLs, frühere Weiterleitungen und relevante Parameter. Jede alte Adresse erhält eine dokumentierte Entscheidung.

Bestehende URLs können erhalten bleiben, wenn das neue Routing sie unterstützt. Andernfalls wird eine dauerhafte Weiterleitung auf den passenden Nachfolgeinhalt eingerichtet. Nicht mehr benötigte Inhalte werden bewusst entfernt; eine pauschale Weiterleitung aller alten Seiten auf die Startseite hilft weder Nutzern noch der fachlichen Prüfung.

SEO- und Open-Graph-Werte werden als Teil des Inhalts- und Darstellungskonzepts festgelegt. Die Site muss sie aus den vorgesehenen Feldern ausgeben. Geprüft wird das tatsächlich ausgelieferte HTML: Titel, Beschreibung, Canonical-Adresse, Sprachverweise und strukturierte Daten dürfen nicht nur im Importprotokoll korrekt aussehen.

Für die interne Suche wird eine Auswahl bekannter Suchaufgaben vor und nach der Migration verglichen: Finden Nutzer die gesuchte Meldung, einen PDF-Download und einen geschützten Inhalt mit der passenden Rolle? Trefferberechtigungen, Filter, Metadaten und Aktualisierung des Index gehören zur Abnahme.

Öffentliche Fachartikel sollten mit sinnvollen Überschriften, vollständigem Text und erreichbaren internen Links ausgeliefert werden. Das erleichtert auch maschinellen Lesern die Verarbeitung. Eine Übernahme in Suchergebnisse oder KI-Antworten lässt sich damit nicht garantieren. Zugriffsschutz für interne Inhalte bleibt unabhängig davon verbindlich.

12. Abnahme, Umschaltung und Rückfall

Der erste Testimport sollte die schwierigen Fälle enthalten: mehrsprachige Seiten, mehrfach verwendete Inhalte, verschachtelte Absätze, geschützte Dokumente und Referenzen auf externe Daten. Ein erfolgreicher Lauf mit zehn einfachen Textseiten sagt darüber wenig aus.

Für den letzten Lauf wird eine kurze Redaktionssperre oder ein überprüfter Änderungsabgleich vereinbart. Ein solcher Delta-Import muss auch Löschungen, Umbenennungen, verschobene Seitenreferenzen und zurückgezogene Freigaben berücksichtigen. Das reine Änderungsdatum eines Textfeldes genügt dafür nicht.

Nach dem finalen Import folgen Referenzprüfung, Indizierung und fachliche Freigabe. Erst danach werden Domains oder Routing umgeschaltet. Das bisherige System bleibt für den vereinbarten Rückfallzeitraum verfügbar.

Ein Rückfall ist mehr als eine DNS-Änderung. Sobald im neuen Portal Inhalte bearbeitet oder Formulare abgesendet wurden, muss feststehen, was mit diesen Änderungen und Vorgängen passiert. Verantwortliche, Abbruchkriterien und Datenbehandlung gehören deshalb vor dem Start in den Umschaltplan.

13. Den Aufwand belastbar bestimmen

Ein Festpreis allein anhand der Seitenzahl wäre bei einer FirstSpirit-Migration wenig aussagekräftig. Der Aufwand entsteht vor allem durch unterschiedliche Inhaltsmodelle, projektspezifische Vorlagen, Integrationen und die Qualität des Bestands.

Für eine erste Einschätzung benötigt Portalworks eine Übersicht der Projekte und Sprachen, die eingesetzten Versionen und Module, typische Seiten- und Absatzvorlagen sowie Beispiele für besonders komplexe Inhalte. Hinzu kommen Freigabeverfahren, externe Systeme und das geplante Liferay-Zielrelease.

Eine technische Vorprüfung sollte ein kleines, repräsentatives Inhaltsset vollständig übertragen: Export, Transformation, Import, Darstellung und redaktionelle Bearbeitung. Daraus lassen sich belastbare Arbeitspakete ableiten. Noch ungeklärte Sonderfälle bleiben sichtbar, statt in einem pauschalen Aufwandswert zu verschwinden.

Die Wirtschaftlichkeitsrechnung berücksichtigt außerdem die verbleibende Nutzung von FirstSpirit. Werden nach der Portalumstellung noch andere Websites damit betrieben, entfallen dessen Betriebs- und Lizenzkosten nicht automatisch. Einsparungen werden erst angesetzt, wenn die zugehörigen Verträge, Aufgaben oder Komponenten tatsächlich wegfallen.

14. Häufige Fragen zur FirstSpirit-Migration nach Liferay

Können FirstSpirit-Templates direkt übernommen werden?

Die FirstSpirit-spezifische Formular- und Ausgabelogik muss für Liferay neu umgesetzt werden. Wiederverwendbare HTML-, CSS- oder JavaScript-Bestandteile können nach Prüfung übernommen werden. Sie ersetzen weder die neuen Inhaltsstrukturen noch die Anbindung an deren Felder.

Reicht ein Crawl der bestehenden Website?

Für den Vergleich der veröffentlichten Ausgabe und die URL-Inventur ist ein Crawl hilfreich. Redaktionelle Struktur, interne Referenzen, Entwürfe und Freigaberegeln lassen sich daraus nicht zuverlässig rekonstruieren. Für diese Daten werden strukturierte Quellen benötigt.

Muss jeder FirstSpirit-Datensatz ein Web Content werden?

Nein. Ziel sind die passenden Inhaltsstrukturen im objektbasierten Liferay CMS. Fachliche Daten können zudem in eigenen Objects oder einem externen System bleiben. Die Zuordnung richtet sich nach Bearbeitung, Beziehungen und Nutzung.

Kann die Migration schrittweise erfolgen?

Ja, wenn sich Websites, Bereiche oder Inhaltstypen sauber abgrenzen lassen. Für die Übergangszeit braucht es klare Zuständigkeiten für Redaktion, Links, Navigation und Suche. Gemeinsam genutzte Inhalte dürfen nicht unkontrolliert in beiden Systemen auseinanderlaufen.

Werden historische Versionen automatisch übernommen?

Das darf nicht vorausgesetzt werden. Historische Versionen und Freigabeprotokolle benötigen eine eigene Übernahmeregel. Je nach Anforderung werden sie migriert oder in einem nachvollziehbaren Archiv erhalten. Der neue Versionsverlauf entsteht dadurch nicht automatisch identisch.

15. FirstSpirit-Migration mit der Portalworks GmbH

Die Portalworks GmbH ist Liferay-Partner. Bei einer geplanten Ablösung von FirstSpirit übernehmen wir die Konzeption und Umsetzung auf der Liferay-Seite: objektbasierte Inhaltsmodelle, redaktionelle Abläufe, Darstellung und Integrationen. Die Anforderungen an den Quellbestand werden gemeinsam mit den Verantwortlichen für das bestehende System geklärt.

Am Anfang steht eine technische Vorprüfung mit einem repräsentativen Ausschnitt Ihres Bestands. Dabei werden die Anforderungen der Redaktion und die vorhandene individuelle Logik ausdrücklich aufgenommen. Das Ergebnis ist ein Liferay-Zielmodell mit einem geprüften Übertragungsweg, einer Liste der neu umzusetzenden Funktionen und klaren Abnahmekriterien. Auf dieser Grundlage lässt sich entscheiden, ob FirstSpirit vollständig abgelöst, teilweise weiterbetrieben oder dauerhaft integriert werden sollte.

Sie planen den Wechsel von FirstSpirit zu Liferay? Für das erste Fachgespräch sind Ihre FirstSpirit-Version, die betroffenen Projekte, das vorgesehene Liferay-Release und zwei bis drei typische Inhaltsbeispiele besonders hilfreich. Daraus entwickeln wir mit Ihnen die nächsten technischen Schritte. FirstSpirit-Migration mit Portalworks besprechen