Magento 2 / Mage-OS / Adobe Commerce

Magento betreibt einige der größten E-Commerce-Operationen im Web und hat sich seinen Ruf als Schwergewicht redlich verdient. Gut betrieben ist es nach wie vor die leistungsfähigste offene Plattform für komplexe Kataloge und B2B. Schlecht betrieben ist es eine Produktseite mit zwölf Sekunden Ladezeit und eine Hosting-Rechnung, die niemand erklären kann. Die meisten unserer Magento-Projekte beginnen mit einem Shop im zweiten Zustand.

Wir arbeiten mit beiden aktiven Branches der Plattform:

• Mage-OS: der community-geführte Fork, der die Zukunft der Plattform von Adobes Roadmap entkoppelt und schneller Releases liefert. Neue Open-Source-Builds landen hier statt im klassischen Magento Open Source; die Release-Aktivität der Community ist in den Fork gewandert.
• Adobe Commerce: die lizenzierte Cloud-Edition mit B2B-Suite, Page Builder und Enterprise-SLAs.

Die Arbeit leitet ein Architekt mit der Zertifizierung Adobe Certified Master – Adobe Commerce Architect, der höchsten, die Adobe für Commerce vergibt, dazu eine Hyvä-Zertifizierung für das Frontend. Beides ist auf LinkedIn nachprüfbar.

Wann Magento die richtige Wahl ist

• Komplexe Kataloge mit vielen Produkttypen, konfigurierbaren Optionen und Preisregeln
• B2B-Anforderungen: Firmenkonten, Quote-Workflows, gestaffelte Preise, Bestellfreigaben
• Multi-Store- und Multi-Brand-Setups unter einer Administration
• Bestehende Investitionen in Adobe-Commerce-Erweiterungen und -Integrationen

Trifft nichts davon zu, sind Sie mit Shopify meist besser bedient, und darauf weisen wir bereits im ersten Gespräch hin.

Typische Ausgangslagen

• Produktseiten, die drei Sekunden brauchen, obwohl Varnish und Redis „längst konfiguriert“ sind
• Ein Checkout, der während einer Kampagne ausfällt, während die Server bei 10 % Auslastung stehen; der Engpass liegt fast immer im Code oder in der Cache-Konfiguration, nicht in der Hardware
• Vierzig installierte Extensions, die Hälfte davon von ihren Herstellern aufgegeben, zwei im Streit um denselben Observer
• Indexer und Crons in einem Zustand, in dem die Storefront Bestände anzeigt, die das Lager nicht hat
• Ein Upgrade, das so lange aufgeschoben wurde, dass jeder Sicherheitspatch zum eigenen Projekt geworden ist

Behobene Fälle aus der Praxis

Aus Shops, an denen wir über die Jahre gearbeitet haben, anonymisiert:

• Kundenregistrierungen schlugen an einem Wochenende fehl, weil die Tabelle einer Extension alle 4,29 Milliarden Auto-Increment-IDs verbraucht hatte, bei gerade einmal einer halben Million Zeilen. Ein BIGINT-Hotfix brachte die Registrierung innerhalb einer Stunde zurück; ein Schema-Override sorgte dafür, dass der Fix auch Upgrades übersteht.
• Nachnahme-Bestellungen verlangten nach einem Upgrade plötzlich Kartenzahlung: Die Schema-Migration hatte eine Tabelle neu aufgebaut und dabei die Zeilen-IDs verschoben, die ein Legacy-Modul als hartkodierte Konstanten benutzte. Gefunden durch den Vergleich der rohen Tabellen zwischen den Umgebungen.
• Der verkaufbare Bestand lag monatelang unter der Realität. Ein Marktplatz-Connector benannte Order-Increments um, nachdem die Bestandsreservierungen bereits angelegt waren, sodass MSI sie nie wieder freigeben konnte. Nachgewiesen mit Anti-Joins auf den Reservierungs-Metadaten, behoben mit einem Vendor-Patch und einem Aufräum-Cron.
• Adressen fanden im ERP keinen Treffer mehr, weil Magentos Schutz gegen CSV-Injection jedem Wert, der mit „+“ beginnt, still ein Leerzeichen voranstellt. Telefonnummern zum Beispiel. Bis in die Framework-Interna verfolgt, behoben mit einem Composer-Patch.
• Medien-Uploads funktionierten auf Staging und scheiterten in der Produktion. Systematisches Ausschließen von Hypothesen führte zu einer einzigen veralteten Konfigurationszeile; ein selbstheilender Data-Patch stellt sicher, dass sie nicht wiederkommt.

Was wir tun

• Performance-Audits und Storefront-Umbauten. Unsere Standardempfehlung ist Hyvä: Es ersetzt den Legacy-Frontend-Stack vollständig und bringt Lighthouse-Scores typischerweise in die 90er. PWA Studio oder vollständig headless, wo der Fall es wirklich verlangt.
• Eigene Module und Integrationen für ERP, PIM, Fulfillment, Payments und Marktplätze, idempotent und beobachtbar gebaut, denn an diesen Schnittstellen treten in der Praxis die meisten Fehler auf.
• Versions-Upgrades, inklusive Magento-1-zu-2-Rettungen, Mage-OS-Migrationen und einem vollständigen Extension-Audit vor dem ersten Handgriff, damit der Sprung zwischen Hauptversionen kalkulierbar wird.
• Langfristiger operativer Support: Sicherheitspatches, Monitoring, Cache-Tuning und der On-Call-Engineer für den Tag, an dem die Datenbank-Sperrtabelle volläuft. Das Ganze als monatlicher Retainer, mit DevOps & Infrastruktur darunter.

Wie ein Projekt üblicherweise beginnt

Für einen laufenden Shop ist das Performance-Audit der natürliche Einstieg: kleiner Festpreis, echte Messungen und eine priorisierte Maßnahmenliste, die jedes Team umsetzen kann. Für einen Shop, der noch auf Magento 1 läuft oder mehrere Hauptversionen zurückliegt, beginnen wir stattdessen mit einer Migrationsanalyse: was übernommen wird, was neu geschrieben wird und wie der Umstiegsplan aussieht. In beiden Fällen kennen Sie Umfang und Preis schriftlich, bevor etwas abgerechnet wird.