Infopark Fiona nach Liferay migrieren: Ablauf und technische Umsetzung - Portal Works

Liferay DXP 2026.Q1 LTS ist da – Jakarta EE, neues CMS & MCP Server Mehr erfahren → Liferay 2026.Q1 LTS →
Liferay 9/18/26, 4:29 PM 4 Min. Lesezeit

Infopark Fiona nach Liferay migrieren: Ablauf und technische Umsetzung

Die Portalworks GmbH zeigt, wie Sie Infopark CMS Fiona nach Liferay migrieren: von der Zuordnung der Objektklassen zu Web Content, Objects und Documents & Media über wiederholbare Datenimporte bis zur Übernahme bestehender URLs und zur geprüften Umschaltung.

Artikelbild

Bei der Migration von Infopark CMS Fiona nach Liferay werden Objektklassen und Felder auf Web-Content-Strukturen, Dokumenttypen oder Liferay Objects abgebildet. Inhalte und Dateien werden exportiert, bereinigt und über die passenden Schnittstellen importiert. Vorlagen, Berechtigungen und Veröffentlichungsregeln werden im Zielsystem eingerichtet; bestehende URLs bleiben erhalten oder werden auf die neuen Inhalte weitergeleitet.

Die Portalworks GmbH begleitet die Migration von Infopark CMS Fiona nach Liferay: von der Analyse des Fiona-Bestands über die Entwicklung des Liferay-Zielmodells bis zum Datenimport und zur Umschaltung. Dabei verbinden wir die Arbeit am Content-Modell mit der Umsetzung von Redaktion, Darstellung und Integrationen in Liferay.

Dieser Leitfaden beschreibt die technische Umsetzung für Verantwortliche aus IT, Webredaktion und Projektleitung. Er zeigt an einer beispielhaften Objektklasse „Meldung“, welche Fiona-Daten wohin gehören und welche Prüfungen vor der Umschaltung erforderlich sind.

Die veröffentlichten HTML-Seiten dienen dabei als Vergleich und, falls nötig, als Datenquelle. Für eine vollständige Übernahme werden jedoch die strukturierten Inhalte aus dem Fiona Content Manager benötigt. Ein Website-Crawl kann interne Metadaten, Arbeitsfassungen und Freigaberegeln nicht vollständig rekonstruieren.

Stand: 18. September 2026. Technische Angaben beziehen sich auf die jeweils verlinkte Produktdokumentation; Schnittstellen und Funktionen sind gegen die eingesetzten Versionen zu prüfen.

Inhalt

1. Fiona-Bestand und Auslieferung erfassen

Fiona verwaltet Inhalte im Content Manager. Objektklassen legen die verfügbaren Felder fest; Layouts und Exportregeln bestimmen die Ausgabe. Bei statischer Veröffentlichung entstehen daraus Dateien für den Webserver. Der Objektpfad ist ein Anhaltspunkt für die öffentliche URL, muss aber zusammen mit der Exportkonfiguration und den tatsächlich ausgelieferten Adressen ausgewertet werden.

Fiona-Installationen können außerdem dynamische Komponenten enthalten. Infopark dokumentiert einen Search Server und die Einbindung dynamischer Suchergebnisse über den Portal Manager. Diese Komponenten und ihr Anwendungscode müssen in der Bestandsaufnahme gesondert erfasst werden. Infopark: System Administration / Development, insbesondere Abschnitt 3.18

Für die Bestandsaufnahme wird je Objektklasse erfasst:

  • Anzahl der Objekte und der tatsächlich veröffentlichten Inhalte;
  • Feldnamen, Datentypen, Pflichtfelder und zulässige Werte;
  • verwendete Layouts, Exportbesonderheiten und eingebundene Skripte;
  • Referenzen auf andere Inhalte, Bilder und Dokumente;
  • Sprachvarianten, Berechtigungen und Freigabeabläufe;
  • öffentliche URLs einschließlich früherer Adressen und vorhandener Weiterleitungen.

Hinzu kommen Dateigrößen, Dokumentformate und die Funktionen außerhalb des CMS: Formularverarbeitung, Suchdienste, Karten, Fachverfahren und Anmeldungen.

Zugriffsprotokolle helfen bei der Priorisierung. Sie entscheiden jedoch nicht allein darüber, ob Inhalte entfallen. Eine selten gelesene Richtlinie kann weiterhin benötigt werden. Ebenso kann eine Objektklasse mit wenigen Instanzen eine eigenständige fachliche Funktion haben. Übernahme, Zusammenlegung und Löschung werden deshalb mit den zuständigen Redaktionen entschieden und je Inhalt dokumentiert.

Ob ein Wechsel wegen auslaufender Wartung notwendig ist, muss anhand der eingesetzten Version und der vereinbarten Hersteller- oder Dienstleisterleistungen geklärt werden. Eine pauschale Aussage über fehlende Sicherheitsupdates ersetzt diese Prüfung nicht.

2. Inhalte aus dem Content Manager extrahieren

Für die Extraktion werden nach Möglichkeit die dokumentierten Fiona-Schnittstellen verwendet. Die Tcl-Schnittstelle stellt unter anderem Zugriffe auf Objekte, Objektklassen und Versionen bereit. Die konkrete Umsetzung richtet sich nach der installierten Version. Freigegebene Inhalte und Arbeitsfassungen müssen dabei getrennt gelesen und gekennzeichnet werden. Fiona führt außerdem Veröffentlichungsgrenzen als validFrom und validUntil. Infopark: Tcl Interface Reference

Der Export für die Migration sollte ein dokumentiertes Zwischenformat erzeugen, beispielsweise JSON für strukturierte Daten und separate Dateien für Binärinhalte. Für jeden Datensatz werden Quell-ID, Objektklasse, Pfad, Versionsstatus, Feldwerte und Referenzen gespeichert. Ein Inhalts-Hash hilft später, Änderungen zwischen zwei Exporten zu erkennen.

Direkte Datenbankabfragen kommen erst infrage, wenn die unterstützten Schnittstellen nicht ausreichen und das interne Schema zuverlässig verstanden ist. Eine Abfrage, die zwar Textfelder liefert, aber Versionen oder Referenzen falsch zuordnet, erzeugt schwer erkennbare Fehler.

Zusätzlich wird die veröffentlichte Website gesichert und gecrawlt. Sie dient als Vergleich für Texte, Downloads, Navigation und URLs. Der Crawl wird mit Exportverzeichnissen, Sitemaps und Zugriffsprotokollen abgeglichen: Nicht verlinkte Seiten werden durch einen gewöhnlichen Crawl nicht zuverlässig gefunden.

Ist der Content Manager nicht mehr zugänglich, müssen Felder aus dem HTML rekonstruiert werden. Dafür werden die vorhandenen Seitenvarianten untersucht und passende Extraktionsregeln erstellt. Unterschiedliche Vorlagen, manuell eingebautes HTML und historische Sonderseiten brauchen eigene Regeln. Nicht rekonstruierbare Angaben, etwa Freigabestatus oder interne Metadaten, werden als fehlend ausgewiesen.

3. Objektklassen und Felder in Liferay abbilden

Die folgenden Beispiele verwenden Liferays etabliertes Web Content, Documents & Media und Liferay Objects. Das ab DXP 2026.Q3 dokumentierte neue Liferay CMS besitzt ein eigenes Modell für Content- und File-Strukturen. Dessen Strukturen und APIs dürfen nicht mit den hier beschriebenen Web-Content-Strukturen gleichgesetzt werden. Liferay: Content Structures

In Fiona hängen Ablage, Inhalt und Seitenausgabe häufig eng zusammen. In Liferay werden diese Aufgaben getrennt geplant: Web Content verwaltet redaktionelle Inhalte, Seiten und Navigation bestimmen deren Einordnung, Display Page Templates deren Detaildarstellung.

Für eine beispielhafte Fiona-Objektklasse „Meldung“ kann die Zuordnung so aussehen. Die Feldnamen sind illustrative Projektfelder und keine vorgegebenen Fiona-Standardfelder.

Beispiel: Fiona-Objektklasse „Meldung“ in Liferay abbilden
Bestandteil in Fiona Umsetzung in Liferay Festlegung für die Migration
Objektklasse „Meldung“ Web-Content-Struktur „Meldung“ Feldtypen, Pflichtfelder und Übersetzbarkeit definieren
Titel Titel des Web-Content-Artikels Sprachvarianten zuordnen
Einleitung Strukturfeld „Einleitung“ Als einfachen Text oder Rich Text festlegen
Hauptinhalt Rich-Text-Feld „Text“ HTML bereinigen und interne Links ersetzen
Bildreferenz Bildfeld mit Bezug auf das importierte Bild Zielreferenz nach dem Dateiimport setzen
PDF-Anhang Dokumentreferenz in einem passenden Strukturfeld Auf den Eintrag in Documents & Media beziehen
Thematische Zuordnung Kategorie im Vokabular „Themen“ Alte Werte auf stabile Kategorien abbilden
Layout für die Detailansicht Display Page Template für die Struktur Felder mit den bearbeitbaren Elementen der Fragmente verbinden
Bisherige Adresse Neue Inhaltsadresse plus URL-Zuordnung Alte Adresse erhalten oder weiterleiten

Liferay-Strukturen unterstützen unter anderem Textfelder, Auswahlfelder und wiederholbare Feldgruppen. Eine Liste mehrerer Downloads muss deshalb nicht in einen einzigen HTML-Block geschrieben werden. Sie kann als wiederholbare Gruppe aus Dokumentreferenz und Beschriftung modelliert werden. Liferay: Web Content Structures

Das Display Page Template wird für den Inhaltstyp beziehungsweise die Struktur eingerichtet. Es stellt die Felder eines Artikels unter dessen Detailadresse dar. Für einzelne Meldungen muss dadurch keine separat gestaltete Inhaltsseite angelegt werden. Übersichtsseiten können die Meldungen über Collections und Collection Displays zusammenstellen. Liferay: Using Display Page Templates

Wann Liferay Objects sinnvoll sind

Objects eignen sich für Datensätze mit eigenen Beziehungen, Validierungen und Bearbeitungsprozessen. Ein mögliches Modell besteht aus den Objects „Dienststelle“ und „Ansprechpartner“ mit einer Beziehung zwischen beiden. Name, Kontaktdaten und Zuständigkeit werden dann als Felder gespeichert, statt in mehreren Artikeln kopiert zu werden.

Filterbarkeit oder API-Zugriff allein sind kein Grund für Objects: Auch Web Content lässt sich strukturiert abrufen und durchsuchen. Eine Veranstaltung kann deshalb als Web Content gepflegt werden, während Anmeldungen in einem Object oder einem externen Buchungssystem liegen. Entscheidend sind die benötigten Beziehungen und Abläufe.

Für veröffentlichte benutzerdefinierte Objects erzeugt Liferay REST-Schnittstellen. Deren Pfade und verfügbare Operationen hängen unter anderem vom Geltungsbereich des Objects ab. Beziehungen lassen sich über eigene Endpunkte verwalten. Liferay: Accessing Object via Headless APIs

Auswahlfelder und Dokumentmetadaten

Ein Fiona-Auswahlfeld wird nach seiner Bedeutung übertragen. Themen und Zielgruppen können Kategorien in Liferay-Vokabularen werden. Ein lokales Auswahlfeld wie „Darstellungsvariante“ bleibt dagegen ein Feld der Web-Content-Struktur. Für feste Auswahllisten in Objects stehen Picklists zur Verfügung. Technische Schlüssel und angezeigte Bezeichnungen werden dabei getrennt zugeordnet. Liferay: Creating Picklists

PDFs, Bilder und andere Dateien werden nach Documents & Media übernommen. Ein Dokumenttyp „Merkblatt“ kann beispielsweise Aktenzeichen, zuständige Stelle und fachliches Gültigkeitsdatum enthalten. Wiederverwendbare Feldgruppen werden als Metadata Sets definiert und Dokumenttypen zugewiesen. Liferay: Defining Metadata Sets

Ein Metadatenfeld „gültig bis“ sperrt einen Download allerdings nicht automatisch. Soll eine Datei ab einem bestimmten Zeitpunkt nicht mehr erreichbar sein, muss dieses Verhalten gesondert umgesetzt und auch beim direkten Dateiaufruf geprüft werden.

4. Veröffentlichung, Sprachen und Berechtigungen übernehmen

Für Web Content werden die bisherigen Veröffentlichungsgrenzen auf Anzeige- und Ablaufdatum abgebildet. Vor dem Import sind Zeitzone, leere Werte und bereits abgelaufene Inhalte festzulegen. Ein fachliches Datum, etwa das Ende einer Antragsfrist, bleibt ein eigenes Inhaltsfeld, wenn die Seite danach weiterhin lesbar sein soll.

Arbeitsfassungen werden separat behandelt. Eine mögliche Vereinbarung lautet: Freigegebene Fassungen bilden den öffentlichen Ausgangsbestand; offene Entwürfe werden zusätzlich als Entwürfe übernommen oder vor der Umschaltung redaktionell abgeschlossen. Der Import darf nicht versehentlich die neueste Arbeitsfassung veröffentlichen.

Sprachvarianten brauchen eine explizite Zuordnung. Werden deutsche und englische Inhalte in getrennten Fiona-Bäumen gepflegt, muss entschieden werden, welche davon Übersetzungen desselben Inhalts sind. Erst dann können sie als Sprachvarianten eines Liferay-Artikels zusammengeführt werden.

Die bisherigen Zugriffsregeln werden auf Liferay-Rollen und Ressourcenberechtigungen abgebildet. Geprüft werden Seiten, Inhalte und Dateien jeweils für Gäste sowie für die vorgesehenen Benutzergruppen. Eine ausgeblendete Navigation ist kein Zugriffsschutz. Die Abnahme muss deshalb auch direkte URLs, Downloads und API-Zugriffe einschließen.

Rich-Text-Inhalte werden vor dem Import mit einem HTML-Parser verarbeitet. Die Regeln legen fest, welche Elemente und Attribute erhalten bleiben. Veraltete Schriftformatierungen, Word-Markup und unnötige Inline-Styles können entfernt werden. Datentabellen müssen dabei von Tabellen unterschieden werden, die lediglich das Layout erzeugen.

Interne Links werden zunächst auf ihr altes Ziel aufgelöst. Ein relativer Verweis wie ../formulare/antrag.pdf erhält erst durch die Adresse seiner Quellseite eine eindeutige Bedeutung. Anschließend wird das Ziel über die Migrationstabelle der passenden Liferay-Datei oder dem neuen Inhalt zugeordnet. URL-Fragmente wie #voraussetzungen müssen auf vorhandene Anker im neuen Inhalt zeigen.

Nicht auflösbare Verweise werden protokolliert. Sie dürfen nicht stillschweigend auf die Startseite oder eine beliebige Übersichtsseite umgebogen werden.

Auch Überschriften, Linkbeschriftungen und Alternativtexte werden geprüft. Ein fett gesetzter Absatz ist nicht automatisch eine Überschrift; ein Bild braucht je nach Verwendung einen beschreibenden Alternativtext oder eine Kennzeichnung als dekoratives Bild. Solche Entscheidungen benötigen redaktionellen Kontext. Die Transformationsstrecke kann Auffälligkeiten erkennen und Vorschläge liefern, aber nicht jede Korrektur selbstständig entscheiden.

6. Den Import wiederholbar aufbauen

Zunächst werden Zielmodelle und Konfigurationen eingerichtet: Strukturen, Dokumenttypen, Vokabulare, Picklists, Object-Definitionen sowie Darstellungs- und Seitenvorlagen. Danach folgen Dateien und Inhalte. Beziehungen werden gesetzt, sobald die referenzierten Ziele vorhanden sind; gegenseitige Verweise lassen sich in einem zweiten Durchlauf ergänzen.

Für Web Content und Dokumente werden die passenden Headless-Delivery-Operationen genutzt, für Objects die Object-APIs. Die tatsächlich verfügbaren Methoden werden im API Explorer der Zielinstallation unter /o/api geprüft und gegen deren OpenAPI-Beschreibung implementiert.

Der dokumentierte Aufruf GET /o/headless-delivery/v1.0/sites/{siteId}/content-structures liest Web-Content-Strukturen. Er ist kein allgemeiner Endpunkt zum Anlegen von Strukturen. Deren Bereitstellung wird über einen für die Zielversion unterstützten Import- oder Administrationsweg gelöst. Liferay: Managing Web Content Structures and Templates by Using the REST API

Jeder importierte Datensatz bekommt eine stabile Herkunftskennung, beispielsweise fiona-prod-4711. Wo der Zieltyp und seine API External Reference Codes unterstützen, kann diese Kennung dafür verwendet werden. Zusätzlich führt der Import eine Zuordnung aus Quellsystem, Quell-ID, Zieltyp, Ziel-ID und Zieladresse. Object-Beziehungen können auch über External Reference Codes verknüpft werden. Liferay: Using Relationship REST APIs

Ein erneuter Lauf aktualisiert vorhandene Datensätze, statt Duplikate anzulegen. Das Verfahren muss außerdem Entfernungen, zurückgezogene Freigaben und fehlgeschlagene Importe behandeln. Ein Delta-Import besteht daher nicht nur aus dem Nachladen geänderter Texte.

Die Importprotokolle weisen für jede Quell-ID aus, ob der Datensatz übernommen, aktualisiert, bewusst ausgeschlossen oder mit Fehler abgewiesen wurde. Für unverändert übernommene Dateien werden Prüfsummen verglichen; für Inhalte unter anderem Pflichtfelder, Sprachvarianten, Referenzen und Veröffentlichungsstatus.

7. URLs und Weiterleitungen festlegen

Für jede bekannte öffentliche Adresse wird eine Entscheidung dokumentiert: unverändert erreichbar, dauerhaft weitergeleitet oder entfallen. Dabei werden neben HTML-Seiten auch Downloads und ältere URL-Varianten berücksichtigt.

Aus /bildung/landwirt/index.htm kann beispielsweise /bildung/landwirt werden. Das ist eine Projektentscheidung, keine zwingende Liferay-Regel. Ob der alte Pfad einschließlich Dateiendung direkt weiterverwendet werden kann, hängt vom Routing in Liferay und im vorgeschalteten Webserver ab.

Weiterleitungen werden in Liferays Redirection-Anwendung oder am Reverse Proxy beziehungsweise Webserver eingerichtet. Liferay unterstützt explizite Alias-Zuordnungen und versionsabhängig auch Musterregeln. Welche Ebene verwendet wird, richtet sich nach dem Routing und der späteren Pflege der Regeln. Liferay: Managing Site URLs

Ein zusammengelegter Inhalt wird mit HTTP 301 auf seinen fachlichen Nachfolger weitergeleitet. Für einen ersatzlos entfernten Inhalt wird ein passender Fehlerstatus wie 404 oder 410 vorgesehen. Eine thematisch unpassende Elternseite ist kein verlässlicher Ersatz.

Der automatisierte URL-Test prüft Statuscodes, Zieladressen, Schleifen und Weiterleitungsketten. Bei übernommenen Inhalten muss zusätzlich geprüft werden, ob das Ziel tatsächlich den erwarteten Inhalt liefert. Auch Canonical-Angaben, interne Links und Sitemaps werden auf die neuen Adressen abgestimmt. Eine unveränderte Platzierung in Suchmaschinen lässt sich damit nicht garantieren.

8. Frontend, Suche und Fachverfahren umsetzen

Fiona-Layouts werden nach ihrer jeweiligen Aufgabe aufgeteilt. Die Ausgabe eines strukturierten Artikels kann über ein Web-Content-Template oder ein Display Page Template erfolgen. Wiederkehrende Oberflächenelemente werden als Fragmente umgesetzt. Gemeinsame Seitenrahmen gehören in Master Page Templates; Seitenvorlagen definieren Ausgangslayouts für neue Seiten.

Farben, Abstände und Typografie können über Style Books gepflegt werden. Welche Werte dort verfügbar sind, hängt von den Frontend-Tokens des verwendeten Themes oder der Theme CSS Client Extension ab. Individuelle Komponenten müssen diese Werte auch verwenden, damit Änderungen wirksam werden. Liferay: Using a Style Book to Standardize Site Appearance

Barrierefreiheit wird an Komponenten und an vollständigen Seiten geprüft. Ein zugängliches Fragment verhindert keine falsche Überschriftenfolge oder unverständliche Linktexte in der zusammengestellten Seite. Formulare, Fehlermeldungen, Tastaturbedienung und die übernommenen Dokumente gehören deshalb in die Abnahme. PDFs werden durch den Import nach Documents & Media nicht automatisch barrierefrei.

Für die Suche wird eine zur Liferay-Version passende Suchmaschine betrieben, beispielsweise Elasticsearch. Suchseiten werden mit Trefferlisten und den benötigten Facetten eingerichtet. Die Standard-Suchergebnisse berücksichtigen die Leseberechtigungen der Benutzer. Ein eigener Suchindex benötigt dennoch Betrieb, Überwachung und eine passende Konfiguration. Liferay: Search Overview, Liferay: Search Results

Für Dokumente wird geprüft, ob ihr Text tatsächlich extrahiert und gefunden wird. Ein gescanntes PDF benötigt gegebenenfalls OCR. Object-Einträge müssen mit geeigneten Suchfeldern, Berechtigungen und einer brauchbaren Trefferansicht eingebunden werden.

Formulare werden je nach Zielversion und Anforderung mit Forms, Object-Formularen oder einer eigenen Anwendung umgesetzt. Eine Antragsstrecke braucht zusätzlich Regeln für Validierung, Speicherung, Zuständigkeit, Rückfragen und Statusanzeige. Diese Abläufe entstehen nicht allein durch das Anlegen eines Objects.

Bestehende Fachverfahren können eigenständig bleiben und über APIs angebunden werden. Für eine gemeinsame Anmeldung werden Liferay und Fachverfahren an einen geeigneten Identity Provider angeschlossen. Liferay unterstützt unter anderem SAML und OpenID Connect; Benutzerzuordnung und Berechtigungen müssen separat festgelegt werden. Liferay: Configuring Single Sign-On

Eine API stellt Daten und Funktionen bereit, aber keine fertige eingebettete Oberfläche. Soll das Fachverfahren innerhalb einer Liferay-Seite bedient werden, ist dafür eine passende Oberflächenintegration nötig. Auch ein Liferay Style Book gestaltet eine externe Anwendung nicht automatisch mit; gemeinsame Gestaltungsvorgaben müssen dort ebenfalls umgesetzt werden.

Abnahme und Umschaltung

Vor der Umschaltung wird ein vollständiger Probelauf durchgeführt. Die Abnahme umfasst Datenbestand, Links, Berechtigungen, Suche, Darstellung und die vereinbarten Fachprozesse. Redaktionen prüfen dabei nicht nur die Startseite, sondern typische und schwierige Fälle aus jeder Inhaltsklasse.

Der Ablauf für die Produktivsetzung wird vorher festgelegt: Redaktionsstopp, letzter Export, Verarbeitung der Änderungen und Löschungen, Import, Prüfung, Routing-Umschaltung und Aktivierung der Weiterleitungen. Dazu gehört ein Rückfallverfahren mit klaren Kriterien. Die benötigte Zeit ergibt sich aus gemessenen Probeläufen.

Schulungen beginnen vor diesem Termin. Redakteure pflegen strukturierte Inhalte weiterhin über Eingabemasken; ausgewählte Seiten können zusätzlich im Seiteneditor bearbeitet werden. Welche Arbeitsweise vorgesehen ist, wird anhand der Aufgaben und Berechtigungen festgelegt.

Nach der Umschaltung werden Importfehler, nicht gefundene URLs, Suchtreffer und wichtige Formularabläufe überwacht. Fiona wird erst außer Betrieb genommen, wenn die vereinbarten Daten und Konfigurationen gesichert und die Abnahmekriterien erfüllt sind.

Was bestimmt den Aufwand einer Fiona-Migration?

Für die Kalkulation werden Anzahl und Unterschiede der Objektklassen, Datenqualität, Dokumentbestand, Sprachen, Integrationen und Prüfaufwand erfasst. Auch Seitenzahl und Datenvolumen spielen eine Rolle: Sie beeinflussen Laufzeiten, redaktionelle Nacharbeit und Abnahme. Eine feste Stichprobengröße oder eine pauschale Zahl von Importläufen liefert dafür keine belastbare Grundlage.

Wo KI bei der Migration helfen kann

KI kann bei der Analyse unbekannter HTML-Varianten, bei Feldzuordnungen und bei Textvorschlägen helfen. Für wiederkehrende Extraktionen werden daraus nachvollziehbare Regeln entwickelt und an unterschiedlichen Seiten geprüft. Objekt-IDs, Datumswerte, Freigaben, Referenzen und Prüfsummen werden durch fest definierte Programme verarbeitet und abgeglichen. Vorgeschlagene Alternativtexte und fachliche Änderungen brauchen eine redaktionelle Prüfung.

Häufige Fragen zur Migration von Fiona nach Liferay

Lassen sich die bisherigen Fiona-URLs beibehalten?

Ja, soweit das Routing der Zielumgebung die bisherigen Pfade unterstützt. Ändert sich eine Adresse, wird die alte URL auf den fachlich entsprechenden Nachfolger weitergeleitet. Diese Zuordnung muss auch PDF-Downloads und andere Dateien berücksichtigen. Das Entfernen der Endung .htm ist keine Voraussetzung für die Migration.

Ist eine Migration ohne Zugriff auf den Fiona Content Manager möglich?

Ja. Veröffentlichte Texte, Bilder und Downloads lassen sich aus einem Dateiexport oder einem Crawl übernehmen. Die Feldstruktur muss dann aus dem HTML rekonstruiert werden. Nicht veröffentlichte Entwürfe, interne Metadaten und Freigabeinformationen lassen sich daraus nicht zuverlässig gewinnen. Der fehlende Repository-Zugriff erhöht deshalb den Analyse- und Prüfaufwand.

Wann verwendet man Web Content und wann Liferay Objects?

Web Content eignet sich für redaktionelle Inhalte wie Meldungen, Fachartikel und Veranstaltungsbeschreibungen. Objects eignen sich für Datensätze mit eigenen Beziehungen, Validierungen und Bearbeitungsprozessen, etwa Anmeldungen oder verknüpfte Dienststellen und Ansprechpartner. Die Entscheidung richtet sich nach der Nutzung der Daten. API-Zugriff und Filterbarkeit sind auch mit Web Content möglich.

Was passiert mit PDFs und ihren Metadaten?

Dateien werden nach Documents & Media importiert. Angaben wie Aktenzeichen oder zuständige Stelle werden in Feldern des Dokumenttyps beziehungsweise zugeordneten Metadata Sets gespeichert. Links auf die Dateien werden aktualisiert. Die Barrierefreiheit des PDF-Inhalts muss unabhängig vom Import geprüft und gegebenenfalls überarbeitet werden.

Muss die Website während der Migration offline gehen?

Fiona kann während des Aufbaus der Liferay-Umgebung weiter ausliefern. Für den abschließenden Datenabgleich wird in der Regel ein Redaktionsstopp vereinbart. Seine Dauer und eine mögliche Unterbrechung bei der Umschaltung hängen vom Importverfahren und der Infrastruktur ab und werden im Probelauf ermittelt.

Wie lässt sich der Aufwand belastbar schätzen?

Die Schätzung braucht ein Inventar der Objektklassen, Inhalte, Dateien, Sprachen und Integrationen sowie repräsentative Testimporte. Bewertet werden auch HTML-Qualität, Berechtigungen, URL-Sonderfälle und redaktionelle Nacharbeiten. Die Seitenzahl allein reicht für eine Kalkulation nicht aus.

Fiona-Migration mit der Portalworks GmbH

Die Portalworks GmbH ist Ihr technischer Ansprechpartner für die Migration von Infopark CMS Fiona nach Liferay. Wir übersetzen die gewachsenen Fiona-Objektklassen, Exportregeln und Verknüpfungen in ein Liferay-Modell, das zu Ihren Inhalten und redaktionellen Abläufen passt. Dazu gehört die Entscheidung, welche Informationen als Web Content, als Object oder als Dokument mit Metadaten gepflegt werden und wie sie auf den Seiten erscheinen.

Unsere Arbeit umfasst die technischen Aufgaben der Migration:

  • Fiona analysieren: Wir erfassen Objektklassen, Felder, Vorlagen, Veröffentlichungsregeln und Schnittstellen. An repräsentativen Inhalten prüfen wir, wie sich die Daten vollständig und reproduzierbar extrahieren lassen.
  • Liferay modellieren und einrichten: Wir definieren Strukturen, Dokumenttypen, Beziehungen und Taxonomien und setzen die benötigten Darstellungen, Rollen und Freigabeabläufe um.
  • Die Migrationsstrecke entwickeln: Wir bauen Extraktion, HTML-Bereinigung und Import so auf, dass Testläufe wiederholt und Änderungen bis zur Umschaltung nachgezogen werden können. Quell-IDs und Importprotokolle machen die Übernahme nachvollziehbar.
  • Verweise und Funktionen erhalten: Wir ordnen alte URLs ihren Zielen zu, übernehmen Dokumentverknüpfungen und binden Suche sowie benötigte Fachverfahren in die neue Umgebung ein.
  • Abnahme und Umschaltung begleiten: Wir prüfen Daten, Links und Berechtigungen anhand vereinbarter Kriterien, bereiten den abschließenden Import vor und unterstützen die Redaktion beim Wechsel.

Bereits in der Analyse bearbeiten wir konkrete Fälle aus Ihrem Bestand: Wie wird eine Fiona-Objektklasse mit mehreren Layoutvarianten in Liferay dargestellt? Was passiert mit zeitgesteuerten Veröffentlichungen? Wie bleiben Verweise aus bestehenden PDFs erreichbar? Die Antworten fließen in die Feldzuordnung, das URL-Konzept und die Abnahmekriterien ein.

Sie planen die Ablösung von Fiona? Sprechen Sie mit der Portalworks GmbH über Ihren Bestand und die Anforderungen an Liferay. Für die erste technische Bewertung sind Angaben zur Fiona-Version, eine Übersicht der Objektklassen, typische Seiten und Dokumente sowie Informationen zu angebundenen Anwendungen hilfreich. Daraus entwickeln wir mit Ihnen das Zielmodell, den Migrationsplan und eine nachvollziehbare Aufwandsschätzung.

Fragen dazu?

Marc Hermann antwortet persönlich – kein Vertriebsteam, kein Formularautomatismus.

Liferay 6. April 2026 4 Min. Lesezeit

Infopark Fiona nach Liferay migrieren: Ablauf und technische Umsetzung

Die Portalworks GmbH zeigt, wie Sie Infopark CMS Fiona nach Liferay migrieren: von der Zuordnung der Objektklassen zu Web Content, Objects und Documents & Media über wiederholbare Datenimporte bis zur Übernahme bestehender URLs und zur geprüften Umschaltung.

Artikelbild

Bei der Migration von Infopark CMS Fiona nach Liferay werden Objektklassen und Felder auf Web-Content-Strukturen, Dokumenttypen oder Liferay Objects abgebildet. Inhalte und Dateien werden exportiert, bereinigt und über die passenden Schnittstellen importiert. Vorlagen, Berechtigungen und Veröffentlichungsregeln werden im Zielsystem eingerichtet; bestehende URLs bleiben erhalten oder werden auf die neuen Inhalte weitergeleitet.

Die Portalworks GmbH begleitet die Migration von Infopark CMS Fiona nach Liferay: von der Analyse des Fiona-Bestands über die Entwicklung des Liferay-Zielmodells bis zum Datenimport und zur Umschaltung. Dabei verbinden wir die Arbeit am Content-Modell mit der Umsetzung von Redaktion, Darstellung und Integrationen in Liferay.

Dieser Leitfaden beschreibt die technische Umsetzung für Verantwortliche aus IT, Webredaktion und Projektleitung. Er zeigt an einer beispielhaften Objektklasse „Meldung“, welche Fiona-Daten wohin gehören und welche Prüfungen vor der Umschaltung erforderlich sind.

Die veröffentlichten HTML-Seiten dienen dabei als Vergleich und, falls nötig, als Datenquelle. Für eine vollständige Übernahme werden jedoch die strukturierten Inhalte aus dem Fiona Content Manager benötigt. Ein Website-Crawl kann interne Metadaten, Arbeitsfassungen und Freigaberegeln nicht vollständig rekonstruieren.

Stand: 18. September 2026. Technische Angaben beziehen sich auf die jeweils verlinkte Produktdokumentation; Schnittstellen und Funktionen sind gegen die eingesetzten Versionen zu prüfen.

Inhalt

1. Fiona-Bestand und Auslieferung erfassen

Fiona verwaltet Inhalte im Content Manager. Objektklassen legen die verfügbaren Felder fest; Layouts und Exportregeln bestimmen die Ausgabe. Bei statischer Veröffentlichung entstehen daraus Dateien für den Webserver. Der Objektpfad ist ein Anhaltspunkt für die öffentliche URL, muss aber zusammen mit der Exportkonfiguration und den tatsächlich ausgelieferten Adressen ausgewertet werden.

Fiona-Installationen können außerdem dynamische Komponenten enthalten. Infopark dokumentiert einen Search Server und die Einbindung dynamischer Suchergebnisse über den Portal Manager. Diese Komponenten und ihr Anwendungscode müssen in der Bestandsaufnahme gesondert erfasst werden. Infopark: System Administration / Development, insbesondere Abschnitt 3.18

Für die Bestandsaufnahme wird je Objektklasse erfasst:

  • Anzahl der Objekte und der tatsächlich veröffentlichten Inhalte;
  • Feldnamen, Datentypen, Pflichtfelder und zulässige Werte;
  • verwendete Layouts, Exportbesonderheiten und eingebundene Skripte;
  • Referenzen auf andere Inhalte, Bilder und Dokumente;
  • Sprachvarianten, Berechtigungen und Freigabeabläufe;
  • öffentliche URLs einschließlich früherer Adressen und vorhandener Weiterleitungen.

Hinzu kommen Dateigrößen, Dokumentformate und die Funktionen außerhalb des CMS: Formularverarbeitung, Suchdienste, Karten, Fachverfahren und Anmeldungen.

Zugriffsprotokolle helfen bei der Priorisierung. Sie entscheiden jedoch nicht allein darüber, ob Inhalte entfallen. Eine selten gelesene Richtlinie kann weiterhin benötigt werden. Ebenso kann eine Objektklasse mit wenigen Instanzen eine eigenständige fachliche Funktion haben. Übernahme, Zusammenlegung und Löschung werden deshalb mit den zuständigen Redaktionen entschieden und je Inhalt dokumentiert.

Ob ein Wechsel wegen auslaufender Wartung notwendig ist, muss anhand der eingesetzten Version und der vereinbarten Hersteller- oder Dienstleisterleistungen geklärt werden. Eine pauschale Aussage über fehlende Sicherheitsupdates ersetzt diese Prüfung nicht.

2. Inhalte aus dem Content Manager extrahieren

Für die Extraktion werden nach Möglichkeit die dokumentierten Fiona-Schnittstellen verwendet. Die Tcl-Schnittstelle stellt unter anderem Zugriffe auf Objekte, Objektklassen und Versionen bereit. Die konkrete Umsetzung richtet sich nach der installierten Version. Freigegebene Inhalte und Arbeitsfassungen müssen dabei getrennt gelesen und gekennzeichnet werden. Fiona führt außerdem Veröffentlichungsgrenzen als validFrom und validUntil. Infopark: Tcl Interface Reference

Der Export für die Migration sollte ein dokumentiertes Zwischenformat erzeugen, beispielsweise JSON für strukturierte Daten und separate Dateien für Binärinhalte. Für jeden Datensatz werden Quell-ID, Objektklasse, Pfad, Versionsstatus, Feldwerte und Referenzen gespeichert. Ein Inhalts-Hash hilft später, Änderungen zwischen zwei Exporten zu erkennen.

Direkte Datenbankabfragen kommen erst infrage, wenn die unterstützten Schnittstellen nicht ausreichen und das interne Schema zuverlässig verstanden ist. Eine Abfrage, die zwar Textfelder liefert, aber Versionen oder Referenzen falsch zuordnet, erzeugt schwer erkennbare Fehler.

Zusätzlich wird die veröffentlichte Website gesichert und gecrawlt. Sie dient als Vergleich für Texte, Downloads, Navigation und URLs. Der Crawl wird mit Exportverzeichnissen, Sitemaps und Zugriffsprotokollen abgeglichen: Nicht verlinkte Seiten werden durch einen gewöhnlichen Crawl nicht zuverlässig gefunden.

Ist der Content Manager nicht mehr zugänglich, müssen Felder aus dem HTML rekonstruiert werden. Dafür werden die vorhandenen Seitenvarianten untersucht und passende Extraktionsregeln erstellt. Unterschiedliche Vorlagen, manuell eingebautes HTML und historische Sonderseiten brauchen eigene Regeln. Nicht rekonstruierbare Angaben, etwa Freigabestatus oder interne Metadaten, werden als fehlend ausgewiesen.

3. Objektklassen und Felder in Liferay abbilden

Die folgenden Beispiele verwenden Liferays etabliertes Web Content, Documents & Media und Liferay Objects. Das ab DXP 2026.Q3 dokumentierte neue Liferay CMS besitzt ein eigenes Modell für Content- und File-Strukturen. Dessen Strukturen und APIs dürfen nicht mit den hier beschriebenen Web-Content-Strukturen gleichgesetzt werden. Liferay: Content Structures

In Fiona hängen Ablage, Inhalt und Seitenausgabe häufig eng zusammen. In Liferay werden diese Aufgaben getrennt geplant: Web Content verwaltet redaktionelle Inhalte, Seiten und Navigation bestimmen deren Einordnung, Display Page Templates deren Detaildarstellung.

Für eine beispielhafte Fiona-Objektklasse „Meldung“ kann die Zuordnung so aussehen. Die Feldnamen sind illustrative Projektfelder und keine vorgegebenen Fiona-Standardfelder.

Beispiel: Fiona-Objektklasse „Meldung“ in Liferay abbilden
Bestandteil in Fiona Umsetzung in Liferay Festlegung für die Migration
Objektklasse „Meldung“ Web-Content-Struktur „Meldung“ Feldtypen, Pflichtfelder und Übersetzbarkeit definieren
Titel Titel des Web-Content-Artikels Sprachvarianten zuordnen
Einleitung Strukturfeld „Einleitung“ Als einfachen Text oder Rich Text festlegen
Hauptinhalt Rich-Text-Feld „Text“ HTML bereinigen und interne Links ersetzen
Bildreferenz Bildfeld mit Bezug auf das importierte Bild Zielreferenz nach dem Dateiimport setzen
PDF-Anhang Dokumentreferenz in einem passenden Strukturfeld Auf den Eintrag in Documents & Media beziehen
Thematische Zuordnung Kategorie im Vokabular „Themen“ Alte Werte auf stabile Kategorien abbilden
Layout für die Detailansicht Display Page Template für die Struktur Felder mit den bearbeitbaren Elementen der Fragmente verbinden
Bisherige Adresse Neue Inhaltsadresse plus URL-Zuordnung Alte Adresse erhalten oder weiterleiten

Liferay-Strukturen unterstützen unter anderem Textfelder, Auswahlfelder und wiederholbare Feldgruppen. Eine Liste mehrerer Downloads muss deshalb nicht in einen einzigen HTML-Block geschrieben werden. Sie kann als wiederholbare Gruppe aus Dokumentreferenz und Beschriftung modelliert werden. Liferay: Web Content Structures

Das Display Page Template wird für den Inhaltstyp beziehungsweise die Struktur eingerichtet. Es stellt die Felder eines Artikels unter dessen Detailadresse dar. Für einzelne Meldungen muss dadurch keine separat gestaltete Inhaltsseite angelegt werden. Übersichtsseiten können die Meldungen über Collections und Collection Displays zusammenstellen. Liferay: Using Display Page Templates

Wann Liferay Objects sinnvoll sind

Objects eignen sich für Datensätze mit eigenen Beziehungen, Validierungen und Bearbeitungsprozessen. Ein mögliches Modell besteht aus den Objects „Dienststelle“ und „Ansprechpartner“ mit einer Beziehung zwischen beiden. Name, Kontaktdaten und Zuständigkeit werden dann als Felder gespeichert, statt in mehreren Artikeln kopiert zu werden.

Filterbarkeit oder API-Zugriff allein sind kein Grund für Objects: Auch Web Content lässt sich strukturiert abrufen und durchsuchen. Eine Veranstaltung kann deshalb als Web Content gepflegt werden, während Anmeldungen in einem Object oder einem externen Buchungssystem liegen. Entscheidend sind die benötigten Beziehungen und Abläufe.

Für veröffentlichte benutzerdefinierte Objects erzeugt Liferay REST-Schnittstellen. Deren Pfade und verfügbare Operationen hängen unter anderem vom Geltungsbereich des Objects ab. Beziehungen lassen sich über eigene Endpunkte verwalten. Liferay: Accessing Object via Headless APIs

Auswahlfelder und Dokumentmetadaten

Ein Fiona-Auswahlfeld wird nach seiner Bedeutung übertragen. Themen und Zielgruppen können Kategorien in Liferay-Vokabularen werden. Ein lokales Auswahlfeld wie „Darstellungsvariante“ bleibt dagegen ein Feld der Web-Content-Struktur. Für feste Auswahllisten in Objects stehen Picklists zur Verfügung. Technische Schlüssel und angezeigte Bezeichnungen werden dabei getrennt zugeordnet. Liferay: Creating Picklists

PDFs, Bilder und andere Dateien werden nach Documents & Media übernommen. Ein Dokumenttyp „Merkblatt“ kann beispielsweise Aktenzeichen, zuständige Stelle und fachliches Gültigkeitsdatum enthalten. Wiederverwendbare Feldgruppen werden als Metadata Sets definiert und Dokumenttypen zugewiesen. Liferay: Defining Metadata Sets

Ein Metadatenfeld „gültig bis“ sperrt einen Download allerdings nicht automatisch. Soll eine Datei ab einem bestimmten Zeitpunkt nicht mehr erreichbar sein, muss dieses Verhalten gesondert umgesetzt und auch beim direkten Dateiaufruf geprüft werden.

4. Veröffentlichung, Sprachen und Berechtigungen übernehmen

Für Web Content werden die bisherigen Veröffentlichungsgrenzen auf Anzeige- und Ablaufdatum abgebildet. Vor dem Import sind Zeitzone, leere Werte und bereits abgelaufene Inhalte festzulegen. Ein fachliches Datum, etwa das Ende einer Antragsfrist, bleibt ein eigenes Inhaltsfeld, wenn die Seite danach weiterhin lesbar sein soll.

Arbeitsfassungen werden separat behandelt. Eine mögliche Vereinbarung lautet: Freigegebene Fassungen bilden den öffentlichen Ausgangsbestand; offene Entwürfe werden zusätzlich als Entwürfe übernommen oder vor der Umschaltung redaktionell abgeschlossen. Der Import darf nicht versehentlich die neueste Arbeitsfassung veröffentlichen.

Sprachvarianten brauchen eine explizite Zuordnung. Werden deutsche und englische Inhalte in getrennten Fiona-Bäumen gepflegt, muss entschieden werden, welche davon Übersetzungen desselben Inhalts sind. Erst dann können sie als Sprachvarianten eines Liferay-Artikels zusammengeführt werden.

Die bisherigen Zugriffsregeln werden auf Liferay-Rollen und Ressourcenberechtigungen abgebildet. Geprüft werden Seiten, Inhalte und Dateien jeweils für Gäste sowie für die vorgesehenen Benutzergruppen. Eine ausgeblendete Navigation ist kein Zugriffsschutz. Die Abnahme muss deshalb auch direkte URLs, Downloads und API-Zugriffe einschließen.

Rich-Text-Inhalte werden vor dem Import mit einem HTML-Parser verarbeitet. Die Regeln legen fest, welche Elemente und Attribute erhalten bleiben. Veraltete Schriftformatierungen, Word-Markup und unnötige Inline-Styles können entfernt werden. Datentabellen müssen dabei von Tabellen unterschieden werden, die lediglich das Layout erzeugen.

Interne Links werden zunächst auf ihr altes Ziel aufgelöst. Ein relativer Verweis wie ../formulare/antrag.pdf erhält erst durch die Adresse seiner Quellseite eine eindeutige Bedeutung. Anschließend wird das Ziel über die Migrationstabelle der passenden Liferay-Datei oder dem neuen Inhalt zugeordnet. URL-Fragmente wie #voraussetzungen müssen auf vorhandene Anker im neuen Inhalt zeigen.

Nicht auflösbare Verweise werden protokolliert. Sie dürfen nicht stillschweigend auf die Startseite oder eine beliebige Übersichtsseite umgebogen werden.

Auch Überschriften, Linkbeschriftungen und Alternativtexte werden geprüft. Ein fett gesetzter Absatz ist nicht automatisch eine Überschrift; ein Bild braucht je nach Verwendung einen beschreibenden Alternativtext oder eine Kennzeichnung als dekoratives Bild. Solche Entscheidungen benötigen redaktionellen Kontext. Die Transformationsstrecke kann Auffälligkeiten erkennen und Vorschläge liefern, aber nicht jede Korrektur selbstständig entscheiden.

6. Den Import wiederholbar aufbauen

Zunächst werden Zielmodelle und Konfigurationen eingerichtet: Strukturen, Dokumenttypen, Vokabulare, Picklists, Object-Definitionen sowie Darstellungs- und Seitenvorlagen. Danach folgen Dateien und Inhalte. Beziehungen werden gesetzt, sobald die referenzierten Ziele vorhanden sind; gegenseitige Verweise lassen sich in einem zweiten Durchlauf ergänzen.

Für Web Content und Dokumente werden die passenden Headless-Delivery-Operationen genutzt, für Objects die Object-APIs. Die tatsächlich verfügbaren Methoden werden im API Explorer der Zielinstallation unter /o/api geprüft und gegen deren OpenAPI-Beschreibung implementiert.

Der dokumentierte Aufruf GET /o/headless-delivery/v1.0/sites/{siteId}/content-structures liest Web-Content-Strukturen. Er ist kein allgemeiner Endpunkt zum Anlegen von Strukturen. Deren Bereitstellung wird über einen für die Zielversion unterstützten Import- oder Administrationsweg gelöst. Liferay: Managing Web Content Structures and Templates by Using the REST API

Jeder importierte Datensatz bekommt eine stabile Herkunftskennung, beispielsweise fiona-prod-4711. Wo der Zieltyp und seine API External Reference Codes unterstützen, kann diese Kennung dafür verwendet werden. Zusätzlich führt der Import eine Zuordnung aus Quellsystem, Quell-ID, Zieltyp, Ziel-ID und Zieladresse. Object-Beziehungen können auch über External Reference Codes verknüpft werden. Liferay: Using Relationship REST APIs

Ein erneuter Lauf aktualisiert vorhandene Datensätze, statt Duplikate anzulegen. Das Verfahren muss außerdem Entfernungen, zurückgezogene Freigaben und fehlgeschlagene Importe behandeln. Ein Delta-Import besteht daher nicht nur aus dem Nachladen geänderter Texte.

Die Importprotokolle weisen für jede Quell-ID aus, ob der Datensatz übernommen, aktualisiert, bewusst ausgeschlossen oder mit Fehler abgewiesen wurde. Für unverändert übernommene Dateien werden Prüfsummen verglichen; für Inhalte unter anderem Pflichtfelder, Sprachvarianten, Referenzen und Veröffentlichungsstatus.

7. URLs und Weiterleitungen festlegen

Für jede bekannte öffentliche Adresse wird eine Entscheidung dokumentiert: unverändert erreichbar, dauerhaft weitergeleitet oder entfallen. Dabei werden neben HTML-Seiten auch Downloads und ältere URL-Varianten berücksichtigt.

Aus /bildung/landwirt/index.htm kann beispielsweise /bildung/landwirt werden. Das ist eine Projektentscheidung, keine zwingende Liferay-Regel. Ob der alte Pfad einschließlich Dateiendung direkt weiterverwendet werden kann, hängt vom Routing in Liferay und im vorgeschalteten Webserver ab.

Weiterleitungen werden in Liferays Redirection-Anwendung oder am Reverse Proxy beziehungsweise Webserver eingerichtet. Liferay unterstützt explizite Alias-Zuordnungen und versionsabhängig auch Musterregeln. Welche Ebene verwendet wird, richtet sich nach dem Routing und der späteren Pflege der Regeln. Liferay: Managing Site URLs

Ein zusammengelegter Inhalt wird mit HTTP 301 auf seinen fachlichen Nachfolger weitergeleitet. Für einen ersatzlos entfernten Inhalt wird ein passender Fehlerstatus wie 404 oder 410 vorgesehen. Eine thematisch unpassende Elternseite ist kein verlässlicher Ersatz.

Der automatisierte URL-Test prüft Statuscodes, Zieladressen, Schleifen und Weiterleitungsketten. Bei übernommenen Inhalten muss zusätzlich geprüft werden, ob das Ziel tatsächlich den erwarteten Inhalt liefert. Auch Canonical-Angaben, interne Links und Sitemaps werden auf die neuen Adressen abgestimmt. Eine unveränderte Platzierung in Suchmaschinen lässt sich damit nicht garantieren.

8. Frontend, Suche und Fachverfahren umsetzen

Fiona-Layouts werden nach ihrer jeweiligen Aufgabe aufgeteilt. Die Ausgabe eines strukturierten Artikels kann über ein Web-Content-Template oder ein Display Page Template erfolgen. Wiederkehrende Oberflächenelemente werden als Fragmente umgesetzt. Gemeinsame Seitenrahmen gehören in Master Page Templates; Seitenvorlagen definieren Ausgangslayouts für neue Seiten.

Farben, Abstände und Typografie können über Style Books gepflegt werden. Welche Werte dort verfügbar sind, hängt von den Frontend-Tokens des verwendeten Themes oder der Theme CSS Client Extension ab. Individuelle Komponenten müssen diese Werte auch verwenden, damit Änderungen wirksam werden. Liferay: Using a Style Book to Standardize Site Appearance

Barrierefreiheit wird an Komponenten und an vollständigen Seiten geprüft. Ein zugängliches Fragment verhindert keine falsche Überschriftenfolge oder unverständliche Linktexte in der zusammengestellten Seite. Formulare, Fehlermeldungen, Tastaturbedienung und die übernommenen Dokumente gehören deshalb in die Abnahme. PDFs werden durch den Import nach Documents & Media nicht automatisch barrierefrei.

Für die Suche wird eine zur Liferay-Version passende Suchmaschine betrieben, beispielsweise Elasticsearch. Suchseiten werden mit Trefferlisten und den benötigten Facetten eingerichtet. Die Standard-Suchergebnisse berücksichtigen die Leseberechtigungen der Benutzer. Ein eigener Suchindex benötigt dennoch Betrieb, Überwachung und eine passende Konfiguration. Liferay: Search Overview, Liferay: Search Results

Für Dokumente wird geprüft, ob ihr Text tatsächlich extrahiert und gefunden wird. Ein gescanntes PDF benötigt gegebenenfalls OCR. Object-Einträge müssen mit geeigneten Suchfeldern, Berechtigungen und einer brauchbaren Trefferansicht eingebunden werden.

Formulare werden je nach Zielversion und Anforderung mit Forms, Object-Formularen oder einer eigenen Anwendung umgesetzt. Eine Antragsstrecke braucht zusätzlich Regeln für Validierung, Speicherung, Zuständigkeit, Rückfragen und Statusanzeige. Diese Abläufe entstehen nicht allein durch das Anlegen eines Objects.

Bestehende Fachverfahren können eigenständig bleiben und über APIs angebunden werden. Für eine gemeinsame Anmeldung werden Liferay und Fachverfahren an einen geeigneten Identity Provider angeschlossen. Liferay unterstützt unter anderem SAML und OpenID Connect; Benutzerzuordnung und Berechtigungen müssen separat festgelegt werden. Liferay: Configuring Single Sign-On

Eine API stellt Daten und Funktionen bereit, aber keine fertige eingebettete Oberfläche. Soll das Fachverfahren innerhalb einer Liferay-Seite bedient werden, ist dafür eine passende Oberflächenintegration nötig. Auch ein Liferay Style Book gestaltet eine externe Anwendung nicht automatisch mit; gemeinsame Gestaltungsvorgaben müssen dort ebenfalls umgesetzt werden.

Abnahme und Umschaltung

Vor der Umschaltung wird ein vollständiger Probelauf durchgeführt. Die Abnahme umfasst Datenbestand, Links, Berechtigungen, Suche, Darstellung und die vereinbarten Fachprozesse. Redaktionen prüfen dabei nicht nur die Startseite, sondern typische und schwierige Fälle aus jeder Inhaltsklasse.

Der Ablauf für die Produktivsetzung wird vorher festgelegt: Redaktionsstopp, letzter Export, Verarbeitung der Änderungen und Löschungen, Import, Prüfung, Routing-Umschaltung und Aktivierung der Weiterleitungen. Dazu gehört ein Rückfallverfahren mit klaren Kriterien. Die benötigte Zeit ergibt sich aus gemessenen Probeläufen.

Schulungen beginnen vor diesem Termin. Redakteure pflegen strukturierte Inhalte weiterhin über Eingabemasken; ausgewählte Seiten können zusätzlich im Seiteneditor bearbeitet werden. Welche Arbeitsweise vorgesehen ist, wird anhand der Aufgaben und Berechtigungen festgelegt.

Nach der Umschaltung werden Importfehler, nicht gefundene URLs, Suchtreffer und wichtige Formularabläufe überwacht. Fiona wird erst außer Betrieb genommen, wenn die vereinbarten Daten und Konfigurationen gesichert und die Abnahmekriterien erfüllt sind.

Was bestimmt den Aufwand einer Fiona-Migration?

Für die Kalkulation werden Anzahl und Unterschiede der Objektklassen, Datenqualität, Dokumentbestand, Sprachen, Integrationen und Prüfaufwand erfasst. Auch Seitenzahl und Datenvolumen spielen eine Rolle: Sie beeinflussen Laufzeiten, redaktionelle Nacharbeit und Abnahme. Eine feste Stichprobengröße oder eine pauschale Zahl von Importläufen liefert dafür keine belastbare Grundlage.

Wo KI bei der Migration helfen kann

KI kann bei der Analyse unbekannter HTML-Varianten, bei Feldzuordnungen und bei Textvorschlägen helfen. Für wiederkehrende Extraktionen werden daraus nachvollziehbare Regeln entwickelt und an unterschiedlichen Seiten geprüft. Objekt-IDs, Datumswerte, Freigaben, Referenzen und Prüfsummen werden durch fest definierte Programme verarbeitet und abgeglichen. Vorgeschlagene Alternativtexte und fachliche Änderungen brauchen eine redaktionelle Prüfung.

Häufige Fragen zur Migration von Fiona nach Liferay

Lassen sich die bisherigen Fiona-URLs beibehalten?

Ja, soweit das Routing der Zielumgebung die bisherigen Pfade unterstützt. Ändert sich eine Adresse, wird die alte URL auf den fachlich entsprechenden Nachfolger weitergeleitet. Diese Zuordnung muss auch PDF-Downloads und andere Dateien berücksichtigen. Das Entfernen der Endung .htm ist keine Voraussetzung für die Migration.

Ist eine Migration ohne Zugriff auf den Fiona Content Manager möglich?

Ja. Veröffentlichte Texte, Bilder und Downloads lassen sich aus einem Dateiexport oder einem Crawl übernehmen. Die Feldstruktur muss dann aus dem HTML rekonstruiert werden. Nicht veröffentlichte Entwürfe, interne Metadaten und Freigabeinformationen lassen sich daraus nicht zuverlässig gewinnen. Der fehlende Repository-Zugriff erhöht deshalb den Analyse- und Prüfaufwand.

Wann verwendet man Web Content und wann Liferay Objects?

Web Content eignet sich für redaktionelle Inhalte wie Meldungen, Fachartikel und Veranstaltungsbeschreibungen. Objects eignen sich für Datensätze mit eigenen Beziehungen, Validierungen und Bearbeitungsprozessen, etwa Anmeldungen oder verknüpfte Dienststellen und Ansprechpartner. Die Entscheidung richtet sich nach der Nutzung der Daten. API-Zugriff und Filterbarkeit sind auch mit Web Content möglich.

Was passiert mit PDFs und ihren Metadaten?

Dateien werden nach Documents & Media importiert. Angaben wie Aktenzeichen oder zuständige Stelle werden in Feldern des Dokumenttyps beziehungsweise zugeordneten Metadata Sets gespeichert. Links auf die Dateien werden aktualisiert. Die Barrierefreiheit des PDF-Inhalts muss unabhängig vom Import geprüft und gegebenenfalls überarbeitet werden.

Muss die Website während der Migration offline gehen?

Fiona kann während des Aufbaus der Liferay-Umgebung weiter ausliefern. Für den abschließenden Datenabgleich wird in der Regel ein Redaktionsstopp vereinbart. Seine Dauer und eine mögliche Unterbrechung bei der Umschaltung hängen vom Importverfahren und der Infrastruktur ab und werden im Probelauf ermittelt.

Wie lässt sich der Aufwand belastbar schätzen?

Die Schätzung braucht ein Inventar der Objektklassen, Inhalte, Dateien, Sprachen und Integrationen sowie repräsentative Testimporte. Bewertet werden auch HTML-Qualität, Berechtigungen, URL-Sonderfälle und redaktionelle Nacharbeiten. Die Seitenzahl allein reicht für eine Kalkulation nicht aus.

Fiona-Migration mit der Portalworks GmbH

Die Portalworks GmbH ist Ihr technischer Ansprechpartner für die Migration von Infopark CMS Fiona nach Liferay. Wir übersetzen die gewachsenen Fiona-Objektklassen, Exportregeln und Verknüpfungen in ein Liferay-Modell, das zu Ihren Inhalten und redaktionellen Abläufen passt. Dazu gehört die Entscheidung, welche Informationen als Web Content, als Object oder als Dokument mit Metadaten gepflegt werden und wie sie auf den Seiten erscheinen.

Unsere Arbeit umfasst die technischen Aufgaben der Migration:

  • Fiona analysieren: Wir erfassen Objektklassen, Felder, Vorlagen, Veröffentlichungsregeln und Schnittstellen. An repräsentativen Inhalten prüfen wir, wie sich die Daten vollständig und reproduzierbar extrahieren lassen.
  • Liferay modellieren und einrichten: Wir definieren Strukturen, Dokumenttypen, Beziehungen und Taxonomien und setzen die benötigten Darstellungen, Rollen und Freigabeabläufe um.
  • Die Migrationsstrecke entwickeln: Wir bauen Extraktion, HTML-Bereinigung und Import so auf, dass Testläufe wiederholt und Änderungen bis zur Umschaltung nachgezogen werden können. Quell-IDs und Importprotokolle machen die Übernahme nachvollziehbar.
  • Verweise und Funktionen erhalten: Wir ordnen alte URLs ihren Zielen zu, übernehmen Dokumentverknüpfungen und binden Suche sowie benötigte Fachverfahren in die neue Umgebung ein.
  • Abnahme und Umschaltung begleiten: Wir prüfen Daten, Links und Berechtigungen anhand vereinbarter Kriterien, bereiten den abschließenden Import vor und unterstützen die Redaktion beim Wechsel.

Bereits in der Analyse bearbeiten wir konkrete Fälle aus Ihrem Bestand: Wie wird eine Fiona-Objektklasse mit mehreren Layoutvarianten in Liferay dargestellt? Was passiert mit zeitgesteuerten Veröffentlichungen? Wie bleiben Verweise aus bestehenden PDFs erreichbar? Die Antworten fließen in die Feldzuordnung, das URL-Konzept und die Abnahmekriterien ein.

Sie planen die Ablösung von Fiona? Sprechen Sie mit der Portalworks GmbH über Ihren Bestand und die Anforderungen an Liferay. Für die erste technische Bewertung sind Angaben zur Fiona-Version, eine Übersicht der Objektklassen, typische Seiten und Dokumente sowie Informationen zu angebundenen Anwendungen hilfreich. Daraus entwickeln wir mit Ihnen das Zielmodell, den Migrationsplan und eine nachvollziehbare Aufwandsschätzung.

Marc Hermann
Marc Hermann
Geschäftsführer Portalworks GmbH

Seit 2008 im Liferay- und Magnolia-Umfeld. Über 50 abgeschlossene Projekte in nationalen und internationalen Teams.

Fragen dazu?

Marc Hermann antwortet persönlich – kein Vertriebsteam, kein Formularautomatismus.