Switching from Pimcore to OpenDXP – Keep GPLv3 Without Running Into a Dead End.

Anyone running Pimcore 11.5 faces a decision by the time LTS ends in December 2026 at the latest: stay without security updates, upgrade to Pimcore 12 under POCL with mandatory registration, or switch to OpenDXP, the GPLv3 fork of the same codebase. This page covers that third path: who it fits, what it means technically, and what you give up. For the service itself, see OpenDXP as an Alternative.

Who Switching to OpenDXP Makes Sense For

The switch fits companies on a solid Pimcore 11.5 install, happy with the current feature level, who want one thing above all: keep GPLv3 without losing security updates in December 2026. It also fits companies above the POCL revenue threshold who don't want an Enterprise subscription, and operations that want to keep the GPL E-Commerce or Web2Print bundles that became enterprise-only in Pimcore 12. December 2026 is when official LTS support for 11.5 ends, not an arbitrary date, not deciding by then is effectively deciding by inaction.

What the Switch Means Technically

The switch is not a drop-in, but not a rebuild either. It requires a current, clean Pimcore 11.5.x installation, anyone on an older 10.x or early 11.x version needs the regular consolidation first, as described under Pimcore Migration. Once that foundation is in place, OpenDXP and Pimcore 11.5 share the same database structure and class logic. There's no data-model rebuild, no export and reimport. What gets migrated are namespaces, configuration prefixes, and code references, not the data structure itself.

The Rename Systematics in Detail

Concretely, the switch systematically renames several layers in the project from the Pimcore to the OpenDxp label: namespaces, configuration prefixes, and environment variables in custom code, plus Composer dependencies, the configuration directory, console commands, and template functions. On top of that, stored settings in the database, a handful of affected method names, and serialized database references in document editables and properties get rewritten via SQL script. A separate guide covers document, asset, and object version data. Each step is mechanical alone, together they add up to a project with real scope: not a drop-in, but systematic, not a toggle.

What You Give Up When You Switch

OpenDXP stays technically at the Pimcore 11 level: no Studio interface, no version 12 Generic Data Index, no commercial enterprise bundles like Portal Engine or Data Quality Management, no commercial support with a vendor SLA. Anyone who'll need those building blocks should check the upgrade path under Migrating Pimcore 11 to 12, rather than planning the switch as an interim step. The rename is reversible in principle, both share the same codebase DNA, but the further a project runs on its own OpenDXP line, the costlier the way back.

Three Paths From Pimcore 11.5

Staying on 11.5/GPLv3 is safe through December 2026, but time-limited. Upgrading to Pimcore 12 means POCL compliance and mandatory registration, but full access to Studio, current bundles, and vendor support (more under Upgrades & Migration). Switching to OpenDXP keeps GPLv3 alive past December 2026, without POCL, but also without Studio, enterprise bundles, or a vendor guarantee. None of the three paths is universally right, a Pimcore Audit clarifies which one fits before the decision gets made. The same three-way logic, focused on the licensing question itself, lives on Open Source vs. Commercial License.

"Getting Around the Pimcore License", Why That's the Wrong Frame

Anyone searching for a way to get around the Pimcore license should reset that expectation here: OpenDXP is not a trick to get Pimcore 12 features for free. It's a legal GPLv3 fork of the last GPLv3 version of Pimcore, clean technically and legally, because the forked 11.5 codebase itself was under GPLv3. Switching gets you Pimcore 11 kept alive under an open license, not Pimcore 12 without a bill. Stating that clearly is advisory quality, not a sales obstacle, the wrong expectation ends in disappointment regardless of how clean the migration was.

Cost Drivers: Why the Core Rename Isn't the Expensive Part

The documented core rename is manageable on a clean, current 11.5 system with little custom code, always with a buffer for serialized references. The real cost driver sits elsewhere: custom and third-party bundles without an OpenDXP counterpart, which need adapting or forking, plus the testing and QA round that follows. Without a bundle inventory, there's no reliable number. On 10.x or an early 11.x system, the regular consolidation to 11.5 comes first, as its own project.

Our Approach: Audit Before Rename

Before any rename, we run a bundle inventory: which third-party bundles already have an OpenDXP counterpart, where custom code still holds old Pimcore namespace or configuration references, how solid test coverage is. Only then do we estimate effort seriously. We also say openly when upgrading beats switching, for instance when Studio, enterprise bundles, or a vendor SLA are foreseeably needed.