Upgrading your site from eZ Publish to eZ Platform

eZ Publish, our previous generation product, has not been actively developed for over five years since its last release in December 2014. There are still many live installations running eZ Publish 5.4 and even older versions. eZ Publish is solid as a rock and supported by eZ Systems until December 2021, but you should always plan for the future.

If you're planning to upgrade an existing installation of eZ Publish to eZ Platform, then continue reading. This is not a step-by-step guide for a technical upgrade, as that is covered in our documentation in the section Migrating from eZ Publish Platform. You'll get a high-level understanding of the steps required and help sizing efforts needed for an upgrade.

eZ Systems' software has always had a high priority on Backwards Compatibility (BC). This is why it is realistic to upgrade from an unsupported 2009 installation of eZ Publish 4.2 installation to the latest eZ Platform 2.5 LTS version. This can be quite trivial or require a near-complete rewrite, so you'll need to do some discovery to estimate the effort.

Let's split the migration effort to three topics and examine them one by one:

• Content migration
• Updating your codebase
• Infrastructure upgrades

Content migration

The content engine is the heart of eZ Publish and eZ Platform. Behind the scenes the technical implementation has been totally rebuilt, but the core concepts remain the same. The same applies to storage - both applications use a relational database to store data in a specific schema. Today the most common RDBMS used is MySQL/MariaDB or PostgreSQL.

In an ideal case an existing eZ Publish database can be migrated to eZ Platform by following the database upgrade steps and finally converting the richtext format using the provided script. In reality, this might not be the case, since in many cases there are third-party extensions with custom field types . More about this in the code migration section.

You can have your existing content repository migrated to eZ Platform, but before proceeding you should ask if you really want to? Over years of development the content model tends to change and you often end up with redundant fields and content. This is why it is often a good idea to start afresh and only migrate select content using an import script.

In a large renewal it is also a good opportunity to review all content and fix flaws in your content architecture. Technically you will be importing new objects from one system (eZ Publish) to a new one (eZ Platform), but because the concepts are identical the implementation effort is usually modest, without doing any low-level database migration.

I recommend using a HTTP API (REST or a custom one) to expose content in the live system and continuous import it to a database in development, linking the two systems using remote IDs. This allows for a gradual importing process, allowing development using real data and avoiding an error prone big bang migration before launch of the upgrade.

Updating your codebase

For code migration, moving from eZ Publish to eZ Platform, the situation is more complex than with content migrations. There are more variables at play here because a majority of code is project specific. To simplify, let's tackle this in three topics:

• Field types
• Site templates and logic
• Integrations and other custom functionality

Field types

The content engine uses field types to enable administrators to define content models. Developers can extend the content engine by creating custom field types. A field type uses the database to store information and set of templates and code to allow users to edit them. Implementation of a field type is completely different between Publish and Platform.

For built-in field types our engineering team have done the conversion effort, but for custom field types you'll need to do that yourself or for third-party extensions see if there is an eZ Platform compatible version available. Automatic migration of field type code and templates is not feasible, so you'll need to estimate the conversion effort case by case.

Site templates and logic

Site templates and build logic are used to display content from the repository to visitors of a site, allow navigation using menus, set a design and so forth. Naturally, these are always implementation specific. The most notable change between eZ Publish and eZ Platform is that not only do they use different templating language, but a different concept altogether.

With eZ Publish you mixed your logic in your display template, whereas with eZ Platform you are required to use the MVC pattern separating concerns following Symfony framework best practices. This will require that you rewrite your whole display layer when migrating from eZ Publish to eZ Platform. It is also an opportunity to refresh your design and markup.

Note there's a twist: If your application was built using eZ Publish 5, you might not need a complete rewrite. eZ Publish 5.x allows developers to write applications in using the old or the new method. If your existing implementation is written with the Twig templating engine, then you can very likely reuse the templates and code with some minor adjustments.

Integrations and other custom functionality

For integrations and other custom functionality, you'll need to consider several things. Very old code will need changes if it does not work with PHP versions supported by eZ Platform. Some functionality in eZ Publish is no longer available in eZ Platform, and the technical implementation for features such as editorial workflows is completely different. Be prepared to spend time and resources on migrating complex custom functionalities.

If your existing implementation has functionality that is not using eZ Publish APIs, you might be able to transfer that code to your existing applications. For example, in one upgrade I moved a custom feature written in Object Oriented PHP using custom database tabled from eZ Publish to eZ Platform. I copied the code, created a Symfony service and injected the database connection used by eZ Platform. And voilà! Application logic was untouched.

One option for heavily modified back end integrations is to use the Legacy Bridge. This allows you to use the old administration interface by including the legacy codebase, very much as eZ Platform 5.x does. While this works, and is officially supported, I would consider it as a stop-gap solution. You will continue to have old code, and eZ Platform 3.0 will no longer support the legacy bridge. You're taking two steps forward and one step back.

Infrastructure upgrades

For infrastructure, both eZ Platform and eZ Publish both use the tried and tested LAMP platform. But over the years the version requirements and peripheral requirements of caching systems, etc. have changed. My recommendation is that as a part of your app upgrade project, you also start fresh regarding infrastructure. They go hand-in-hand.

A few notes on software versions: PHP remains a core requirement, eZ Platform 2.5 requires a minimum of PHP 7.1, but ideally you should go for the highest supported version for new language features and improved performance. eZ Platform supports Memcached as a caching backend, but Redis is now the de-facto one. For search eZ Platform still uses Solr like ezfind did, but the version requirement has been bumped up a notch or two.

As for the low-level approach you can take any direction you want with eZ Platform: You can install on premises, on a Virtual Private Server (VPS) provider or on the cloud with AWS, Google Cloud or Azure. Another novel option is to use a PaaS (Platform as a Service) where you control the software, but the all the services are managed on your behalf. One great option is eZ Platform Cloud, our own PaaS optimized for eZ Platform Enterprise Edition.

Conclusion

As you can see, our architecture enables upgrading even older systems into the bleeding-edge version of our software. In addition to new features, improved security and performance, your software development team will likely be happier as well. With the use of the Symfony framework, onboarding new developers to your project will also be easier.

Please do not hesitate to contact us to help us with your next step of your upgrade project, whether it be kicking it off with expert consulting or finding an implementation partner to help you with the migration process from planning to a successful deployment.