Wofür wir Magento einsetzen
Magento kommt bei uns nicht aus dem Angebot, sondern aus der Vergangenheit unserer Kunden. Es sind Shops, die vor Jahren auf Magento 1 oder Magento 2 gebaut wurden, die im Tagesgeschäft laufen und an denen Umsatz, Prozesse und Schnittstellen hängen. Magento-1-Installationen bekommen seit Juni 2020 keine Sicherheitsupdates mehr; dort ist die Frage nicht ob, sondern wann abgelöst wird. Unsere Aufgabe ist es, diese Systeme lauffähig, sicher und weiterentwickelbar zu halten — unabhängig davon, wer sie ursprünglich gebaut hat.
Typisch sind B2B-Kataloge mit vielen Varianten, Kundenpreisen und Anbindungen an ERP oder PIM. Genau diese Anbindungen sind der Grund, warum ein Shopwechsel selten am Frontend scheitert und fast immer an den Datenstrecken dahinter. Wir übernehmen Wartung, Sicherheitspatches und fachliche Erweiterungen, betreiben den Shop auf unseren Servern in Deutschland und halten die Schnittstellen zur Warenwirtschaft am Laufen.
Wie wir mit Magento arbeiten
Erweiterungen entstehen als eigene Module in app/code, nicht als Eingriff in den Core. Layout und Templates werden über ein eigenes Theme überschrieben, Geschäftslogik über Plugins und Observer erweitert. Deployment läuft über Composer, Konfiguration wird versioniert statt im Backend geklickt. Wer den Core anfasst, kauft sich die nächste Update-Runde als Projekt ein — dieser Fehler kostet später mehr als die Ersparnis am Anfang.
Im Betrieb hängt bei Magento vieles am Umfeld: MariaDB oder MySQL, ein Key-Value-Speicher für Cache und Sessions, eine eigene Suchmaschine, Varnish davor, Cronjobs für Indexer und Warteschlangen. Dieses Umfeld hat sich zuletzt verschoben — Adobe setzt ab Version 2.4.8 auf OpenSearch statt Elasticsearch und ab 2.4.9 auf Valkey statt Redis. Fällt einer dieser Dienste aus, merkt das der Shop sofort. Wir richten die Umgebung deshalb reproduzierbar mit Docker ein, überwachen Indexer und Message Queues und testen Updates in einer Staging-Umgebung, bevor sie produktiv gehen.
Grenzen — und wann wir zu Shopware 6 raten
Magento ist mächtig, und das hat einen Preis. Die Hosting-Anforderungen sind hoch, die Update-Zyklen eng, und Entwicklerstunden sind teurer als in anderen Systemen. Für einen mittelständischen Shop mit überschaubarem Sortiment steht dieser Aufwand oft in keinem Verhältnis zum Nutzen. Wir sagen das auch dann, wenn ein Magento-Projekt für uns mehr Stunden bedeuten würde als eine Migration.
Für die meisten Projekte im Mittelstand ist Shopware 6 die wirtschaftlichere Wahl — günstiger im Betrieb, näher am deutschen Markt, mit einem größeren Angebot an Entwicklern. Gegen eine Migration spricht dagegen ein Magento-Shop, der stabil läuft, gepflegt ist und dessen Sonderlogik teuer nachzubauen wäre. Ein funktionierendes System ist kein Grund für ein Neubauprojekt. Diese Rechnung machen wir vorher auf, nicht mittendrin.