Pimcore übernehmen: Was ein neuer Betreuer braucht

Die Agentur, die Ihre Pimcore-Installation gebaut hat, antwortet nicht mehr. Das System läuft weiter, Bestellungen kommen an, Produktdaten gehen in den Shop. Nur hat seit zwei Jahren niemand ein Update eingespielt, und im Unternehmen kennt niemand den individuellen Code. So beginnen die meisten Übernahmen, die wir sehen.

Dieser Artikel nennt die 15 Angaben und Zugänge, die ein neuer Betreuer von Ihnen braucht, und was jeweils passiert, wenn einer davon fehlt.

Warum Übernahmen an Unterlagen scheitern und nicht an Technik

Eine Pimcore-Installation zu übernehmen ist selten ein technisches Problem. Der Code ist da, das System läuft, und Pimcore ist dokumentiert. Was fehlt, ist das Wissen darüber, warum etwas so gebaut wurde, wer worauf Zugriff hat und welche Prozesse im Hintergrund laufen.

Deshalb entscheidet die Vorbereitung über die ersten Wochen. Wenn Sie die folgenden Punkte zusammenstellen, bevor Sie mit jemandem sprechen, bekommen Sie eine belastbare Einschätzung statt einer Schätzung mit großem Sicherheitsaufschlag. Fehlt vieles davon, ist das kein Ausschlusskriterium. Es verschiebt nur den Aufwand in eine Bestandsaufnahme, die dann vor allem aus Rekonstruktion besteht.

Welche Zugänge braucht ein neuer Betreuer?

Ein Betreuer braucht Zugang zum Code, zum Server, zum System selbst und zur Domain. Diese vier Zugänge sind die Voraussetzung für jede Aussage über Zustand und Risiko. Alles andere lässt sich notfalls rekonstruieren, diese vier nicht.

1. Das Repository mit vollständiger Historie. Gemeint ist das Git-Repository mit allen Commits, nicht ein ZIP-Archiv des Produktivverzeichnisses. Fehlt das: Jede Anpassung muss aus dem laufenden System zurückgelesen werden, und niemand kann unterscheiden, was bewusst so gebaut und was unter Zeitdruck hineingeschrieben wurde. Der erste Fehler wird damit zur Rekonstruktionsarbeit.

2. Serverzugang und die Liste aller, die ihn haben. Dazu gehören SSH-Zugang, Deploy-Benutzer, Datenbankbenutzer und die hinterlegten öffentlichen Schlüssel. Fehlt das: Schlüssel der früheren Agentur bleiben aktiv, Änderungen am Server lassen sich niemandem zuordnen, und ein Sicherheitsvorfall bleibt unerklärlich.

3. Administratorzugang in Pimcore und die Benutzerliste mit Rollen. Pimcore verwaltet Benutzer, Rollen und Arbeitsbereiche im System selbst. Fehlt das: Verwaiste Administratorkonten bleiben bestehen, Redaktionsrechte lassen sich nicht prüfen, und nach einem Personalwechsel weiß niemand, wer was ändern darf.

4. Domain, DNS-Verwaltung und Zertifikate. Wer ist Registrar, wo liegen die DNS-Einträge, wie werden die TLS-Zertifikate erneuert. Fehlt das: Ein ablaufendes Zertifikat macht den Shop unerreichbar, und niemand hat den Zugang, um es zu erneuern. Bei einem Serverumzug fehlt der Hebel für die Umstellung.

Welche Angaben zum System sind vor der ersten Zeile Code nötig?

Vor jeder Aussage über Update-Pfad und Aufwand stehen vier Angaben: Versionsstände, Erweiterungen, individueller Code und der Weg auf den Server. Sie bestimmen, ob ein Update ein Wochenendprojekt oder ein Quartalsthema ist.

5. Versionsstände von Pimcore oder OpenDXP, PHP, Datenbank und Symfony. Ohne diese vier Zahlen lässt sich kein Update-Pfad benennen. Die PHP-Version ist dabei oft der härtere Zwang als Pimcore selbst: PHP 8.3 erhält seit dem 31. Dezember 2025 keine Sicherheitsupdates mehr, für PHP 8.4 endet die Sicherheitsunterstützung am 31. Dezember 2026 (Stand 29. September 2026, Quelle 1). Fehlt das: Jede Aufwandsangabe ist geraten, und eine Installation auf einer nicht mehr unterstützten PHP-Version läuft ohne Sicherheitsnetz weiter.

6. Liste der Bundles und Erweiterungen samt Lizenzen. Bundles sind die Erweiterungspakete, mit denen Pimcore um Funktionen ergänzt wird, etwa für Shop, Import oder Suche. Notieren Sie auch, welche davon kommerziell lizenziert sind und wann die Lizenz ausläuft. Fehlt das: Ein Upgrade scheitert an einem einzigen nicht mehr gepflegten Bundle, und zwar meist erst nach mehreren Tagen Arbeit.

7. Wo der individuelle Code liegt und was er überschreibt. Gemeint sind eigene Bundles, überschriebene Templates, Event-Listener und Eingriffe in Kernverhalten. Fehlt das: Ein Update setzt Anpassungen zurück, und der Fehler zeigt sich erst in der Produktion, weil niemand wusste, dass an dieser Stelle etwas überschrieben war.

8. Der Weg vom Commit auf den Server. Also: Composer-Installation, Asset-Build, Deployment-Skript oder Pipeline, und wer den Vorgang auslösen darf. Fehlt das: Die Auslieferung ist nicht reproduzierbar, Korrekturen landen per FTP am Repository vorbei, und der nächste reguläre Deploy setzt sie stillschweigend zurück.

Was muss über Daten und Schnittstellen bekannt sein?

Die Datenstruktur und die angebundenen Systeme sind der Teil, der bei einer Übernahme am meisten Schaden anrichten kann. Wer hier ohne Kenntnis eingreift, zerstört Daten, die in keinem Backup einzeln wiederherstellbar sind.

9. Export der Klassendefinitionen und der Datenstruktur. Dazu gehören Objektklassen, Fieldcollections, Objektbricks sowie die Frage, wo mit Vererbung und Varianten gearbeitet wird. Fehlt das: Eine einzelne Feldänderung kann vererbte Werte in tausenden Objekten überschreiben, ohne dass jemand die Ursache sieht.

10. Alle Schnittstellen mit Richtung, Takt und Ansprechpartner. Für jede Verbindung zu ERP, Shop, Versanddienstleister oder Übersetzungsdienst: Wer ruft wen auf, wie oft, mit welchen Zugangsdaten, und wer betreut das System auf der Gegenseite. Fehlt das: Der nächtliche Import bricht ab, und im Haus weiß niemand, bei wem man anruft.

11. Backups mit dem Datum des letzten geprüften Restores. Nicht nur, was gesichert wird und wohin, sondern wann zuletzt jemand eine Sicherung zurückgespielt und das Ergebnis geprüft hat. Fehlt das: Sie haben Sicherungen, aber keinen belegten Wiederherstellungsweg. Das fällt immer im schlechtesten Moment auf.

Was gehört aus dem laufenden Betrieb dazu?

Der Betrieb ist der Teil, den Übergaben am häufigsten auslassen, weil er unsichtbar läuft. Vier Punkte gehören dazu: geplante Aufgaben, ein Testsystem, vorhandene Dokumentation und die Zuständigkeit auf Ihrer Seite.

12. Cronjobs und geplante Aufgaben. Dazu zählen das Pimcore-Maintenance-Kommando, Import- und Exportjobs sowie Prozesse, die Warteschlangen abarbeiten. Fehlt das: Der Maintenance-Lauf steht still, Papierkorb und Versionsstände wachsen unbemerkt, und der Suchindex zeigt Daten von vorgestern.

13. Ein Testsystem und der Weg, es mit der Produktion abzugleichen. Wichtig ist nicht nur, dass es existiert, sondern wie aktuell die Daten darauf sind und wer es aufsetzt. Fehlt das: Updates werden im Livesystem getestet, und der erste Rollback findet unter Beobachtung des ganzen Hauses statt.

14. Dokumentation, auch unvollständige. Alte Konzepte, Tickets, Übergabeprotokolle, selbst Notizen in einem Wiki helfen weiter. Fehlt das: Sie bezahlen dasselbe Wissen zweimal, einmal beim Bauen und einmal beim Rekonstruieren.

15. Ansprechpartner bei Ihnen und der Entscheidungsweg. Wer beantwortet fachliche Rückfragen, wer entscheidet über Aufwände, und wer gibt ein Wartungsfenster frei. Fehlt das: Rückfragen bleiben wochenlang liegen, und aus einer Übernahme von wenigen Wochen wird ein halbes Jahr.

Wann eine Übernahme nicht der richtige Schritt ist

Nicht jede verwaiste Installation gehört übernommen. Wir verdienen an Übernahmen, deshalb sagen wir die Gegenseite deutlich dazu.

Die bisherige Agentur kann und will weiterarbeiten. Dann kostet ein Wechsel vor allem Einarbeitung. Dieses Geld fehlt anschließend für die Erweiterungen, die Sie eigentlich vorhatten. Ein Gespräch über Reaktionszeiten ist in diesem Fall der günstigere Weg.
Das System trägt nur eine überschaubare Website. Wenn keine Produktdaten, keine Schnittstellen und keine Shop-Logik dahinterstehen, ist die richtige Frage nicht, wer Pimcore übernimmt, sondern ob Pimcore für diesen Zweck noch das passende System ist.
Das Geschäftsmodell hat sich verändert und die Datenstruktur passt nicht mehr. Wenn die Objektklassen ein Sortiment abbilden, das es so nicht mehr gibt, ist die Übernahme nur der erste Teil der Rechnung. Der Umbau danach kann teurer werden als ein Neuaufbau.
Niemand im Unternehmen hat Zeit für Rückfragen. Eine Übernahme braucht in den ersten Wochen Ihre Fachabteilung. Ohne diese Zeit verzögert sich alles, unabhängig davon, wer die Arbeit macht.

Was wir bewusst nicht versprechen: eine feste Dauer ohne Bestandsaufnahme und eine Migration ohne Risiko. Beides hängt von Punkten ab, die vor der Analyse niemand kennt.

Fragen und Antworten zur Übernahme einer Pimcore-Installation

Die Fragen, die in Gesprächen über verwaiste Installationen am häufigsten kommen. Einzelne Punkte stehen ausführlicher im Artikel zum Ablauf eines Pimcore-Updates, im Vergleich von Pimcore und OpenDXP und im Beitrag zum Pimcore-Hosting.

Was tun wir, wenn die alte Agentur nicht mehr erreichbar ist?

Dann rekonstruieren wir den Stand aus dem laufenden System. Aus einer Installation lassen sich Versionsstände, installierte Bundles, Klassendefinitionen und Cronjobs auslesen; damit steht der größte Teil der Liste oben. Aufwendig wird es bei der Frage, warum etwas so gebaut wurde. Diese Antwort steckt in der Commit-Historie, und wenn die fehlt, bleibt nur der Code selbst.

Müssen wir vor einer Übernahme erst updaten?

Nein, und meistens wäre es die falsche Reihenfolge. Ein Update auf ein System, das niemand kennt, vergrößert das Risiko. Zuerst kommt die Bestandsaufnahme, dann die Entscheidung über den Update-Pfad, dann ein Testlauf auf einem Staging-System.

Wie lange dauert eine Übernahme?

Das hängt von Versionsstand, Menge des individuellen Codes und Zahl der Schnittstellen ab. Eine seriöse Angabe gibt es erst nach der Bestandsaufnahme. Als Orientierung aus einem konkreten Projekt: Wir haben 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.

Was passiert mit unserem individuellen Code?

In der Regel bleibt er erhalten. Angepasst werden müssen Stellen, die auf Kernverhalten aufsetzen, das sich zwischen den Versionen geändert hat, sowie Abhängigkeiten zu Bundles, die es in der Zielversion nicht mehr gibt. Genau deshalb steht Punkt 7 auf der Liste: Was überschrieben wurde, muss vor dem Update bekannt sein.

Müssen wir bei einer Übernahme auf OpenDXP wechseln?

Nein. Wir setzen Pimcore 12 um und betreiben bestehende Pimcore-Installationen weiter. OpenDXP ist ein Fork von Pimcore 11 unter der GPLv3 und damit ohne Umsatzgrenze nutzbar (Stand 29. September 2026, Quelle 2); für Unternehmen, die genau diese Grenze fürchten, ist das ein Argument.

Was, wenn es überhaupt keine Dokumentation gibt?

Das ist der Normalfall und kein Hindernis. Die Bestandsaufnahme erzeugt dann die erste Dokumentation: Versionsstände, Bundles, Datenmodell, Schnittstellen, Cronjobs, Backup-Weg. Wichtig ist nur, dass dieses Dokument danach gepflegt wird, sonst steht in zwei Jahren dieselbe Frage wieder an.

Wer betreibt den Server nach der Übernahme?

Das ist eine getrennte Entscheidung. Eine Übernahme der Entwicklung bedeutet nicht automatisch einen Wechsel des Hostings, und ein Wechsel lässt sich auch später machen.

Wenn Sie eine Übernahme prüfen

Wenn Ihre Installation ohne Betreuung läuft: Schicken Sie mir die Pimcore-Version, die PHP-Version und die Liste der installierten Bundles. Das sind drei Angaben, die Sie ohne Vorbereitung aus dem System holen können. Ich sehe sie durch und sage Ihnen, welcher der 15 Punkte in Ihrem Fall kritisch wird und ob der nächste Schritt ein Update, eine Migration oder erst einmal nur der Weiterbetrieb ist. Bei Viucom mache ich das selbst, es gibt keine Übergabe an jemand anderen. Mehr zu unserer Arbeit mit dem System steht auf der Seite Pimcore-Betreuung und Weiterentwicklung.