Du interviewst eine neue Agentur, die deinen Magento-2-Shop übernehmen soll. Oder du hast das Geschäft gekauft und den Shop von einem Gründer geerbt, der alles selbst gemacht hat. Oder deine aktuelle Agentur übergibt dich gerade an eine neue Ansprechpartnerin, und du willst wissen, womit du es tatsächlich zu tun hast. Drei verschiedene Ausgangslagen, dieselbe Frage: Was findet ein guter Tech-Partner am ersten Tag, das ich heute ansprechen sollte?
Die Antwort ist die Acht-Punkte-Liste unten. Keiner dieser Punkte ist ein Notfall, keiner heißt, dass irgendjemand etwas falsch gemacht hat; es ist der Fingerabdruck, den jeder Magento-2-Shop sich über Jahre geflickter Entscheidungen, abwandernder Entwickler und Not-Launches einfängt. Eine gute Agentur schaut sich am ersten Tag jeden Punkt an, sagt dir, welche normal sind und welche tragende technische Schulden, und gibt dir ein Gefühl dafür, was ein Remediation-Fahrplan kosten würde.
Jeder geerbte Magento-2-Shop hat einige davon. Das ist kein Versagen; das ist die Natur einer sechsjährigen Plattform mit vielen beweglichen Teilen und Jahren kommerziellem Druck. Die Frage, die eine gute Agentur am ersten Tag beantwortet, ist nicht „ist er sauber?" Sie ist: „welche davon zählen, und was wäre nötig, um sie zu fixen?"
So nutzt du diese Liste
Zwei Modi.
Wenn du einen Shop erbst (neue Eigentümerin, neue Ansprechpartnerin, Migration aus einem internen Team), arbeitest du die Liste in der ersten Woche mit deinem neuen Tech-Partner gemeinsam durch. Jedes Warnsignal hat ein konkretes Artefakt, das er oder sie dir zeigen kann: eine Datei-Anzahl, ein Log-Ausschnitt, ein Kommando-Output. Wenn sie das Artefakt nicht liefern können, ist das das oberste Warnsignal über allem anderen auf der Liste.
Wenn du eine neue Agentur aussuchst, frag in der Angebots-Phase: „Laufen Sie diese acht Dinge am ersten Tag mit uns durch und sagen uns, was Sie finden?" Jeder kompetente Magento-2-Spezialist wird ohne Zögern Ja sagen. Die, die ausweichen oder sagen „klingt nach etwas für später", sind die, die planen, nicht hinzusehen.
Die 8 Warnsignale
-
01
Wie viele Custom-Module sind installiert, und wer hat sie gebaut?
Magento 2 wird aus Modulen zusammengesetzt: Paketen aus Code, die Features zum Shop hinzufügen. Die Zahl allein ist nicht das Warnsignal. Ein Shop mit Dutzenden Modulen, die dieselbe Agentur über Jahre strukturierter Arbeit gebaut hat, kann vollkommen wartbar sein — das ist einfach ein komplexer Shop, kein kaputter. Das Warnsignal ist eine hohe Anzahl aus vielen verschiedenen Quellen: Extensions von fünf verschiedenen Agenturen, ein paar aus dem Marketplace, ein paar halbfertige Experimente von Freelancern, die vor drei Jahren gegangen sind. Diese Kombination schafft Abhängigkeitskonflikte, unklare Verantwortung und Upgrade-Kopfschmerzen. Frag deine Agentur: wie viele unterschiedliche Anbieter haben Module beigesteuert, welche werden aktiv gepflegt, und welche lassen sich auf jemanden zurückführen, der heute noch erreichbar ist?
-
02
Schreibt irgendetwas Debug-Output in die Production-Error-Logs?
Debug-Log-Zeilen („hier ist er angekommen", „der Wert ist X") gehören in die Entwicklung, nicht in Production. Sie bremsen die Seite und leaken oft Daten. Jeder Request auf einen langsamen Shop, den wir auditieren, zeigt etwas davon. Bitte deine Agentur, eine Stunde Production-Error-Logs zu ziehen und jeden Eintrag einzukreisen, der eher nach Debug-Output aussieht als nach einem echten Fehler. Je kürzer diese Liste, desto sauberer die Codebase.
-
03
Liegen Test- oder Entwickler-Dateien in deinem öffentlichen Webroot?
Wenn Entwickler ein Problem debuggen, legen sie manchmal eine kleine PHP-Datei im öffentlichen Ordner des Shops ab, um etwas zu testen. Die Datei soll nach der Debug-Session wieder verschwinden. Sie tut es oft nicht. Bitte deine Agentur, den öffentlichen Webroot durchzugehen und jede PHP-Datei zu listen, die nicht zu Standard-Magento gehört. Alles, was nach Test, Backup oder Datenbank-Tool aussieht, wird sofort entfernt.
-
04
Gibt es eine CI-Pipeline, und gibt es automatisierte Tests?
CI (Continuous Integration) bedeutet, dass bei jeder Code-Änderung automatisch Prüfungen laufen, bevor etwas live geht. Bitte deine neue Agentur, nach CI-Konfigurationsdateien im Projekt zu suchen (z. B. ein .github/workflows-Ordner, eine .gitlab-ci.yml-Datei oder eine ähnliche Pipeline-Konfiguration). Und dann: gibt es automatisierte Tests? Unit-Tests prüfen einzelne Funktionen isoliert. Integrationstests prüfen, ob die Komponenten des Shops korrekt zusammenspielen. End-to-End-Tests simulieren echtes Kundenverhalten im Browser. Als Bonus bedeuten Code-Coverage-Berichte und Komplexitäts-Checks, dass jemand Werkzeuge aufgesetzt hat, um die Qualität über Zeit zu verstehen. Eine Codebase ohne Tests ist nicht automatisch schlecht, aber jede Änderung trägt mehr Risiko, und jedes Refactoring ist Handarbeit. Eine Codebase mit Tests und CI-Pipeline ist bedeutend sicherer zu übernehmen und weiterzuentwickeln.
-
05
Werden deine Plattform-Versionen noch unterstützt?
Magento, PHP und die Suchmaschine (Elasticsearch oder OpenSearch) haben alle End-of-Life-Daten. Nach diesen Daten bekommst du keine Security-Patches mehr. Eine gute Agentur nennt dir die aktuellen Versionen deines Shops, wann jede davon EoL erreicht und wie der Upgrade-Pfad aussieht. Wir haben Magentos Release-Zyklen unter /magento-kb/general/magento2-release-cycles-and-eol ausführlicher behandelt, falls du den Hintergrund willst. Für diese Prüfung ist die Antwort, die du willst: „Alles, was wir fahren, wird aktuell unterstützt, und dies ist der Upgrade-Kalender für die nächsten 18 Monate."
-
06
Läuft Cron und kommt es hinterher?
Magento nutzt einen Hintergrundprozess namens „Cron" für das meiste, was kein Kunde direkt anklickt: E-Mails, Preisaktualisierungen, Bestandssynchronisation, Warenkorbabbruch-Recovery. Wenn Cron kaputt ist, lädt und wirkt der Shop eine Weile normal, und dann hören Features still auf zu funktionieren. E-Mails gehen nicht raus. Preise aktualisieren nicht. Bestand synchronisiert nicht. Bitte deine Agentur, dir den Cron-Status zu zeigen und wann der älteste unverarbeitete Job in die Queue gestellt wurde. „Alles aufgearbeitet, läuft jede Minute" ist die Antwort, die du willst.
-
07
Sind die Indexer gesund?
Magento nutzt „Indexer", um Katalog-, Preis- und Suchdaten aktuell zu halten. Wenn ein Indexer feststeckt, sieht der Kunde veraltete Daten: alte Preise, Produkte, die als verfügbar angezeigt werden, obwohl sie es nicht sind, Kategorie-Seiten, die sich nicht aktualisieren, wenn du ein neues Produkt veröffentlichst. Bitte deine Agentur um einen Screenshot der Indexer-Management-Seite. Jeder Indexer sollte „Ready" und „Update on save" sagen. Alles, was länger als ein paar Stunden in „Processing" hängt, ist ein Problem.
-
08
Sieht die Codebase aus, als kümmere sich noch jemand darum?
Das siehst du selbst nicht, aber deine neue Tech-Lead-Person schon. Gibt es Versionskontrolle mit sauberen Commits oder ein gezipptes Backup ohne Historie? Sind Klassen voll von auskommentierten Blöcken, bei denen niemand weiß, ob sie weg dürfen? Bitte deine Entwickler,
composer outdated -Dauszuführen — das listet alle direkten Abhängigkeiten, die hinter ihrer aktuellen Version liegen. Eine lange Liste ist ein verlässliches Signal, dass das Projekt seit Längerem nicht mehr aktiv angefasst wurde. Keiner dieser Punkte ist ein Einzelversagen. Zusammen sagen sie dir, ob die Codebase aktiv gepflegt wurde oder passiv überlebt hat. Eine gute Agentur gibt dir nach ein paar Stunden Einsicht eine ehrliche Einschätzung.
Was die Antworten dir sagen
Einzelne Warnsignale sind Rauschen. Zwei oder drei zusammen sind ein Muster.
Ein oder zwei Funde aus dieser Liste sind normal. Jeder geerbte Magento-2-Shop, den wir je angeschaut haben, hat ein paar davon. Die Fixes laufen im Rahmen normaler Wartung und passen ins erste Quartal mit dem neuen Team.
Vier oder fünf Funde bringen dich in ein Terrain, das eine ordentliche Discovery-Phase vor jeder neuen Feature-Arbeit rechtfertigt. Die technischen Schulden sind tragend. Neue Features oben draufzulegen, ohne die Basis anzugehen, heißt, dass jedes neue Feature zwei- bis dreimal das kostet, was es sollte. Ein ein- bis zweiwöchiger Discovery-Audit mit der neuen Agentur liefert einen priorisierten Plan.
Sechs oder mehr Funde, besonders wenn Punkt #2 (Debug-Logs), #3 (Test-Dateien) und #5 (EoL-Versionen) alle zutreffen, sind ein Signal, dass sich das vorige Team nicht mehr gekümmert hat. Keine Anklage. Manchmal werden Teams überlastet, manchmal läuft der Account aus, manchmal ändert sich das Geschäft, und die Technik bekommt nicht die nötige Aufmerksamkeit. Wie auch immer, das erste Quartal der neuen Agentur wird ein Remediation-Quartal, und das muss offen budgetiert werden.
Deine neue Agentur sollte dir diese Einschätzung in verständlichem Deutsch geben können, ohne Hedging und ohne Weltuntergangsstimmung. Panik hilft dir nicht. So tun, als gäbe es die Probleme nicht, hilft dir auch nicht. Dazwischen ist das, was ein guter Partner liefert.
Weiterführende Artikel
- Warum dein Magento-2-Shop trotz Varnish und Redis langsam wirkt. Wenn sich dein geerbter Shop langsam anfühlt, behandelt das die drei häufigsten echten Ursachen.
- Ist mein Magento-2-Shop wirklich sicher? Ein 10-Minuten-Selbstcheck für Händler. Der sicherheitsorientierte Begleitartikel zu dieser Liste. Teils dieselben Warnsignale, aus anderer Perspektive.
- Magento 2 Release-Zyklen und End of Life. Hintergrund zu Warnsignal #5.
FAQ
Einen Magento-2-Shop erben? Lass uns die Liste gemeinsam durchgehen.
Wir bieten ein kostenloses 30-minütiges Kennenlerngespräch für Händler, die einen Magento-2-Shop übernehmen. Du bekommst eine ehrliche Einschätzung, wo die technischen Schulden sitzen, was ein voller Audit aufdecken würde, und ob die nächsten sechs Monate ein Remediation-Quartal brauchen oder einfach normale Wartung.