Migrating Pimcore 11 to 12 – the License Gate First, Then the Technology.

Most project plans treat an 11-to-12 upgrade like a technical intermediate step: a few Composer commands, a deployment, done. In practice, the first hurdle isn't technical at all, it's a licensing decision: starting with Pimcore 12, the Community Edition runs under POCL instead of GPLv3, and without a registered product key, the build simply fails. Anyone who reverses this order and migrates technically first, then thinks about the license, risks a finished migration plan that ultimately fails on a question that could have been settled from the start.

Phase 0: The License Gate, Before the First Composer Command

Four points belong before any technical planning: the switch from GPLv3 to POCL for the Community Edition, the mandatory product registration in place since 12.0, without a valid product key registered at license.pimcore.com, no build starts –, the 1,480-euro one-time license for the classic admin UI on Community, and the fact that ee-commerce, ee-web-to-print, and ee-personalization are only available under the Enterprise subscription as of version 12. Each of these four points can stop a project if it only surfaces mid-implementation instead of at the start.

The Technical Breaking Changes in Detail

The starting point is the last 11.5.x version (PHP 8.1–8.3, Symfony 6.4, DBAL 3), the target is the 12.x line (PHP roughly 8.3/8.4, with a newly required OpenSSL PHP extension, Symfony still ^6.4, with an additional dual ^7.3 controllable via a dedicated freeze bundle starting with version 12.3, DBAL ^4, ORM ^3). The DBAL 3-to-4 switch brings concrete code fallout: a central database helper function loses one of its parameters, an upsert method now returns the last insert ID, and a listing count method was reworked. Anyone with custom code that writes directly against these APIs should search for it specifically before migrating, rather than discovering it at the first error.

The Collation Trap: utf8mb4_unicode_520_ci

Pimcore 12 changes the default database collation from utf8mb4_general_ci to utf8mb4_unicode_520_ci. New tables automatically get the new collation, existing ones keep the old one: The result is an "Illegal mix of collations" error as soon as a DataObject is opened whose tables sit on different collations. The fix is to consistently convert all tables, using the official SQL generator snippets. As a rough practical benchmark: about 18 minutes for 680 tables. That's enough to plan a maintenance window around, but it remains a step that can't be skipped on larger databases.

The WYSIWYG Switch: Quill Instead of TinyMCE

Starting with 12.0, Quill is the recommended WYSIWYG editor. TinyMCE keeps running technically, but is considered deprecated for the Community Edition, with no promised security updates. Anyone continuing to run TinyMCE unchanged after the upgrade should treat that as a deliberate, time-limited decision, not as "it still works."

Generic Data Index: The Order Nobody Should Skip

A detail missing from many migration plans: the Generic Data Index's indexes must already exist before the database migrations run. If they're missing, the migration aborts with an "index_not_found_exception" error, and in the worst case, a corrupted intermediate migration is left behind. The GDI itself needs OpenSearch 2.7 or later, or Elasticsearch 8.0 or later, plus its own Messenger workers, which need to be live before the actual migration run.

One Detail That's Easy to Miss

The encryption secret, which can be generated automatically from the command line, should be generated early and stored in a secret manager, not as an afterthought. If this secret is lost after encryption, the affected data is unrecoverable, regardless of how carefully the rest of the migration went.

The 11.5 LTS Alternative: Staying Is Also a Valid Answer

Platform Version 2024.4 (Pimcore 11.5) runs with LTS support through December 2026, GPLv3, classic admin UI, no license gate. Anyone who needs that time for the licensing or Studio decision can deliberately use it, rather than pushing an upgrade under time pressure, more in the Pimcore Migration overview.

Praetorian Angle: Audit Before Composer Command

We make the license gate the first decision of every 11-to-12 project, not the unpleasant surprise after project start. An upfront Pimcore Audit covers the bundle inventory, DBAL-4 hits in custom code, the collation plan, and the necessary GDI infrastructure lead time, embedded in our Upgrades & Migration service. We regularly take over rescue cases where a previous vendor already failed at the 11-to-12 upgrade, usually because exactly this order wasn't followed.