Exponential 6 and Exponential Platform Legacy #

Exponential Platform Legacy (se7enxweb/exponential-platform-legacy) runs the Exponential 6 kernel and a Symfony platform on one database, joined by se7enxweb/legacy-bridge. It is the gentlest way to give an Exponential 6 site the Symfony stack: the content, the legacy admin, the TPL templates and the extensions keep working while Twig templates, REST v2 and the platform admin are added. And because nothing of the legacy side is removed, the way back is short.

Migration hub · Checklist · The product's own book: Exponential Platform Legacy, chapter 11: Migrating into Exponential Platform Legacy

Contents #

• 1. The release lines
• 2. Is it the right target?
• 3. From Exponential 6 to Platform Legacy
• 4. Moving to a newer line
• 5. From Platform Legacy back to Exponential 6 alone
• 6. Verify
• 7. Rollback
• 8. Risks
• 9. Checklist

1. The release lines #

Read from the composer.json of each release tag on 2026-10-18 (hub, 1.2):

A ready-to-run variant of the v5 line is se7enxweb/exponential-platform-legacy-starter (1.0.0.0).

2. Is it the right target? #

Things that change for the site when the Symfony stack serves it:

• Symfony serves the requests; the legacy siteaccesses are reached through the bridge (legacy_mode: true). Velocity, which serves Exponential 6 alone, is not the server of a Platform Legacy project.
• Database credentials live only in Symfony's configuration; the bridge injects them into the legacy kernel.
• Image aliases come from the YAML image variations; legacy-only aliases in image.ini must be declared there.
• Sign-in on non-legacy siteaccesses is Symfony's. Both kernels read the legacy password hashes, but platform generations from 3.0 on accept only types 6 and 7 (17.7).
• Database engines: the platform side supports MySQL/MariaDB and PostgreSQL; SQLite is offered for development in the v5 quick start. MongoDB and Oracle, which Exponential 6 supports, are not platform engines: move such a site to MySQL, MariaDB or PostgreSQL first (Databases).

3. From Exponential 6 to Platform Legacy #

An Exponential 6 database is a legacy database that is already past the 5.4 step of the old chain, so you follow the product's chapter 11.3 without its legacy update chain.

Arrive on the 2.5 line first. The product's book: the 2.5 platform schema "is the complete legacy schema", so nothing the legacy site uses is missing; move up line by line afterwards (4).

1. Freeze and back up the database and var/<site>/storage. Restore the backup once on a scratch machine.
2. Bring Exponential 6 to its newest release (chapter 11.6) and confirm the version rows (11.2).
3. On MySQL, convert the tables to utf8mb4. The 2.5 platform kernel creates utf8mb4 tables and the distribution's legacy override talks utf8mb4 to the server; the product's chapter 11.3 gives the query that prints the ALTER TABLE ... CONVERT TO CHARACTER SET utf8mb4 statements to review and run.
4. Apply the 2.5 platform kernel's update files from vendor/se7enxweb/ezpublish-kernel/data/update/<engine>/, in the order the product's chapter 11.3 step 3 lists. On an Exponential 6 database most of what they do (the wider password_hash, ezcontentobject_trash.trashed, the PostgreSQL sequence names) is already there; the product's chapter 10.7 explains which statements are safe to repeat. Run them on the copy and read every error: a "duplicate column" means the change exists, anything else stops the migration.
5. Add the tables the 2.5 kernel expects that a legacy-only database lacks (for example ezcontentclass_attribute_ml, eznotification): compare your table list with data/mysql/schema.sql of the installed se7enxweb/ezpublish-kernel and create the missing ones from that file (chapter 16.6.1 has the comparison).
6. Create the 2.5 project with an explicit version, and point it at the migrated database without running the installer: the product's book warns that ezplatform:install / exponential:install drop and recreate the tables they know.
7. Move the storage to ezpublish_legacy/var/<site>/storage (or the directory your VarDir names).
8. Move the legacy configuration: settings/override/ into ezpublish_legacy/settings/override/, the siteaccess directories into ezpublish_legacy/settings/siteaccess/, and remove the [DatabaseSettings] connection values.
9. Declare the siteaccesses in YAML with the same names; the legacy ones get legacy_mode: true. Declare every image alias the legacy designs use as an image variation.
10. Move your extensions into the project and activate them; regenerate the autoloads through the bridge (php bin/console ezpublish:legacy:script bin/php/ezpgenerateautoloads.php).
11. Verify the schema with ezsqldiff.php, the reference schema first and your database second (the product's chapter 11.3 step 10 and the Nexus book, 12.4 explain the argument order). DROP lines for platform-only tables are expected.
12. Run the legacy cron through the bridge, clear the caches of both sides, reindex, and verify (6).

What does not need to move: the content, the classes, the users, roles, sections, states, URL aliases and the Exponential Layouts data stay in the shared database and are read by the legacy side as before.

4. Moving to a newer line #

Move one line at a time, with the product's chapter 10 (Upgrading between release lines):

Every line change also changes the project layout and configuration (for example app/config to config/, web/ to public/ from 2.5 to 3.x); the product's chapter lists them.

5. From Platform Legacy back to Exponential 6 alone #

The legacy half is a complete Exponential 6 installation; going back means letting it serve the site again.

1. Back up the shared database and storage.
2. Decide what happens to Symfony-only content. RichText fields, Exponential Layouts or other platform-only data have no legacy reading of their own: list the field types in use and check them against chapter 16.6.3.
3. On a v5 database, reverse the ibexa_* table renames (or keep the translator extension active) (chapter 16.6.4 step 2).
4. Check the schema against Exponential 6 with ezsqldiff.php (reference first) and apply the missing tables and columns; then apply the current update/database/<engine>/6.0/ files as chapter 11.6 says.
5. Install Exponential 6 (a Git clone with history is recommended, chapter 3), copy ezpublish_legacy/settings/override/, settings/siteaccess/, the extensions and the storage into it, and put the database connection back into settings/override/site.ini.append.php.
6. Serve it with Velocity or Apache/nginx with PHP-FPM (chapter 8); the addresses of the legacy siteaccesses stay the same; addresses that Symfony routes served (REST v2, Twig-only pages) need redirects or a replacement.
7. Passwords: users who signed in on the Symfony side have type 7 hashes, which Exponential 6 reads.

6. Verify #

• Counts of objects per class and language, users, URL aliases before and after.
• The front page, one page per class, both admins: edit and publish one item from each.
• An image variation, an upload, the search, the legacy cron parts run by hand.
• var/log of Symfony and ezpublish_legacy/var/log/error.log are clean.
• The product's book has the commands per line (chapter 10.8).

7. Rollback #

The platform's update files alter rows and add tables but cannot be undone by another SQL file. Rollback is the backup from step 1, plus the old Exponential 6 installation, kept untouched until the new one has run in production for a while.

8. Risks #

9. Checklist #

• To do: Line chosen (arrive on 2.5, move up later); version given explicitly.
• To do: Exponential 6 at its newest release; backup restored once.
• To do: MySQL tables on utf8mb4; 2.5 kernel update files applied and their errors read.
• To do: Missing 2.5 tables created; ezsqldiff.php (reference first) shows no missing table or column.
• To do: Project created, installer not run on the data; storage moved.
• To do: Legacy settings moved, connection values removed; siteaccesses in YAML with legacy_mode.
• To do: Image aliases declared as variations; extensions moved and autoloads regenerated.
• To do: Caches cleared on both sides, search reindexed, cron through the bridge.
• To do: Front end and both admins verified; rollback plan agreed.

This page is part of the Exponential documentation and is free documentation under the GNU Free Documentation License 1.3 or any later version (the license of this documentation).