Du sitzt im Erstgespräch mit einer neuen Agentur, die deinen Magento-2-Shop übernehmen soll. Oder du hast gerade ein Unternehmen gekauft und mit ihm einen Shop geerbt, den der Gründer jahrelang im Alleingang gepflegt hat. Oder deine bisherige Agentur wechselt gerade den Account Lead, und du willst endlich wissen, womit du es eigentlich zu tun hast. Drei völlig unterschiedliche Ausgangslagen, eine Frage: Was findet ein guter Tech-Partner am ersten Tag, das du schon heute ansprechen solltest?
Die Antwort steckt in den acht Punkten weiter unten. Keiner davon ist ein Notfall, und keiner bedeutet, dass jemand Mist gebaut hat. Es sind die Spuren, die jeder Magento-2-Shop im Lauf der Jahre ansammelt: improvisierte Entscheidungen unter Zeitdruck, Entwickler, die das Team verlassen haben, Launches, die eilig über die Bühne mussten. Eine gute Agentur geht am ersten Tag jeden dieser Punkte durch, sagt dir, was normal ist und was tragende technische Schulden sind, und gibt dir ein Gefühl dafür, was ein Sanierungsplan kosten würde.
Key takeaway: Jeder geerbte Magento-2-Shop trifft auf ein paar dieser Punkte. Das ist kein Versagen, sondern die Realität einer sechs Jahre alten Plattform mit vielen beweglichen Teilen und jahrelangem kommerziellem Druck. Die eigentliche Frage, die eine gute Agentur am ersten Tag beantwortet, lautet nicht "Ist der Code sauber?", sondern "Welche dieser Punkte sind relevant, und was braucht es, um sie zu beheben?"
Wie du diese Liste nutzt
Es gibt zwei Szenarien.
Übernimmst du einen Shop (neue Eigentümerin, neuer Account Lead, Migration aus einem internen Team), gehst du die Liste in der ersten Woche gemeinsam mit deinem neuen Tech-Partner durch. Zu jedem Warnsignal gibt es ein konkretes Artefakt, das man dir zeigen kann: eine Dateianzahl, einen Log-Ausschnitt, eine Kommandozeilen-Ausgabe. Kann dein Gegenüber das Artefakt nicht liefern, ist genau das schon das größte Warnsignal auf der ganzen Liste.
Suchst du gerade eine neue Agentur, frag schon in der Angebotsphase: "Geht ihr am ersten Tag diese acht Punkte mit uns durch und sagt uns, was ihr findet?" Jeder kompetente Magento-2-Spezialist bejaht das ohne zu zögern. Wer ausweicht oder sagt "das heben wir uns für später auf", plant bereits, nicht genau hinzuschauen.
Die 8 Warnsignale
-
Wie viele Custom-Module laufen im Shop, und wer hat sie gebaut?
Magento 2 setzt sich aus Modulen zusammen, also Code-Paketen, die dem Shop neue Funktionen geben. Die reine Anzahl allein ist noch kein Warnsignal. Ein Shop mit Dutzenden Modulen, die eine einzige Agentur über Jahre hinweg strukturiert gebaut hat, kann völlig wartbar sein, das ist einfach ein komplexer Shop, kein kaputter. Das Warnsignal ist eine hohe Zahl aus vielen unterschiedlichen Quellen: Extensions von fünf verschiedenen Agenturen, ein paar aus dem Marketplace, dazu ein paar halbfertige Experimente von Freelancern, die vor drei Jahren abgesprungen sind. Diese Mischung sorgt für Abhängigkeitskonflikte, unklare Zuständigkeiten und Upgrade-Kopfschmerzen. Frag deine Agentur: Wie viele unterschiedliche Anbieter haben Module beigesteuert, welche davon werden aktiv gepflegt, und bei welchen lässt sich noch jemand erreichen, der tatsächlich ans Telefon geht?
-
Landet Debug-Output in den Production-Error-Logs?
Debug-Zeilen wie "hier angekommen" oder "Wert ist X" gehören in die lokale Entwicklung, nicht in Production. Sie bremsen den Shop aus und leaken nicht selten Daten. Bei praktisch jedem langsamen Shop, den wir auditieren, taucht davon etwas auf. Lass dir von deiner Agentur eine Stunde Production-Logs ziehen und markieren, welche Einträge eher nach Debug-Ausgabe als nach echtem Fehler aussehen. Je kürzer diese Liste, desto sauberer die Codebase.
-
Liegen Test- oder Entwickler-Dateien im öffentlichen Webroot?
Beim Debuggen legen Entwickler manchmal eine kleine PHP-Datei direkt im öffentlichen Ordner des Shops ab, um schnell etwas zu testen. Eigentlich soll die Datei danach wieder verschwinden. Oft passiert das nicht. Lass deine Agentur den öffentlichen Webroot durchgehen und jede PHP-Datei auflisten, die nicht zum Standard-Magento gehört. Alles, was nach Test, Backup oder Datenbank-Tool aussieht, fliegt sofort raus.
-
Gibt es eine CI-Pipeline, und gibt es automatisierte Tests?
CI (Continuous Integration) heißt, dass bei jeder Code-Änderung automatisch Prüfungen laufen, bevor irgendetwas live geht. Lass deine neue Agentur nach CI-Konfigurationsdateien im Projekt suchen, etwa einem .github/workflows-Ordner, einer .gitlab-ci.yml oder einer vergleichbaren Bitbucket-Pipeline. Und dann die nächste Frage: 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 zeigen Code-Coverage-Reports und Complexity-Checks, dass sich jemand Gedanken über Qualität über die Zeit gemacht hat, nicht nur darüber, ob die Seite lädt. Eine Codebase ohne Tests ist nicht automatisch schlecht, aber jede Änderung trägt mehr Risiko, und jedes Refactoring bleibt Handarbeit. Eine Codebase mit Tests und CI-Pipeline lässt sich deutlich sicherer übernehmen und weiterentwickeln.
-
Werden eure Plattform-Versionen noch unterstützt?
Magento, PHP und die Suchmaschine (Elasticsearch oder OpenSearch) haben alle ein End-of-Life-Datum. Danach gibt es 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. Die Details zu Magentos Release-Zyklen findest du in Magento 2 Release-Zyklen und End of Life. Für diesen Check willst du als Antwort hören: "Alles, was bei uns läuft, wird aktuell unterstützt, und hier ist der Upgrade-Kalender für die nächsten 18 Monate."
-
Läuft der Cron, und kommt er hinterher?
Magento erledigt fast alles, was ein Kunde nicht direkt anklickt, über einen Hintergrundprozess namens Cron: E-Mails, Preisänderungen, Bestandsabgleich, Recovery für abgebrochene Warenkörbe. Bricht der Cron, sieht und lädt der Shop erstmal völlig normal weiter, aber nach und nach hören Funktionen still auf zu arbeiten. E-Mails gehen nicht raus. Preise aktualisieren sich nicht. Bestände laufen auseinander. Lass dir von deiner Agentur den Cron-Status zeigen und sagen, wann der älteste unverarbeitete Job in die Queue kam. "Alles abgearbeitet, läuft jede Minute" ist die Antwort, die du hören willst.
-
Sind die Indexer gesund?
Magento hält Katalog-, Preis- und Suchdaten über sogenannte Indexer aktuell. Hängt ein Indexer fest, sieht der Kunde veraltete Daten: alte Preise, Produkte, die als lieferbar angezeigt werden obwohl sie es nicht sind, Kategorieseiten, die sich nach einer neuen Produktveröffentlichung nicht aktualisieren. Lass dir einen Screenshot der Indexer-Management-Seite geben. Jeder Indexer sollte "Ready" und "Update on Save" zeigen. Alles, was länger als ein paar Stunden auf "Processing" hängen bleibt, ist ein Problem.
-
Sieht die Codebase danach aus, dass sich noch jemand kümmert?
Das siehst du selbst nicht unbedingt, dein neuer Tech Lead schon. Gibt es eine Versionsverwaltung mit sauberen Commits, oder nur ein gezipptes Backup ohne Historie? Stecken die Klassen voller auskommentierter Blöcke, bei denen niemand mehr weiß, ob man sie löschen darf? Lass deine Entwickler
composer outdated -Dausführen; das listet jede direkte Abhängigkeit auf, die hinter ihrer aktuell veröffentlichten Version zurückliegt. Eine lange Liste ist ein zuverlässiges Zeichen, dass sich lange niemand ernsthaft um das Projekt gekümmert hat. Keiner dieser Punkte ist für sich allein ein Totalausfall. Zusammen zeigen sie, ob die Codebase aktiv gepflegt wurde oder nur passiv überlebt hat. Eine gute Agentur gibt dir nach ein paar Stunden Durchsicht eine ehrliche, unverblümte Einschätzung.
Was die Ergebnisse bedeuten
Ein einzelnes Warnsignal ist Hintergrundrauschen. Zwei oder drei zusammen sind ein Muster.
Ein oder zwei Treffer aus der Liste sind normal. Jeder geerbte Magento-2-Shop, den wir je unter die Lupe genommen haben, hat ein paar davon. Die Fixes laufen im Rahmen der normalen Wartung und passen locker ins erste Quartal mit dem neuen Team.
Vier oder fünf Treffer rechtfertigen eine ordentliche Discovery-Phase, bevor irgendein neues Feature angefasst wird. Die technischen Schulden sind tragend. Wer jetzt einfach neue Features obendrauf baut, ohne die Basis zu sanieren, zahlt für jedes Feature das Zwei- bis Dreifache. Ein ein- bis zweiwöchiger Discovery-Audit mit der neuen Agentur liefert dafür einen priorisierten Plan.
Sechs oder mehr Treffer, vor allem wenn Punkt 2 (Debug-Logs), Punkt 3 (Test-Dateien) und Punkt 5 (EOL-Versionen) alle zutreffen, sind ein Signal, dass sich das vorherige Team nicht mehr gekümmert hat. Das ist keine Anklage. Manchmal sind Teams überlastet, manchmal läuft ein Account einfach aus, manchmal verändert sich das Geschäft und die Technik bleibt auf der Strecke. So oder so wird das erste Quartal der neuen Agentur zum Sanierungsquartal, und das gehört offen ins Budget.
Deine neue Agentur sollte dir diese Einschätzung in klarem Deutsch geben können, ohne Ausflüchte und ohne Weltuntergangsstimmung. Panik bringt dir nichts. So tun, als gäbe es die Probleme nicht, bringt dir auch nichts. Genau dazwischen liegt 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, findest du hier die drei häufigsten echten Ursachen.
- Ist mein Magento-2-Shop wirklich sicher? Ein 10-Minuten-Selbstcheck für Händler. Der sicherheitsfokussierte Begleitartikel zu dieser Liste, teils dieselben Warnsignale, andere Perspektive.
- Magento 2 Release-Zyklen und End of Life. Hintergrund zu Warnsignal 5.
FAQ
Einen Magento-2-Shop geerbt? Lass uns die Liste gemeinsam durchgehen.
Wir bieten Händlern, die einen Magento-2-Shop übernehmen, ein kostenloses 30-minütiges Kennenlerngespräch an. Du bekommst eine ehrliche Einschätzung, wo die technischen Schulden liegen, was ein vollständiger Audit ans Licht bringen würde, und ob die nächsten sechs Monate ein Sanierungsquartal brauchen oder normale Wartung reicht.