Sechs Wochen nach einer Übernahme kam bei einem Händler eine Rechnung an, die niemand zuordnen konnte. Kleine VM bei einem Hoster, den weder er noch wir auf der Liste hatten. Darauf lief ein Skript, das nachts einen Preisexport für einen Marktplatz baute. Niemand hatte es erwähnt, weil niemand mehr wusste, dass es existierte. Der Entwickler, der es gebaut hatte, war zwei Jahre vorher aus der alten Agentur ausgeschieden.
Das ist der typische Fall. Nicht Sabotage, nicht Zurückhalten von Zugängen, sondern Wissen, das sich still verabschiedet hat.
Die alte Agentur ist selten das Problem
Die Sorge, mit der Händler in solche Gespräche kommen, lautet: Die geben nichts raus. In der Praxis erleben wir das kaum. Übergaben laufen meist sachlich, oft sogar erleichtert, weil beide Seiten wissen, dass die Zusammenarbeit nicht mehr passt.
Das eigentliche Risiko ist ein anderes. Eine Agentur, die ein System fünf Jahre betreut hat, hat Dinge im Kopf, die in keinem Dokument stehen. Warum der Cronjob für den Lagerabgleich um 3:15 Uhr läuft und nicht um 3:00. Warum ein bestimmtes Plugin auf Version 2.4.1 festgenagelt ist, obwohl 2.6 verfügbar wäre. Welcher Kunde jedes Jahr im November anruft, weil sein Preisexport anders aussehen muss. Dieses Wissen bekommst du nicht über eine Passwortliste, sondern nur über Gespräche, und die brauchen Termine, bevor das Vertragsende feststeht.
Deshalb: Inventur zuerst, Kündigung später. Wer zuerst kündigt und dann fragt, verhandelt aus einer schlechteren Position, auch wenn niemand böse Absichten hat.
Wer ist eigentlich Vertragspartner
Die Frage klingt banal und ist regelmäßig die teuerste. Bei Übernahmen finden wir immer wieder Konstellationen, in denen die Agentur Vertragspartner des Hosters ist, nicht der Händler. Der Server läuft auf die Agentur, das SEPA-Mandat auch, die Domain steht im Whois auf die Agenturadresse. Solange alle sich vertragen, merkt das keiner.
Geh die Rechnungen der letzten zwölf Monate durch, und zwar die der Agentur genauso wie die eigenen Kreditkartenabrechnungen. Jede wiederkehrende Position ist ein Vertrag, der irgendwo hängt: Hosting, Domains, SSL, Monitoring, Backup-Speicher, Suchdienst, Bilderdienst, Newsletter-Tool, Fehler-Tracking, ein Plugin-Abo. Bei Shopware 6 kommen die Store-Plugins dazu, die an einem Shopware-Account hängen. Ist das der Account der Agentur, bekommst du nach der Trennung keine Updates mehr, und zwar ohne Fehlermeldung. Das fällt erst auf, wenn eine Sicherheitslücke gemeldet wird und der Store-Bereich das Plugin nicht mehr kennt.
Dasselbe Muster bei Plenty mit Plugins aus dem Marketplace, bei JTL mit Servicepacks und bei Shopify mit Apps, die über einen Collaborator-Zugang installiert wurden. Prüfe außerdem, auf welche Mailadresse die Zugänge laufen. Wenn der Passwort-vergessen-Link an eine Adresse bei der alten Agentur geht, gehört sie dir faktisch nicht.
Was in ein Übergabeprotokoll gehört
Wir arbeiten mit einer Liste, die sich über mehrere Übernahmen entwickelt hat. Sie ist nicht elegant, aber sie fängt die Dinge ab, die sonst durchrutschen.
Hosting und Infrastruktur: Zugang zum Kundenkonto des Hosters, nicht nur SSH auf die Maschine. Dazu SSH-Keys, sudo-Rechte, Datenbankzugänge, die Cronjob-Liste des Systemusers und aller anderen User auf der Kiste. Bei Shopware 6 die .env, das Verzeichnis config/jwt/ und die auth.json mit dem Token für packages.shopware.com. Bei JTL die SQL-Server-Instanz mit der Datenbank eazybusiness, die Version des JTL-Connectors im Shop und der Ort, an dem der Worker läuft. Bei Plenty die Backend-Benutzer samt Rechten und die Zuordnung der Plugin-Sets zu den Mandanten. Bei Shopify Staff-Accounts mit Zwei-Faktor-Zuständigkeit und die Custom Apps samt ihrer Access Tokens, weil die an der App hängen und nicht am Benutzer.
Code: Git-Remote, Branch-Struktur, Deploy-Keys, CI-Konfiguration. Und die ehrliche Frage, ob das, was im Repository liegt, dem entspricht, was live läuft. Sie wird überraschend oft verneint, sobald man sie direkt stellt.
Schnittstellen: jede API-Verbindung nach draußen mit Zugangsdaten und Ansprechpartner auf der Gegenseite. Zahlungsdienstleister mit ihren Webhook-URLs, der Versanddienstleister, der Marktplatz, das PIM. Bei EDI die SFTP-Keys der Handelspartner und die AS2-Zertifikate mit ihrem Ablaufdatum.
Betrieb: Wohin gehen Backups, wie lange werden sie gehalten, wann wurde zuletzt ein Restore getestet. Die letzte Antwort ist oft ein Schulterzucken.
Reihenfolge, damit der Shop nicht anhält
Erstens Lesezugriff auf alles, parallel und ohne dass sich technisch etwas ändert. Zweitens die Verträge klären: Was wird umgeschrieben, was neu abgeschlossen, was gekündigt. Drittens den Code holen und auf einem eigenen Staging-System zum Laufen bringen. Das ist der Lackmustest. Was sich dort nicht bauen lässt, ist entweder undokumentiert oder hängt an einer Lizenz, die noch nicht übertragen ist. Viertens Lizenzen und Accounts umschreiben. Fünftens, falls das Hosting wechselt, der eigentliche Umzug. Sechstens Domains und DNS. Siebtens die Zugänge der alten Agentur entziehen, und zwar erst dann.
Domains zuletzt hat einen Grund. Ein Registrar-Wechsel bei einer .de-Domain läuft über den AuthInfo-Code und ist an sich unkritisch, aber er sperrt für die Dauer des Transfers gern Änderungen an den DNS-Einträgen. Wer gleichzeitig den Server wechselt, hat dann keine Handbremse mehr. Wir setzen die TTL der relevanten Records ein bis zwei Tage vor dem Serverwechsel auf 300 Sekunden, machen den Umzug, und ziehen die TTL erst nach ein paar ruhigen Tagen wieder hoch. Danach der Registrar, wenn er überhaupt wechseln muss.
Ein Detail, das zweimal Ärger gemacht hat: Mailversand. Transaktionsmails liefen über einen SMTP-Zugang der Agentur, SPF und DKIM zeigten entsprechend. Nach dem Wechsel gingen Bestellbestätigungen in den Spam, ohne dass im Shop ein Fehler sichtbar war. Prüfe die Mail-Records, bevor du den Zugang abschaltest, nicht danach.
Undokumentierte Eigenentwicklungen findest du nicht durch Fragen
Du findest sie, indem du das System liest. Bei Shopware 6 schauen wir in custom/plugins/ und custom/static-plugins/ und vergleichen mit dem Repository. Alles, was live liegt und nicht im Git ist, ist ein Fund. Danach die Frage, ob jemand in vendor/ gearbeitet hat, was bei Composer-Projekten selten, aber nicht nie vorkommt. Bei JTL sind es eher Workflows in der Wawi, SQL-Skripte auf der Datenbank und Ameise-Vorlagen, die auf einem Arbeitsplatzrechner in der Buchhaltung liegen. Bei Plenty sind es Ereignisaktionen, die vor Jahren jemand angelegt hat und die niemand mehr abschalten möchte, weil unklar ist, was dann passiert.
Die ehrlichste Zahl in so einem Projekt ist die Anzahl der Dinge, die am Ende auf der Liste "unklar, läuft aber" stehen. Wir versuchen, sie klein zu halten, auf null bekommen wir sie nicht. Ein Skript, das seit Jahren stabil eine Datei schreibt, die jemand irgendwo weiterverarbeitet, ist manchmal einfach eine offene Frage, die man mitnimmt und beim nächsten Anlass klärt.
Ein Sonderfall, den wir hier nicht lösen
EDI-Verbindungen zu großen Handelspartnern hängen oft an Zugängen zu Lieferantenportalen, und die sind auf eine Person und eine Mailadresse registriert. Wenn diese Person bei der alten Agentur saß, hilft dir kein Passwort weiter. Da beginnt ein Prozess beim Handelspartner, der Wochen dauern kann und mit Technik wenig zu tun hat. Wer weiß, dass er wechselt und EDI im Spiel ist, sollte damit zuerst anfangen und nicht zuletzt.
Wenn du gerade überlegst, ob ein Wechsel für dich Thema ist: Fang mit den Rechnungen an. Zwölf Monate, jede wiederkehrende Position, daneben die Frage, auf wessen Namen sie läuft. Diese Liste kostet dich einen halben Tag, gehört dir unabhängig davon, ob du am Ende wechselst, und ist meistens der Punkt, an dem das Gespräch konkret wird.
KI-generierter Inhalt.