Von Pimcore zu OpenDXP wechseln – GPLv3 behalten, ohne in eine Sackgasse zu laufen.

Wer heute auf Pimcore 11.5 sitzt, steht spätestens mit dem LTS-Ende im Dezember 2026 vor einer Entscheidung: bleiben, ohne offizielle Sicherheitsupdates, upgraden auf Pimcore 12 mit POCL-Lizenz und Produktregistrierungspflicht, oder wechseln zu OpenDXP, dem GPLv3-Fork derselben Codebasis. Diese Seite behandelt den dritten Weg konkret: für wen er passt, was er technisch bedeutet, und was man dafür aufgibt. Mehr zur Leistung selbst steht unter OpenDXP als Alternative.

Für wen der Wechsel zu OpenDXP Sinn ergibt

Der Wechsel passt für Unternehmen, die auf einem soliden Pimcore-11.5-Bestand sitzen, mit dem Funktionsniveau zufrieden sind und vor allem eines wollen: GPLv3 als Lizenzmodell behalten, ohne im Dezember 2026 ohne Sicherheitsupdates dazustehen. Er passt ebenso für Unternehmen über der POCL-Umsatzschwelle, die kein Enterprise-Abo abschließen wollen, und für Betriebe, die die GPL-E-Commerce- oder Web2Print-Bundles weiter nutzen möchten, die Pimcore bei Version 12 enterprise-only gemacht hat. Der Zeitanker ist dabei bewusst gesetzt: Dezember 2026 ist kein beliebiges Datum, sondern das Ende des offiziellen LTS-Supports für 11.5. Wer bis dahin keine Entscheidung trifft, trifft sie faktisch durch Untätigkeit.

Was der Wechsel technisch bedeutet

Der Wechsel ist kein Drop-in, aber auch kein Neubau. Voraussetzung ist eine aktuelle, saubere Pimcore-11.5.x-Installation, wer noch auf einer älteren 10er- oder frühen 11er-Version sitzt, braucht davor die reguläre Konsolidierung, wie sie auch unter Pimcore-Migration beschrieben ist. Ist diese Basis vorhanden, teilen OpenDXP und Pimcore 11.5 dieselbe Datenbankstruktur und Klassenlogik. Es findet kein Datenmodell-Rebuild statt, keine Re-Modellierung, kein Export und Reimport von Daten. Migriert werden Namespaces, Konfigurationspräfixe und Referenzen im Code, nicht die Datenstruktur selbst.

Die Rename-Systematik im Detail

Konkret stellt der Wechsel mehrere Ebenen im Projekt systematisch von der Pimcore- auf die OpenDxp-Bezeichnung um: Namensräume, Konfigurationspräfixe und Umgebungsvariablen im Custom-Code, dazu Composer-Abhängigkeiten, das Konfigurationsverzeichnis, Konsolenbefehle und Template-Funktionen. Ergänzend werden gespeicherte Einstellungen in der Datenbank, einzelne betroffene Methodennamen und serialisierte Datenbankreferenzen in Dokumenten-Editables und Properties per SQL-Skript mit umgeschrieben. Ein separater Leitfaden regelt zusätzlich die Migration von Dokument-, Asset- und Objekt-Versionsdaten. Jeder dieser Schritte ist für sich genommen mechanisch, in Summe aber ein Projekt mit echtem Umfang: kein Drop-in, aber systematisch, kein Konfigurationsschalter.

Was Sie aufgeben, wenn Sie wechseln

OpenDXP bleibt technisch auf dem Stand von Pimcore 11: keine Pimcore-Studio-Oberfläche, kein Generic Data Index in der 12er-Ausprägung, keine kommerziellen Enterprise-Bundles wie Portal Engine oder Data Quality Management, kein kommerzieller Support mit Hersteller-SLA. Wer diese Bausteine perspektivisch braucht, plant den Wechsel besser nicht als Zwischenlösung, sondern prüft direkt den Upgrade-Pfad auf Pimcore 12 unter Pimcore 11 auf 12 migrieren. Der Rename ist prinzipiell reversibel, beide Systeme teilen dieselbe Codebasis-DNA. Je weiter ein Projekt auf der eigenständigen OpenDXP-1.x-Linie weiterläuft, desto aufwendiger wird der Rückweg.

Drei Wege ab Pimcore 11.5

Bleiben auf 11.5/GPLv3 ist bis Dezember 2026 sicher, aber befristet, danach fehlen offizielle Sicherheitsupdates. Upgraden auf Pimcore 12 bedeutet POCL-Konformität und Produktregistrierungspflicht, dafür vollen Zugriff auf Studio, aktuelle Bundles und Hersteller-Support (mehr unter Upgrades & Migration). Wechseln zu OpenDXP hält GPLv3 über Dezember 2026 hinaus am Leben, ohne POCL, aber auch ohne Studio, Enterprise-Bundles und Herstellergarantie. Keiner der drei Wege ist pauschal richtig, welcher passt, klärt ein Pimcore-Audit vor der Entscheidung. Dieselbe Dreiweg-Logik, mit Fokus auf die Lizenzfrage selbst, steht unter Pimcore Open Source vs. kommerzielle Lizenz.

"Pimcore-Lizenz umgehen", warum das der falsche Rahmen ist

Wer nach einem Weg sucht, die Pimcore-Lizenz zu umgehen, sollte die Erwartung an dieser Stelle gerade rücken: OpenDXP ist kein Trick, um Pimcore-12-Funktionen kostenlos zu bekommen. Es ist ein legaler GPLv3-Fork der letzten GPLv3-Version von Pimcore, technisch und rechtlich sauber, weil die geforkte Pimcore-11.5-Codebasis selbst unter GPLv3 stand. Wer zu OpenDXP wechselt, bekommt Pimcore 11 unter einer offenen Lizenz weiterbetrieben, nicht Pimcore 12 ohne Rechnung. Diesen Unterschied klar zu benennen ist Beratungsqualität, kein Verkaufshemmnis. Wer mit der falschen Erwartung startet, ist am Ende enttäuscht, unabhängig davon, wie sauber die technische Migration lief.

Aufwandstreiber: warum der Core-Rename nicht das Teuerste ist

Der dokumentierte Core-Rename ist bei einem sauberen, aktuellen 11.5-System mit wenig Custom-Code überschaubar, immer mit Puffer für serialisierte Referenzen. Der eigentliche Kostentreiber liegt woanders: bei Custom- und Drittanbieter-Bundles ohne OpenDXP-Pendant, die selbst angepasst oder geforkt werden müssen, und bei der anschließenden Test- und QA-Runde. Ohne Bundle-Inventar keine belastbare Zahl. Steht das Ausgangssystem noch auf 10.x oder frühem 11er, kommt die reguläre Konsolidierung auf 11.5 als eigenes Vorprojekt davor.

Unser Vorgehen: Audit vor Rename

Vor jedem Rename steht bei uns ein Bundle-Inventar: welche Drittanbieter-Bundles haben bereits ein OpenDXP-Pendant, welche nicht, wo im Custom-Code stehen noch alte Pimcore-Namensraum- oder Konfigurationsreferenzen, wie umfangreich ist die Test-Abdeckung. Erst danach schätzen wir Aufwand seriös, statt eine Zahl ins Blaue zu nennen. Und wir sagen auch offen, wann Upgraden statt Wechseln der bessere Weg ist, etwa wenn Studio, Enterprise-Bundles oder Hersteller-SLA absehbar gebraucht werden. Das macht die Migrationsempfehlung glaubwürdig, nicht nur verkäuflich.