Ein bestehendes Shopware-Projekt übernehmen: Der Audit vor dem ersten Handschlag
„Der Shop läuft, wir brauchen nur jemanden, der ihn weiterpflegt." Klingt harmlos — ist es selten. Wer einen bestehenden Shopware-Shop von einer anderen Agentur oder einem Vorgänger-Entwickler übernimmt, erbt nicht nur Code, sondern jede Entscheidung, die vorher getroffen wurde: welche Plugins gekauft, welche Kernklassen überschrieben, welche Migration halb gemacht wurde. Sichtbar wird das erst, wenn man in der Verantwortung steht. Deshalb gehört vor die Zusage ein strukturierter Audit — und der klärt fast immer Dinge, die im Verkaufsgespräch niemand erwähnt hat.
1. Du erbst Entscheidungen, nicht nur Dateien
Der teuerste Denkfehler bei einer Übernahme ist die Annahme, ein laufender Shop sei ein gelöstes Problem. Ein Shop läuft auch dann noch, wenn das Fundament brüchig ist — bis zum nächsten Shopware-Update, dem nächsten inkompatiblen Plugin oder dem Tag, an dem eine Zahlungsart ausfällt. In dem Moment steht dein Name über der Rechnung, nicht der des Vorgängers. Genauso wenig taugt ein Audit, das dir jemand anders vorlegt, als Datenquelle: Ich habe mehr als einmal die Bestandsaufnahme eines Kollegen geprüft und zentrale Annahmen widerlegt — eine angeblich ausstehende Datenmigration war längst gelaufen, ein „installiertes" Plugin existierte weder in der Datenbank noch im Dateisystem. Bei Zahlen, die deine Kalkulation tragen, gilt: selbst messen, nicht übernehmen. Die Übernahme beginnt nicht mit dem ersten Commit, sondern mit einer ehrlichen Inventur.
2. Die Inventur: Version, Plugins, Custom-Code
Der erste Blick geht auf die Basis. Welche exakte Shopware-Version läuft (nicht „6.6", sondern die Patch-Nummer), und ist sie composer-managed oder klassisch installiert? Das entscheidet über jeden späteren Update-Pfad. Die vollständige Plugin-Liste holst du dir über die Konsole mit bin/console plugin:list, den technischen Gesamtzustand mit bin/console about. Entscheidend ist die Trennung, die diese Liste nicht von selbst macht: Was ist gekauftes Store-Plugin, was ist Custom-Code? Store-Plugins lassen sich aktualisieren und im Zweifel ersetzen. Custom-Code ist genau das, wofür man dich künftig verantwortlich macht — und der Teil, der im Preis fast immer unterschätzt wird. Zähle die Einträge nicht nur, sondern öffne die custom/plugins- und custom/static-plugins-Verzeichnisse und schau, wie viel davon eigenentwickelt ist.
3. Die Lizenzfalle: kommerzielle Extensions hängen am alten Account
Ein Punkt, den fast alle übersehen: Kommerzielle Erweiterungen aus dem Shopware Store sind an den Account und die Domain gebunden, über die sie gekauft wurden — oft der Account der abgebenden Agentur. Bei einem Betreiberwechsel müssen diese Lizenzen aktiv übertragen werden. Das geht laut Shopware-Dokumentation nur im Kundenaccount über die „Lizenz übertragen"-Funktion beziehungsweise den License Transfer Assistant, wird vom Sales-Team geprüft und dauert einige Werktage. Zwei Details mit echtem Konfliktpotenzial: Ein negativer Kontostand blockiert die Übertragung komplett, und die Rechnung wird dem aktuellen Eigentümer ausgestellt und lässt sich danach nicht mehr ändern. Kläre also früh, wem der Shopware-Account gehört, ob abonnierte Extensions bezahlt sind und wer die Übertragung anstößt — sonst steht der Shop nach dem Wechsel plötzlich ohne gültige Lizenzen da, und du erklärst dem Kunden ein Problem, das du nicht verursacht hast.
4. Wo der teure Teil versteckt liegt
Die großen Kostenblöcke stehen selten im Lastenheft. Drei Klassiker: Laufende Abo-Kosten — Warenwirtschaft, POS oder Lager-Erweiterungen rechnen in Shopware 6 zunehmend als Monatsabo statt als Einmallizenz ab; ein ERP-Anschluss kann so still vierstellig pro Jahr kosten, und das ist Betriebskern, kein Testpunkt. Migrationsreste — bei Shops mit Shopware-5-Vergangenheit lohnt der Blick, ob wirklich alle Kunden und Bestellungen übernommen wurden oder ob ein Zeitfenster fehlt. Redirects und SEO-URLs — nach einem Relaunch oder Systemwechsel müssen tausende alte URLs weitergeleitet werden; fehlen die Weiterleitungen, verliert der Shop Rankings, und niemand merkt es sofort. Diese drei Punkte messe ich vor jeder Zusage direkt in der Datenbank, nicht aus Bauchgefühl — die Differenz zwischen „müsste passen" und der tatsächlichen Zahl ist genau der Betrag, den man sonst selbst draufzahlt.
5. Custom-Code prüfen: update-sicher oder Zeitbombe?
Beim eigenentwickelten Code interessiert weniger, ob er funktioniert — das tut er meist, sonst würde der Shop nicht laufen — sondern wie er gebaut ist. Die wichtigste Frage: Wird sauber über Events, Subscriber und Decorators erweitert, oder werden Kernklassen direkt überschrieben? Letzteres ist Update-Schulden auf Raten: Jedes Shopware-Update kann es brechen. Prüfe außerdem, ob Migrations idempotent sind, ob es überhaupt automatisierte Tests gibt und wie oft globale document.querySelector-Zugriffe oder ungeprüfte DAL-Assoziationen im Code stehen — die stillen Fehlerquellen, die erst in einer bestimmten Shop-Konstellation zuschlagen. Ein bin/console debug:container und ein Blick in die Fehler-Logs unter var/log verraten mehr über den echten Zustand als jede Zusicherung. Wenn das Error-Log im Minutentakt dieselbe Exception wirft, ist das kein Kosmetikthema — das ist Arbeit, die du sonst unbezahlt erbst.
6. Zugänge, Infrastruktur und die „eine Person, die alles weiß"
Technik ist das eine, der Zugang das andere. Häufig hängt das gesamte Wissen an einer einzigen Person beim Vorgänger — und die ist nach der Übergabe nicht mehr erreichbar. Deshalb gehört auf die Liste: Server- und Hosting-Zugänge, wo DNS verwaltet wird (oft ein externer Anbieter), wo die Domains liegen, Zugänge zu Git-Repositories, Deployment-Pipelines, Zahlungsdienstleister-Accounts und der Shopware-Account selbst. Prüfe die Serverumgebung nüchtern statt sie vorauszusetzen: Ich habe schon Shops übernommen, deren Trägheit sich per SSH in Minuten erklären ließ — zu wenige CPU-Kerne, kein Redis, eine veraltete Datenbank-Version. Solche Befunde sind wertvoll, weil sie eine spätere „warum ist der Shop so langsam"-Diskussion vorwegnehmen und dir erlauben, den Infrastruktur-Aufwand vorab einzupreisen, statt ihn später als Überraschung zu erklären. Und: Kläre, wie ein Rollback aussieht, falls dein erster Eingriff etwas kippt — ohne Staging-Umgebung ist jeder Fix auf einem Live-Shop ein Risiko.
7. Die Bestandsaufnahme ist eine bezahlte Phase
Der letzte und wichtigste Punkt ist kein technischer: Ein seriöser Audit kostet Zeit — realistisch mehrere Personentage — und die verschenkt man nicht. Der saubere Weg ist, die Analysephase als eigene, klar abgegrenzte Position anzubieten, idealerweise voll anrechenbar, wenn es zur Beauftragung kommt. Das schützt beide Seiten: Der Kunde bekommt eine belastbare Einschätzung statt eines aus der Luft gegriffenen Festpreises, und du kalkulierst nicht ins Blaue, sondern auf Basis gemessener Fakten. Wer stattdessen sofort einen Pauschalpreis nennt, um den Auftrag nicht zu verlieren, kauft sich exakt die Risiken ein, die der Audit hätte sichtbar machen sollen. Wie man dabei zwischen Festpreis, Stundensatz und Aufwand mit Deckel abwägt, hängt weniger am Preis als daran, wer das Risiko des Unbekannten am besten steuert — und bei einer Übernahme ist das Unbekannte der eigentliche Kostentreiber.
Du willst einen bestehenden Shopware-Shop übernehmen?
Lass uns in 30 Minuten durchgehen, was vor der Zusage auf den Prüfstand gehört — Plugin-Inventur, Lizenzlage, versteckte Abo-Kosten und der Zustand des Custom-Codes. Damit aus einem „läuft doch" keine unbezahlte Dauerbaustelle wird. Kein Sales-Call.