When migrating from Infopark CMS Fiona to Liferay, object classes and fields are mapped to web content structures, document types, or Liferay Objects. Content and files are exported, cleaned up, and imported via the appropriate interfaces. Templates, permissions, and publishing rules are set up in the target system; existing URLs are preserved or redirected to the new content.
Portalworks GmbH supports the migration from Infopark CMS Fiona to Liferay: from the analysis of the Fiona inventory and the development of the Liferay target model through to data import and cutover. In doing so, we combine work on the content model with the implementation of editing, presentation, and integrations in Liferay.
This guide describes the technical implementation for those responsible in IT, web editing, and project management. Using an example object class “Press Release,” it shows which Fiona data belongs where and which checks are required before cutover.
The published HTML pages serve as a comparison and, if necessary, as a data source. For a complete migration, however, the structured content from the Fiona Content Manager is required. A website crawl cannot fully reconstruct internal metadata, working versions, and approval rules.
As of: September 18, 2026. Technical details refer to the product documentation linked in each case; interfaces and functions must be verified against the versions in use.
Contents
- 1. Capture the Fiona inventory and delivery
- 2. Extract content from the Content Manager
- 3. Map object classes and fields in Liferay
- 4. Transfer publishing, languages, and permissions
- 5. Clean up HTML and internal links
- 6. Build the import to be repeatable
- 7. Define URLs and redirects
- 8. Implement frontend, search, and specialized applications
- Acceptance and cutover
- What determines the effort of a Fiona migration?
- Frequently asked questions about migrating from Fiona to Liferay
- Fiona migration with Portalworks GmbH
1. Capture the Fiona inventory and delivery
Fiona manages content in the Content Manager. Object classes define the available fields; layouts and export rules determine the output. With static publishing, this produces files for the web server. The object path is an indicator of the public URL, but must be evaluated together with the export configuration and the addresses actually delivered.
Fiona installations can also contain dynamic components. Infopark documents a Search Server and the integration of dynamic search results via the Portal Manager. These components and their application code must be captured separately in the inventory. Infopark: System Administration / Development, in particular section 3.18
For the inventory, the following is captured for each object class:
- number of objects and of content actually published;
- field names, data types, required fields, and permitted values;
- layouts used, export specifics, and embedded scripts;
- references to other content, images, and documents;
- language variants, permissions, and approval workflows;
- public URLs, including earlier addresses and existing redirects.
In addition, there are file sizes, document formats, and the functions outside the CMS: form processing, search services, maps, specialized applications, and logins.
Access logs help with prioritization. However, they do not alone decide whether content is dropped. A rarely read policy may still be needed. Likewise, an object class with few instances can have an independent business function. Migration, consolidation, and deletion are therefore decided with the responsible editorial teams and documented for each piece of content.
Whether a switch is necessary because maintenance is expiring must be clarified based on the version in use and the agreed vendor or service provider services. A blanket statement about missing security updates does not replace this assessment.
2. Extract content from the Content Manager
For extraction, the documented Fiona interfaces are used wherever possible. Among other things, the Tcl interface provides access to objects, object classes, and versions. The specific implementation depends on the installed version. Released content and working versions must be read and labeled separately. Fiona also maintains publishing limits as validFrom and validUntil. Infopark: Tcl Interface Reference
The export for the migration should produce a documented intermediate format, for example JSON for structured data and separate files for binary content. For each record, the source ID, object class, path, version status, field values, and references are stored. A content hash later helps detect changes between two exports.
Direct database queries only come into consideration if the supported interfaces are not sufficient and the internal schema is reliably understood. A query that returns text fields but assigns versions or references incorrectly produces errors that are hard to spot.
In addition, the published website is backed up and crawled. It serves as a comparison for texts, downloads, navigation, and URLs. The crawl is reconciled with export directories, sitemaps, and access logs: pages that are not linked are not reliably found by an ordinary crawl.
If the Content Manager is no longer accessible, fields must be reconstructed from the HTML. To do this, the existing page variants are examined and suitable extraction rules are created. Different templates, manually inserted HTML, and historical special pages need their own rules. Information that cannot be reconstructed, such as approval status or internal metadata, is flagged as missing.
3. Map object classes and fields in Liferay
The following examples use Liferay's established Web Content, Documents & Media, and Liferay Objects. The new Liferay CMS documented as of DXP 2026.Q3 has its own model for content and file structures. Its structures and APIs must not be equated with the web content structures described here. Liferay: Content Structures
In Fiona, storage, content, and page output are often closely linked. In Liferay, these tasks are planned separately: Web Content manages editorial content, pages and navigation determine its placement, and Display Page Templates its detail view.
For an example Fiona object class “Press Release,” the mapping can look like this. The field names are illustrative project fields, not predefined Fiona standard fields.
| Element in Fiona | Implementation in Liferay | Decision for the migration |
|---|---|---|
| Object class “Press Release” | Web content structure “Press Release” | Define field types, required fields, and translatability |
| Title | Title of the web content article | Assign language variants |
| Introduction | Structure field “Introduction” | Define as plain text or rich text |
| Main content | Rich text field “Text” | Clean up HTML and replace internal links |
| Image reference | Image field referencing the imported image | Set target reference after the file import |
| PDF attachment | Document reference in a suitable structure field | Reference the entry in Documents & Media |
| Topic assignment | Category in the vocabulary “Topics” | Map old values to stable categories |
| Layout for the detail view | Display Page Template for the structure | Connect fields with the editable elements of the fragments |
| Previous address | New content address plus URL mapping | Preserve or redirect the old address |
Liferay structures support, among other things, text fields, selection fields, and repeatable field groups. A list of several downloads therefore does not have to be written into a single HTML block. It can be modeled as a repeatable group of a document reference and a label. Liferay: Web Content Structures
The Display Page Template is set up for the content type or structure. It displays the fields of an article under its detail address. As a result, no separately designed content page has to be created for individual press releases. Overview pages can assemble the press releases via Collections and Collection Displays. Liferay: Using Display Page Templates
When Liferay Objects make sense
Objects are suitable for records with their own relationships, validations, and processing workflows. One possible model consists of the objects “Office” and “Contact Person” with a relationship between the two. Name, contact details, and responsibility are then stored as fields instead of being copied into several articles.
Filterability or API access alone is not a reason for Objects: Web Content can also be retrieved and searched in a structured way. An event can therefore be maintained as Web Content, while registrations are stored in an Object or an external booking system. What matters are the required relationships and workflows.
For published custom Objects, Liferay generates REST interfaces. Their paths and available operations depend, among other things, on the scope of the Object. Relationships can be managed via dedicated endpoints. Liferay: Accessing Object via Headless APIs
Selection fields and document metadata
A Fiona selection field is transferred according to its meaning. Topics and target groups can become categories in Liferay vocabularies. A local selection field such as “Display variant,” on the other hand, remains a field of the web content structure. For fixed selection lists in Objects, Picklists are available. Technical keys and displayed labels are mapped separately. Liferay: Creating Picklists
PDFs, images, and other files are transferred to Documents & Media. A document type “Fact Sheet” can, for example, contain a file reference number, the responsible office, and a business validity date. Reusable field groups are defined as Metadata Sets and assigned to document types. Liferay: Defining Metadata Sets
However, a metadata field “valid until” does not automatically block a download. If a file should no longer be accessible from a certain point in time, this behavior must be implemented separately and also checked for direct file access.
4. Transfer publishing, languages, and permissions
For Web Content, the previous publishing limits are mapped to the display and expiration dates. Before the import, the time zone, empty values, and content that has already expired must be defined. A business date, such as the end of an application deadline, remains a separate content field if the page should still be readable afterward.
Working versions are handled separately. One possible agreement: released versions form the public baseline; open drafts are additionally transferred as drafts or completed editorially before cutover. The import must not accidentally publish the latest working version.
Language variants need an explicit mapping. If German and English content is maintained in separate Fiona trees, it must be decided which of them are translations of the same content. Only then can they be merged as language variants of a Liferay article.
The previous access rules are mapped to Liferay roles and resource permissions. Pages, content, and files are each checked for guests and for the intended user groups. Hidden navigation is not access protection. Acceptance must therefore also include direct URLs, downloads, and API access.
5. Clean up HTML and internal links
Rich text content is processed with an HTML parser before the import. The rules define which elements and attributes are retained. Outdated font formatting, Word markup, and unnecessary inline styles can be removed. Data tables must be distinguished from tables that merely create the layout.
Internal links are first resolved to their old target. A relative link such as ../formulare/antrag.pdf only gets an unambiguous meaning from the address of its source page. The target is then mapped via the migration table to the matching Liferay file or the new content. URL fragments such as #voraussetzungen must point to existing anchors in the new content.
Links that cannot be resolved are logged. They must not be silently redirected to the home page or an arbitrary overview page.
Headings, link labels, and alternative texts are also checked. A paragraph set in bold is not automatically a heading; depending on its use, an image needs a descriptive alternative text or a marking as a decorative image. Such decisions require editorial context. The transformation pipeline can detect anomalies and make suggestions, but cannot decide every correction on its own.
6. Build the import to be repeatable
First, target models and configurations are set up: structures, document types, vocabularies, Picklists, Object definitions, as well as display and page templates. Files and content follow. Relationships are set as soon as the referenced targets exist; mutual references can be added in a second pass.
For Web Content and documents, the appropriate Headless Delivery operations are used; for Objects, the Object APIs. The methods actually available are checked in the API Explorer of the target installation under /o/api and implemented against its OpenAPI description.
The documented call GET /o/headless-delivery/v1.0/sites/{siteId}/content-structures reads web content structures. It is not a general endpoint for creating structures. Their provisioning is handled via an import or administration path supported for the target version. Liferay: Managing Web Content Structures and Templates by Using the REST API
Each imported record receives a stable origin identifier, for example fiona-prod-4711. Where the target type and its API support External Reference Codes, this identifier can be used for them. In addition, the import maintains a mapping of source system, source ID, target type, target ID, and target address. Object relationships can also be linked via External Reference Codes. Liferay: Using Relationship REST APIs
A repeated run updates existing records instead of creating duplicates. The procedure must also handle removals, withdrawn approvals, and failed imports. A delta import therefore does not consist merely of reloading changed texts.
The import logs show for each source ID whether the record was transferred, updated, deliberately excluded, or rejected with an error. For files transferred unchanged, checksums are compared; for content, among other things, required fields, language variants, references, and publishing status.
7. Define URLs and redirects
For each known public address, a decision is documented: accessible unchanged, permanently redirected, or dropped. In addition to HTML pages, downloads and older URL variants are also taken into account.
For example, /bildung/landwirt/index.htm can become /bildung/landwirt. This is a project decision, not a mandatory Liferay rule. Whether the old path, including the file extension, can be reused directly depends on the routing in Liferay and in the upstream web server.
Redirects are set up in Liferay's Redirection application or at the reverse proxy or web server. Liferay supports explicit alias mappings and, depending on the version, also pattern rules. Which level is used depends on the routing and on how the rules will be maintained later. Liferay: Managing Site URLs
Consolidated content is redirected with HTTP 301 to its business successor. For content removed without replacement, an appropriate error status such as 404 or 410 is provided. A thematically unsuitable parent page is not a reliable replacement.
The automated URL test checks status codes, target addresses, loops, and redirect chains. For transferred content, it must also be checked whether the target actually delivers the expected content. Canonical tags, internal links, and sitemaps are also aligned with the new addresses. This cannot guarantee unchanged search engine rankings.
8. Implement frontend, search, and specialized applications
Fiona layouts are split up according to their respective purpose. A structured article can be rendered via a web content template or a Display Page Template. Recurring interface elements are implemented as fragments. Shared page frames belong in Master Page Templates; page templates define starting layouts for new pages.
Colors, spacing, and typography can be maintained via Style Books. Which values are available there depends on the frontend tokens of the theme used or of the Theme CSS Client Extension. Custom components must also use these values for changes to take effect. Liferay: Using a Style Book to Standardize Site Appearance
Accessibility is checked on components and on complete pages. An accessible fragment does not prevent an incorrect heading order or incomprehensible link texts on the assembled page. Forms, error messages, keyboard operation, and the transferred documents therefore belong in the acceptance. PDFs do not automatically become accessible by being imported into Documents & Media.
For search, a search engine compatible with the Liferay version is operated, for example Elasticsearch. Search pages are set up with result lists and the required facets. The standard search results take the users' read permissions into account. A dedicated search index nevertheless requires operation, monitoring, and a suitable configuration. Liferay: Search Overview, Liferay: Search Results
For documents, it is checked whether their text is actually extracted and found. A scanned PDF may require OCR. Object entries must be integrated with suitable search fields, permissions, and a usable result view.
Depending on the target version and requirements, forms are implemented with Forms, Object forms, or a custom application. An application process additionally needs rules for validation, storage, responsibility, follow-up questions, and status display. These workflows do not come about simply by creating an Object.
Existing specialized applications can remain independent and be connected via APIs. For a shared login, Liferay and the specialized applications are connected to a suitable identity provider. Liferay supports SAML and OpenID Connect, among others; user mapping and permissions must be defined separately. Liferay: Configuring Single Sign-On
An API provides data and functions, but no ready-made embedded user interface. If the specialized application is to be operated within a Liferay page, a suitable UI integration is required. A Liferay Style Book does not automatically style an external application either; shared design guidelines must also be implemented there.
Acceptance and cutover
Before cutover, a complete trial run is carried out. Acceptance covers the data inventory, links, permissions, search, presentation, and the agreed business processes. Editorial teams check not only the home page, but typical and difficult cases from each content class.
The go-live procedure is defined in advance: editorial freeze, final export, processing of changes and deletions, import, verification, routing switch, and activation of redirects. This includes a fallback procedure with clear criteria. The time required is derived from measured trial runs.
Training begins before this date. Editors continue to maintain structured content via input forms; selected pages can additionally be edited in the page editor. Which way of working is intended is defined based on tasks and permissions.
After cutover, import errors, URLs not found, search results, and important form workflows are monitored. Fiona is only decommissioned once the agreed data and configurations have been backed up and the acceptance criteria have been met.
What determines the effort of a Fiona migration?
For the cost estimate, the number of object classes and the differences between them, data quality, document inventory, languages, integrations, and testing effort are captured. Page count and data volume also play a role: they affect run times, editorial rework, and acceptance. A fixed sample size or a flat number of import runs does not provide a reliable basis for this.
Where AI can help with the migration
AI can help analyze unknown HTML variants, with field mappings, and with text suggestions. For recurring extractions, traceable rules are developed from this and tested on different pages. Object IDs, date values, approvals, references, and checksums are processed and reconciled by firmly defined programs. Suggested alternative texts and content changes require editorial review.
Frequently asked questions about migrating from Fiona to Liferay
Can the previous Fiona URLs be retained?
Yes, insofar as the routing of the target environment supports the previous paths. If an address changes, the old URL is redirected to the corresponding business successor. This mapping must also take PDF downloads and other files into account. Removing the .htm extension is not a prerequisite for the migration.
Is a migration possible without access to the Fiona Content Manager?
Yes. Published texts, images, and downloads can be transferred from a file export or a crawl. The field structure must then be reconstructed from the HTML. Unpublished drafts, internal metadata, and approval information cannot be reliably obtained from it. The lack of repository access therefore increases the analysis and testing effort.
When do you use Web Content and when Liferay Objects?
Web Content is suitable for editorial content such as press releases, specialist articles, and event descriptions. Objects are suitable for records with their own relationships, validations, and processing workflows, such as registrations or linked offices and contact persons. The decision depends on how the data is used. API access and filterability are also possible with Web Content.
What happens to PDFs and their metadata?
Files are imported into Documents & Media. Information such as file reference numbers or the responsible office is stored in fields of the document type or of assigned Metadata Sets. Links to the files are updated. The accessibility of the PDF content must be checked independently of the import and revised if necessary.
Does the website have to go offline during the migration?
Fiona can continue to deliver content while the Liferay environment is being built. For the final data reconciliation, an editorial freeze is usually agreed. Its duration and any interruption during cutover depend on the import procedure and the infrastructure and are determined in the trial run.
How can the effort be estimated reliably?
The estimate requires an inventory of object classes, content, files, languages, and integrations, as well as representative test imports. HTML quality, permissions, special URL cases, and editorial rework are also assessed. Page count alone is not sufficient for a cost estimate.
Fiona migration with Portalworks GmbH
Portalworks GmbH is your technical partner for migrating from Infopark CMS Fiona to Liferay. We translate the Fiona object classes, export rules, and links that have grown over time into a Liferay model that fits your content and editorial workflows. This includes deciding which information is maintained as Web Content, as an Object, or as a document with metadata, and how it appears on the pages.
Our work covers the technical tasks of the migration:
- Analyze Fiona: We capture object classes, fields, templates, publishing rules, and interfaces. Using representative content, we check how the data can be extracted completely and reproducibly.
- Model and set up Liferay: We define structures, document types, relationships, and taxonomies and implement the required presentations, roles, and approval workflows.
- Develop the migration pipeline: We build extraction, HTML cleanup, and import so that test runs can be repeated and changes can be carried over until cutover. Source IDs and import logs make the migration traceable.
- Preserve links and functions: We map old URLs to their targets, carry over document links, and integrate search and the required specialized applications into the new environment.
- Support acceptance and cutover: We check data, links, and permissions against agreed criteria, prepare the final import, and support the editorial team during the switch.
Already during the analysis, we work on concrete cases from your inventory: How is a Fiona object class with several layout variants represented in Liferay? What happens to time-controlled publications? How do links from existing PDFs remain accessible? The answers feed into the field mapping, the URL concept, and the acceptance criteria.
Are you planning to replace Fiona? Talk to Portalworks GmbH about your inventory and your requirements for Liferay. For the initial technical assessment, information on the Fiona version, an overview of the object classes, typical pages and documents, and information on connected applications are helpful. Based on this, we work with you to develop the target model, the migration plan, and a traceable effort estimate.
