---
title: "Magento 2 / Mage-OS / Adobe Commerce"
description: "Enterprise-Commerce für komplexe Kataloge, B2B und Multi-Store, auf Mage-OS und Adobe Commerce."
language: "de"
canonical: "https://zapolu.com/de/services/magento/"
---

# 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](https://mage-os.org):** 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](https://business.adobe.com/products/magento/magento-commerce.html):**
  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](https://www.linkedin.com/in/lubos-zapotocny-48bba0124/)
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](/de/services/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ä](https://hyva.io): 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](/de/services/integrations/)**
  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](/de/services/devops/)
  darunter.

## Wie ein Projekt üblicherweise beginnt

Für einen laufenden Shop ist das
[Performance-Audit](/de/services/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.