Pimcore nach OpenDXP migrieren: Ablauf in sechs Schritten

Die Lizenzfrage ist inzwischen beantwortet: Wer Pimcore 12 einsetzt, arbeitet unter der Pimcore Open Core License. OpenDXP ist ein Fork von Pimcore 11 unter der GPLv3 (Open Source); die Unterschiede im Einzelnen stehen in unserem Vergleich von Pimcore und OpenDXP. Was in den Gesprächen danach fehlt, ist die praktische Frage: Wie läuft so eine Migration ab, und woran scheitert sie?

Dieser Artikel beschreibt den Ablauf in sechs Schritten, nennt die Stellen, an denen stillschweigend etwas kaputtgeht, und sagt, was bei Installationen älter als Pimcore 11 zusätzlich dazukommt.

OpenDXP ist kein neues System, sondern ein Fork der Pimcore Community Edition auf dem Stand 11.5 (Stand November 2026, Quelle 1). Der Code ist derselbe, umbenannt. Aus dem Namensraum Pimcore\ wird OpenDxp\, aus dem Konfigurationsschlüssel pimcore wird opendxp, aus den Twig-Funktionen pimcore_* werden opendxp_*, aus den Konsolenbefehlen pimcore: werden opendxp:.

Ein Detail daran entscheidet über den Aufwand: Beide Namen sind sieben Zeichen lang. In serialisierten PHP-Daten steht die Länge jeder Zeichenkette mit in der Datenbank. Ein Suchen und Ersetzen über serialisierte Felder ist deshalb längensicher und verbiegt keine Datensätze. Das ist der Grund, warum diese Migration überhaupt mit vertretbarem Aufwand machbar ist.

Für Ihre Installation heißt das: Der eigene Code ist der berechenbare Teil. Teuer wird, was daneben liegt.

Vier Angaben entscheiden über alles Weitere: Ausgangsversion von Pimcore, PHP-Version, Liste der installierten Bundles und Umfang des individuellen Codes. Dazu die Größe der Datenbank, weil sie das Wartungsfenster bestimmt.

Ab Pimcore 11.5 ist der Weg kurz, weil das Datenbankschema dem von OpenDXP entspricht. Von älteren Ständen kommt eine Migrationskette dazu, dazu weiter unten mehr.

Das ist der Schritt, den Angebote am häufigsten überspringen, und die häufigste Ursache für Nachträge.

Ein Bundle, das pimcore/pimcore verlangt und den Namensraum Pimcore\ benutzt, läuft unter OpenDXP nicht. Ob es weitergeht, hängt daran, ob jemand ein OpenDXP-Paket liefert. Für jedes Bundle aus Ihrer config/bundles.php gehören vier Fragen beantwortet, bevor eine Zahl im Angebot steht: Gibt es ein OpenDXP-Paket, von wem, auf welcher Ausgangsversion basiert es, und unter welcher Lizenz?

Drei Antworten haben Folgen für den Plan:

• Ein Fork setzt eine bestimmte Ausgangsversion voraus. Oft muss das Bundle noch unter Pimcore auf genau diesen Stand gehoben werden, samt dessen eigener Datenbankmigrationen, bevor der Wechsel überhaupt möglich ist.
• Bei kommerziellen Bundles ist die Lizenzfrage offen, bis sie jemand klärt. Das ist eine Entscheidung mit Vorlauf, kein Schritt im Composer-Lauf.
• Schnittstellenpfade ändern sich. Beim Data Hub etwa heißt der GraphQL-Endpunkt nach der Migration anders. Externe Systeme, die den alten Pfad aufrufen, bekommen danach lautlos nichts. Entweder sie werden umgestellt, oder es braucht eine Alias-Route.

Den tatsächlichen Nutzungsumfang eines Bundles lesen Sie dabei aus der Datenbank, nicht aus dem Repository. Eingecheckte Exporte zeigen nur, was irgendwann jemand exportiert hat. Maßgeblich sind die Tabellen des Bundles und seine Laufhistorie, also das, was heute noch läuft.

Die eigentliche Umbenennung ist mechanisch und in wenigen Minuten erledigt. Vier Stellen werden dabei regelmäßig vergessen, und jede davon kostet anschließend Stunden Fehlersuche.

Die Umbenennung darf nicht auf PHP-Dateien beschränkt werden. Konfigurationsdateien, Templates, JavaScript und die Laufzeit-Konfiguration unter var/config gehören dazu. Die Klassendefinitionen unter var/classes ebenfalls. Wer beides auslässt, bekommt beim ersten Start einen Container-Fehler ohne brauchbare Meldung.

Das Admin-Objekt im JavaScript heißt opendxp, nicht pimcore. Eigene Backend-Erweiterungen brechen sonst mit der Meldung „pimcore is not defined“. Im Produktionsmodus ist das Admin-JavaScript zusammengefasst, ein Fehler am Anfang bricht alles danach ab. Typisches Symptom: Der WYSIWYG-Editor erscheint nicht mehr.

Ein pauschales Ersetzen trifft auch Daten, die der Server weiter mit pimcore liefert. Spaltennamen in Rastern, Statuswerte, Parameternamen. Das erzeugt keinen Fehler: Spalten bleiben leer, Schaltflächen verschwinden, eine Anfrage antwortet mit 400. Nach dem Ersetzen gehört jeder geänderte Bezeichner gegen den zugehörigen PHP-Code geprüft.

Der Cache muss vorher weg. Ein cache:clear kann einen Plattformwechsel nicht aufräumen, weil es den alten Container zum Aufräumen braucht.

Hier gilt das Gegenteil von Schritt 3: nicht pauschal ersetzen, sondern gezielt suchen.

Der Suchbegriff ist Pimcore\ mit Backslash, also der Namensraum. Damit bleibt das Wort „Pimcore“ in Ihren Inhalten unberührt, in Blogartikeln, Produkttexten und Dokumentnamen. Welche Spalten überhaupt betroffen sind, findet eine Abfrage über alle Text- und Blob-Spalten des Schemas. In der Praxis bleiben wenige übrig, und sie liegen an Stellen, an die niemand denkt: ein Link-Editable speichert eine serialisierte Klasse im Dokumentinhalt, dazu Properties, Rasterkonfigurationen, Notizen.

Vier Tabellen brauchen eine Sonderbehandlung:

• settings_store: Hier wird nicht nur die Spalte id umbenannt, sondern auch scope. OpenDXP liest die Installationsmarker der Bundles unter dem Bereich opendxp. Bleibt scope auf pimcore, meldet jedes Bundle sich als nicht installiert, und mit ihnen verschwinden Thumbnails, Dokumenttypen, Static Routes und wieder der WYSIWYG-Editor.
• messenger_messages: Die serialisierten Nachrichten tragen den Namen ihres Nachrichtenbusses mit. Wird der nicht mitumgeschrieben, verwirft der Worker jede übernommene Nachricht. Auf dem Produktivsystem fällt das erst auf, wenn eine Aktualisierung des Suchindex fehlt. Prüfen lässt sich das nur, indem man eine übernommene Nachricht tatsächlich verarbeiten lässt, nicht indem man sie ansieht.
• migration_versions: Diese Einträge werden nicht umbenannt. OpenDXP bringt eine eigene, kurze Migrationshistorie mit, die Pimcore-Einträge finden keine Entsprechung.
• cache_items: leeren, und zwar per TRUNCATE. In Bestandsdatenbanken ist diese Tabelle oft mehrere Gigabyte groß; ein DELETE liefe mitten im Wartungsfenster minutenlang.

Den Durchlauf führen Sie zweimal aus. Der zweite muss null Zeilen ändern. Das ist der billigste Nachweis, dass nichts übersehen wurde.

Eine Migration ist dann fertig, wenn jemand zeigen kann, dass die Daten dieselben sind. „Sieht gut aus“ reicht dafür nicht.

Der Weg, der sich bewährt hat: je Tabelle die Zeilenzahl und eine Prüfsumme über alle Spalten bilden, vor und nach der Umstellung. Abweichungen müssen einzeln erklärbar sein. Verwaiste Verweise auf gelöschte Objekte, die dabei verschwinden, sind in Ordnung. Eine Tabelle mit weniger Zeilen als vorher ist es nicht.

Zwei Dinge gehören auf dieselbe Liste, weil sie sich sonst erst im Betrieb zeigen: Der WYSIWYG-Editor muss erscheinen, und eine Nachricht aus der Warteschlange muss tatsächlich verarbeitet werden.

Im Wartungsfenster wird nur noch eingespielt, was vorher erzeugt wurde: der migrierte Datenbankabzug in eine neue Datenbank. Die alte bleibt unangetastet und ist damit der Rückweg. Dasselbe gilt für das Projektverzeichnis.

Wenn die Umstellung im bestehenden Verzeichnis passiert, verschieben Sie nur bekannte Pfade nach einer festen Liste, nie „alles außer var“. Der Altordner bekommt Rechte 700, weil darin die alte Konfiguration mit Zugangsdaten liegt.

Von Pimcore 6 oder 10 aus fehlen die Core-Migrationen dazwischen. Code und Datenbank nehmen dann getrennte Wege:

• Der Code wird einmal direkt auf das OpenDXP-Gerüst portiert, ohne Zwischenstand. Ab Pimcore 10 gibt es keine PHP-Templates mehr, der betroffene Code wird ohnehin neu geschrieben.
• Die Datenbank läuft durch die offizielle Kette, Stufe für Stufe mit einem leeren Gerüst der jeweiligen Version: 6.9 auf PHP 7.4, dann 10.6 auf PHP 8.1, dann 11.5 auf PHP 8.3, dann OpenDXP. Was bei jeder einzelnen Stufe zu beachten ist, steht in unserem Artikel zum Ablauf eines Pimcore-Updates.

Das klingt nach viel und ist vor allem Fleißarbeit, die als ein Skript läuft. Wir haben für einen Kunden eine Installation von Pimcore 6.9 nach OpenDXP migriert, mit mehreren Domains und über 25.000 Zeilen individuellem Code, der erhalten blieb. Der Umbau dauerte drei Wochen. Das ist ein Fall, kein Richtwert.

Zwei Eigenheiten dieser Kette sind erwähnenswert, weil sie Zeit kosten und nirgends dokumentiert sind. Pimcore 10.6 läuft nur auf PHP 8.0 oder 8.1. Und eine Migration auf der Stufe 11 bricht ohne Debug-Modus mit einer Meldung ab, die den falschen Ordner nennt.

Eine dritte Eigenheit betrifft nicht die Technik, sondern die Uhrzeit: Pimcore 6 hat die Zeitzone aus den Systemeinstellungen gesetzt. Ab Pimcore 11 und OpenDXP gilt die Einstellung der PHP-Installation, und die steht auf Servern oft auf UTC. Die Daten stimmen dann, die Uhrzeiten in PDFs und Objektschlüsseln liegen ein bis zwei Stunden daneben.

Die Standardregel der Webserver-Konfiguration gibt jede Datei des Asset-Speichers direkt aus, wenn der Pfad bekannt ist, seit Pimcore 6 bis heute. Bei Installationen, die vertrauliche Dokumente als Assets ablegen, ist das ein Datenleck, das eine Migration sonst unverändert übernimmt. Prüfbar in einer Minute: Rufen Sie den Pfad eines vorhandenen Assets ohne Anmeldung ab. Kommt eine Datei zurück, gehört die Regel geändert. Weitere Punkte für den Betrieb nach der Umstellung stehen in unserem Artikel zum OpenDXP-Hosting.

Die Migration von Pimcore 11 zu OpenDXP ist für Sie der richtige Schritt, wenn Sie weiter Open-Source-Software einsetzen wollen. Pimcore steht ab Version 12 unter der Pimcore Open Core License (POCL) und ist damit nicht mehr Open Source.

Schicken Sie mir die Pimcore-Version, die PHP-Version und die Liste aus Ihrer config/bundles.php. Aus diesen drei Angaben sage ich Ihnen, ob Ihr Fall der kurze Weg ab 11.5 ist oder die Kette, welche Bundles den Plan bestimmen und woran der Aufwand hängt. Bei Viucom mache ich das selbst, es gibt keine Übergabe an jemand anderen. Einen Überblick über unsere Arbeit mit beiden Systemen gibt die Seite Pimcore und OpenDXP bei Viucom.

1. open-dxp/opendxp, Repository mit Lizenz GPLv3 und Fork-Basis Pimcore 11.5, GitHub, abgerufen am 05.11.2026

Recherche und Entwurf mit Unterstützung von Claude; geprüft und freigegeben von Simon Back. Bild mit der Bild-API von OpenAI erstellt.