eZ Publish has been powering media websites and government portals since 1999, but upgrading from legacy eZ Publish 4.x to anything current requires a complete template rewrite and Symfony expertise that most teams running these sites simply do not have.
The Norwegian CMS That Predates Them All
Launched in 1999 by Oslo-based eZ Systems, eZ Publish was one of the first enterprise PHP CMS platforms in the world. It powered national broadcasters, government agencies, newspaper groups, and university portals across Scandinavia and Europe for over a decade. The content model was genuinely ahead of its time: structured content objects with explicit field definitions, a hierarchical node tree, and a permission system fine-grained enough for complex editorial workflows. For organizations with the technical staff to configure and maintain it, eZ Publish was a serious tool.
But the platform has been in a state of architectural transition since 2012, and that transition has never really completed. eZ Publish 4.x (the original legacy version) was replaced by eZ Platform in 2015, which was itself replaced by Ibexa DXP in 2020. Each transition broke backward compatibility. Templates written for eZ Publish 4.x (in the `.tpl` format) are entirely incompatible with eZ Platform (Twig/Symfony). Extensions written for the old kernel do not run on the new one. Upgrading is not an update. It is a full rebuild.
The Version Treadmill That Never Ends
The version history of the eZ Publish family is the clearest illustration of the problem. eZ Publish 4.x used its own `.tpl` template engine and an INI-based configuration system. eZ Platform 1.x introduced a full Symfony stack with Twig templates and YAML configuration, but maintained a “Legacy Bridge” to run old 4.x code alongside. eZ Platform 2.x dropped the Legacy Bridge. Ibexa DXP rebranded everything again and introduced a commercial platform on top. Meanwhile, a community fork called 7x released eZ Publish 6.0 in 2024 for organizations that cannot afford the full Ibexa transition, but in August 2025 Ibexa issued a trademark dispute and 7x rebranded their project to “Exponential.”
The consequence for organizations still running eZ Publish 4.x is this: to stay within an officially supported environment, they must move to Ibexa DXP, which requires a full Symfony rebuild, new Twig templates, and replacing every extension with Ibexa-compatible equivalents. The path to “upgrading” costs as much as building a new website from scratch, but delivers the same CMS complexity they already have. For many of them, the question is no longer whether to leave eZ Publish, but where to go.
eZ Publish Extensions and Their WordPress Equivalents
Every piece of functionality in eZ Publish is delivered through content types, field types, and extensions. None of these can be ported directly to WordPress. Each must be mapped to a WordPress plugin, ACF field group, or custom-built feature. The table below maps the most common eZ Publish extensions and field types to their WordPress counterparts, including the community forum migration that matters most: eZ Forum moving to wpForo 360° AI.
| eZ Publish Extension / Feature | What It Does | WordPress Equivalent | Cost |
|---|---|---|---|
| Content Objects and Content Types | Structured content with typed fields (text, image, date, relation) | WordPress Posts + Pages + ACF Pro custom fields | Free + Pro |
| eZ Publish Templates (.tpl) | Legacy Smarty-derived template engine for all front-end output | Custom WordPress PHP theme | Custom dev |
| eZ Comments / eZ Comments 2 | Threaded user comments on content objects | WordPress native comments (built in) | Built in |
| eZ Forum | Community discussion boards with topics and replies | wpForo 360° AI (full forum with AI features) | Free + Pro |
| eZ Tags | Hierarchical tagging taxonomy applied to content objects | WordPress Categories + Tags + custom taxonomies | Built in |
| eZ Flow | Zone-based landing page builder for structured page layouts | Gutenberg Block Editor + ACF Flexible Content | Free + Pro |
| eZ Form Token / eZ Survey | Web forms and surveys with submission tracking | Gravity Forms / WPForms / Fluent Forms | Free tiers |
| eZ Recommendation | Personalized content recommendation engine | Related Posts by Yoast / Contextly | Free tiers |
| eZ Image field type | Managed image fields on content objects with cropping support | WordPress Media Library + ACF Image field | Free + Pro |
| eZ User + Roles | Granular user roles and section-based access control | WordPress User Roles + MemberPress / Ultimate Member | Free core |
| eZ URL aliases | Automatic and manual URL alias generation per content object | Yoast SEO + WordPress permalink settings | Free core |
| eZ Multisite / SiteAccess | Multiple site configurations from a single installation | WordPress Multisite | Built in |
| eZ Network / eZ Online Editor | Rich text editing on content object body fields | WordPress Gutenberg Block Editor (built in) | Built in |
A note on the eZ Forum migration. eZ Publish forum content is stored in the portal database alongside the main content objects. gConverter migrates forum categories, topics, replies, and member attribution directly into wpForo 360° AI, giving the community a properly featured forum with AI-powered moderation, member ranks, subscriptions, and real-time notifications that eZ Forum never supported.
What a Proper eZ Publish Migration Involves
Migrating eZ Publish to WordPress cannot be done with a generic export tool. The eZ Publish database stores content in an abstract repository model with content objects, locations (nodes), versions, and field values spread across multiple tables. A proper migration reads the source database directly and maps each layer explicitly. Here is how each component is handled.
Content objects and structured fields
eZ Publish content is stored in the ezcontentobject, ezcontentobject_version, and ezcontentobject_attribute tables. Each content type definition (formerly “content class”) lives in ezcontentclass with field definitions in ezcontentclass_attribute. A proper migration reads every content object per type, maps the field values to their ACF Pro equivalents in WordPress, and creates posts or custom post types that replicate the original content structure. The content object hierarchy (the node tree stored in ezcontentobject_tree) is mapped to the WordPress page hierarchy or post archive structure as appropriate.
Node tree to page hierarchy
Every piece of content in eZ Publish lives at one or more locations (nodes) in a tree. The tree represents the site structure and URL path. A proper migration reads ezcontentobject_tree and ezurlalias_ml to reconstruct the exact URL structure in WordPress. Container nodes (folders) become page parents. Content nodes become pages or posts. The URL alias table is read directly to preserve every existing URL where possible and create 301 redirects for any that must change.
Templates to WordPress theme
eZ Publish legacy templates are written in the .tpl format. They cannot be ported to WordPress. A proper migration delivers a custom WordPress theme that replicates the visual output of the original eZ Publish site exactly: every header variant, every content type view (full, line, embed), every sidebar widget, and every page layout zone. The result is visually identical to the original site but built on native WordPress PHP templates with no dependency on the eZ template engine.
eZ Forum to wpForo
Forum topics and replies are stored in eZ Publish as content objects of the forum content type. The topic hierarchy maps to forum categories and threads. A proper migration reads these content objects and creates the corresponding wpForo 360° AI structure: categories from the forum container nodes, topics from topic content objects, and replies from reply content objects. Author attribution, publication timestamps, and view counts are all preserved.
Users, roles, and sections
eZ Publish users are stored in ezuser and ezcontentobject (users are content objects in the eZ data model). Roles are defined in ezrole with policy assignments in ezpolicy. All registered users are imported to WordPress with role mapping. Section-based access control is translated to WordPress user roles and MemberPress access rules where needed. User profile fields defined as content class attributes are imported as WordPress user meta.
SEO and URL aliases
Every eZ Publish content object has one or more URL aliases in the ezurlalias_ml table. These are read directly and either replicated as WordPress permalink slugs (where the structure permits) or implemented as 301 redirects via the Redirection plugin. SEO titles and meta descriptions are imported to Yoast SEO. No content item goes live without its URL and SEO data intact.
What Bad eZ Publish Migrations Look Like
- Content object attributes silently lost. Generic migration tools do not understand the
ezcontentobject_attributetable structure. They grab the rendered HTML output of each page but miss every structured field: dates, related content links, image fields, file attachments, and custom field types. All structured content arrives in WordPress as a flat blob or is dropped entirely. - Node tree ignored. The eZ Publish URL structure is derived from the node tree. Generic tools create default WordPress slugs with no regard for the original URL structure and implement no redirects. All existing inbound links, bookmarks, and search rankings break at launch.
- eZ Forum content abandoned. Forum topics and replies stored as eZ Publish content objects are not handled by any standard WordPress importer. Years of community discussion are simply not migrated.
- Templates not rebuilt. Some providers export the rendered HTML of each page and paste it into a generic WordPress theme. The result breaks immediately when content is edited, has no template hierarchy, and is unmaintainable.
- User accounts incomplete. eZ users are content objects with profile fields stored in
ezcontentobject_attribute. Generic tools import basic account credentials but lose all user profile field data, breaking author attribution throughout the migrated site. - eZ Tags not migrated. The eZ Tags extension stores a hierarchical taxonomy separate from the main content class system. Generic tools skip it entirely. All content arrives in WordPress without category or tag assignments.
GDPR and Your Data
An eZ Publish database contains the personal data of every registered user: usernames, email addresses, hashed passwords, and all user profile field values stored as content object attributes. If the site used eZ Forum, the database contains every post and reply tied to user identities. If forms were used via eZ Form Token or eZ Survey, submitted personal data is in the content object attribute tables. For Scandinavian government sites and media organizations running eZ Publish, this data is subject to GDPR and potentially national data protection regulations in Norway, Sweden, Denmark, or Finland.
Migrating this to WordPress is a personal data transfer that requires a signed Data Processing Agreement before any provider accesses your database. gConverter is US-registered with full EU GDPR compliance. We sign a DPA before any access, store all credentials in AES-256 encrypted vaults, transfer over TLS 1.3, and permanently delete all customer data within 30 days. Read the full GDPR documentation →
What Clients Say
Went FAR above and beyond to help us work through this project. We are thrilled with the final result and they were professional, great to work with, and responsive every step of the way. Would highly recommend.
Anna P., Wilmington NC – Customer Lobby, January 2026
Very few conversion issues on the first pass, and they cleaned it right. Very Impressive.
Stacy C., Katy TX – Customer Lobby, November 2025
The Bottom Line
For the media organizations, government portals, and university sites across Scandinavia and Europe that built on eZ Publish in its prime, the platform delivered real value. The content object model, the hierarchical node tree, and the role-based access control were genuinely capable. But the version incompatibility chain from eZ Publish 4.x through eZ Platform to Ibexa DXP has made staying current prohibitively expensive, and the community of developers who know the platform deeply has contracted significantly.
WordPress is where the talent is, where the tools are, and where a content team can work independently. Every content object, every forum thread, every user account, and every URL alias on your eZ Publish site can be migrated cleanly. And the community forum moves to wpForo 360° AI, not into a basic thread list with no moderation features.