Wer nach einer Magento Alternative sucht, hat das meistens nicht aus Neugier getan. Der Auslöser ist fast immer konkret: ein Upgrade, das drei Wochen statt drei Tagen gedauert hat. Eine Hosting-Rechnung, die im Verhältnis zum Umsatz nicht mehr aufgeht. Oder die Frage, was aus Magento Open Source eigentlich wird, seit Adobe seine Energie sichtbar in Adobe Commerce steckt.
Die Antworten im Netz sind dann meist Listen: zehn Systeme, je ein Absatz, Vor- und Nachteile in Stichpunkten. Solche Listen sind austauschbar, weil sie alle aus denselben Marketing-Seiten abgeschrieben sind. Sie beantworten die Frage „Was gibt es?” — nicht die Frage, die du tatsächlich hast: „Was davon hält die nächsten fünf Jahre?”
Deshalb haben wir für diesen Artikel zwei Dinge selbst gemessen, statt sie zu zitieren:
- Das Datenmodell. Magentos größter Kostentreiber ist keine Funktion, sondern eine Architekturentscheidung aus 2007. Wir haben sie im Quellcode ausgezählt und den Alternativen gegenübergestellt.
- Die Wartung. Wir haben 7.150 Commits aus sechs Monaten über sieben Projekte gezogen und ausgewertet, wie viele Menschen ein System wirklich am Leben halten. Das Ergebnis widerspricht der Sterne-Zahl auf GitHub deutlich.
Alle Zahlen unten sind mit den angegebenen Befehlen nachprüfbar. Wo wir uns beim Messen selbst korrigieren mussten, steht das dabei — das gehört zur Methode.
Warum überhaupt eine Magento Alternative? Der ehrliche Anlass
Bevor wir Systeme vergleichen, lohnt eine unbequeme Frage: Ist Magento dein Problem — oder ist es dein Shop?
Denn ein Plattformwechsel ist die teuerste aller Antworten. Er kostet je nach Katalog- und Prozesskomplexität einen mittleren fünfstelligen bis sechsstelligen Betrag, bindet dein Team ein halbes bis ganzes Jahr und bringt null neue Funktionen für den Kunden. Wenn dein eigentliches Problem eine langsame Themeschicht, ein aufgeblähter Extension-Stack oder fehlendes Caching ist, wechselst du für viel Geld die Baustelle statt sie zu schließen.
Es gibt aber drei Anlässe, bei denen der Wechsel rational ist:
1. Die Versionslage. Magento Open Source und Adobe Commerce folgen demselben Release-Zyklus, aber nicht demselben Fokus. Die aktuellen Releases im offiziellen Repository (Stand 08.08.2026): 2.4.9 vom 12.05.2026, davor die Patch-Serien 2.4.8-p5, 2.4.7-p10 und 2.4.6-p15 am selben Tag. Wer auf einer älteren Minor-Version sitzt, hat kein Sicherheitsproblem in der Zukunft, sondern einen Migrationszwang in der Gegenwart — nur eben innerhalb von Magento.
2. Die Betriebskosten. Magento ist kein Shop, den man „hostet”. Es ist ein verteiltes System, das mehrere Dienste voraussetzt. Ein Blick in die composer.json des Core zeigt, was mitgeschleppt wird:
curl -s https://raw.githubusercontent.com/magento/magento2/2.4-develop/composer.json | jq -r '.require | keys[]'Darin: elasticsearch/elasticsearch, opensearch-project/opensearch-php, php-amqplib/php-amqplib (RabbitMQ), gleich vier Redis-bezogene Pakete. Insgesamt 80 Runtime-Abhängigkeiten allein im Core, vor der ersten Extension. Das ist kein Fehler — das ist die Bauart eines Systems für große Kataloge. Es ist nur teuer, wenn dein Katalog nicht groß ist.
3. Der Aufwand pro Änderung. Und der hat eine Ursache, über die kaum jemand schreibt, weil sie unsichtbar im Schema liegt.
Der eigentliche Grund: EAV — nachgezählt
Magento speichert Produkte nach dem Entity-Attribute-Value-Muster. Statt einer Tabelle mit einer Spalte pro Eigenschaft gibt es eine schmale Entitätstabelle und daneben Wertetabellen, in denen jede einzelne Eigenschaft als eigene Zeile liegt.
Das klingt abstrakt, bis man es zählt. Wir haben das Schema direkt aus dem Core geholt:
git clone --depth 1 --branch 2.4-develop --filter=blob:none https://github.com/magento/magento2.git
grep -oP '<column xsi:type="[^"]+"[^>]*?name="\K[^"]+' \
magento2/app/code/Magento/Catalog/etc/db_schema.xmlDas Ergebnis ist der Kern dieses ganzen Artikels:
| Tabelle | Spalten | Inhalt |
|---|---|---|
catalog_product_entity | 8 | entity_id, attribute_set_id, type_id, sku, has_options, required_options, created_at, updated_at |
catalog_product_entity_varchar | 5 | Werte-Zeilen (Text) |
catalog_product_entity_int | 5 | Werte-Zeilen (Ganzzahl) |
catalog_product_entity_decimal | 5 | Werte-Zeilen (Dezimal) |
catalog_product_entity_text | 5 | Werte-Zeilen (Langtext) |
catalog_product_entity_datetime | 5 | Werte-Zeilen (Datum) |
app/code/Magento/Catalog/etc/db_schema.xml, Branch 2.4-develop, abgerufen am 08.08.2026. Gezählt wurden ausschließlich <column>-Elemente.
Lies die erste Zeile noch einmal. Die Produkttabelle von Magento enthält keinen Namen, keinen Preis und keine Beschreibung. Sie enthält eine ID, einen SKU und Verwaltungsflags. Alles, was ein Produkt inhaltlich ausmacht, liegt woanders.
Insgesamt gibt es im Core 12 Tabellen, die mit catalog_product_entity beginnen, und 21 Tabellen mit dem Präfix eav_, die das Regelwerk dazu verwalten. Die Standardinstallation legt 43 Produktattribute an (name, sku, description, price, special_price, weight, manufacturer, meta_title …), gezählt in app/code/Magento/Catalog/Setup/CategorySetup.php.
Was das praktisch bedeutet
Ein einziges Produkt mit 43 gefüllten Attributen liegt physisch in bis zu sechs Tabellen verteilt. Ein Produktlisting braucht deshalb entweder viele Joins oder einen vorberechneten Zwischenstand. Genau deshalb existieren Magentos Indexer — und auch die haben wir gezählt:
grep -rhoP '<indexer\s+id="\K[^"]+' magento2/app/code/Magento --include=indexer.xml | sort -u12 Indexer im Core, darunter catalog_product_flat, catalog_product_price, catalog_category_product und catalogsearch_fulltext. Dazu 15 Cache-Typen (--include=cache.xml).
Das ist der ehrliche Kern der Magento-Erfahrung: Der „Flat”-Indexer ist eine Maschine, die das EAV-Modell wieder in genau die flache Tabelle zurückrechnet, die andere Systeme von vornherein haben. Jede Preisänderung, jeder Import, jedes Attribut-Update stößt Neuberechnungen an. Die berüchtigte Frage „Warum sieht man die Änderung im Shop noch nicht?” ist keine Bedienfehler-Frage — sie ist eine direkte Folge dieser Architektur.
Und der Vorteil? EAV ist nicht dumm. Es erlaubt, pro Attribut-Set völlig unterschiedliche Produkttypen zu führen, ohne je eine Migration zu schreiben — ein Möbelhaus mit 400 Attributen für Sofas und 30 für Kerzen bildet das sauber ab. Wenn dein Katalog wirklich so heterogen ist, ist EAV ein Feature. Bei den meisten Shops ist es das nicht.
Die Gegenprobe: Wie machen es die anderen?
Wir haben dieselbe Frage an die Alternativen gestellt — jeweils an der Stelle, an der das Produkt definiert wird.
Shopware 6 definiert Produkte in ProductDefinition.php:
curl -s https://raw.githubusercontent.com/shopware/shopware/trunk/src/Core/Content/Product/ProductDefinition.php \
| grep -cP "new \w+Field\("105 Felder, direkt an der Entität, davon 13 übersetzbare (TranslatedField). Darunter fachlich konkrete Dinge, die bei Magento erst ein Attribut werden müssten: stock, available_stock, restock_time, ean, min_purchase, max_purchase, purchase_steps, shipping_free, mark_as_topseller, rating_average.
Medusa (TypeScript) definiert das Produkt als Modell mit 23 Feldern direkt in packages/modules/product/src/models/product.ts — inklusive status (Draft/Published), handle, weight, hs_code, mid_code, origin_country.
Saleor (Python/Django) hält den Produktkern bewusst schlank: 11 Felder in saleor/product/models.py, alles Variantenspezifische liegt in eigenen Modellen.
| System | Produktfelder direkt an der Entität | Modell |
|---|---|---|
| Magento 2 | 8 (ohne Name, Preis, Beschreibung) | EAV + 12 Indexer |
| Shopware 6 | 105 (13 übersetzbar) | flach + Übersetzungstabellen |
| Medusa | 23 | flach, modular |
| Saleor | 11 (schlanker Kern) | flach + Varianten-Modelle |
db_schema.xml (Magento, 2.4-develop), ProductDefinition.php (Shopware, trunk), product.ts (Medusa, develop), models.py (Saleor, main). Alle abgerufen am 08.08.2026. Die Zahlen sind bewusst nicht direkt vergleichbar im Sinne von „mehr ist besser” — sie zeigen, wo die Information liegt, nicht wie viel es davon gibt.
Warum diese Tabelle mehr sagt als jeder Feature-Vergleich: Sie erklärt, warum eine simple Aufgabe wie „zeig mir alle Produkte unter 20 €, sortiert nach Name” bei Shopware eine gewöhnliche WHERE-Abfrage ist und bei Magento entweder mehrere Joins oder einen aktuellen Index braucht. Der Unterschied im Entwicklungsaufwand summiert sich über Jahre — und er ist der eigentliche Grund, warum Magento-Stunden teurer sind.
Die Kandidaten: Wer kommt ernsthaft in Frage?
Mage-OS — der Weg mit dem kleinsten Bruch
Mage-OS ist ein Community-Fork von Magento Open Source, getragen von einer Non-Profit-Association. Es ist die einzige Option in dieser Liste, bei der deine Extensions, dein Team-Wissen und deine Datenbank weitgehend bleiben, wo sie sind.
Die Release-Lage ist gesund, nicht symbolisch: 3.3.0 am 05.08.2026, 3.2.0 am 14.07.2026, 3.0.0 am 20.05.2026, davor 2.0.0 im Oktober 2025. Ein Fork, der in drei Monaten drei Minor-Releases schafft, ist kein Schaufensterprojekt.
Aber hier wird es interessant, und diese Zahl haben wir nirgends sonst gefunden. Wir haben die Beitragenden beider Projekte über dasselbe Halbjahr verglichen:
Von 72 Personen, die seit dem 08.02.2026 zu Mage-OS beigetragen haben, sind 59 auch im offiziellen magento/magento2-Repository aktiv — das sind 82 %.
Das ist eine zweischneidige Zahl, und beide Schneiden sind wichtig:
- Beruhigend: Mage-OS ist keine Abspaltung verärgerter Außenseiter. Es sind zum größten Teil dieselben Leute, die auch Magento pflegen. Die Kompetenz ist real.
- Ernüchternd: Ein Fork, dessen Beitragende zu 82 % aus dem Upstream stammen, ist noch keine unabhängige Lebensversicherung. Sollte Adobe die Investition in Open Source reduzieren, verschwindet ein Großteil dieser Menschen aus der bezahlten Arbeitszeit — und damit möglicherweise auch aus beiden Repositories.
Wirklich Mage-OS-eigen sind Namen wie DavidLambauer, ProxiBlue, paales, rhoerr oder Bashev — ein erkennbarer, aber kleiner unabhängiger Kern.
Für wen: Läuft dein Shop im Kern gut und stört dich vor allem die Perspektive von Adobe, ist Mage-OS die mit Abstand günstigste Antwort. Du behältst EAV — inklusive aller Kosten, die wir oben gezählt haben. Du kaufst dir Governance, nicht Architektur.
Shopware 6 — die naheliegende Migration im DACH-Raum
Shopware ist im deutschsprachigen Markt die häufigste Zieladresse für Magento-Wechsler, und dafür gibt es handfeste Gründe: MIT-Lizenz, deutscher Hersteller, ausgeprägte Kenntnis lokaler Anforderungen (Rechnungsstellung, Steuerlogik, DSGVO-Praxis), und ein Ökosystem aus Agenturen, das dieselbe Sprache spricht wie deine Buchhaltung.
Technisch ist es ein Symfony-Projekt mit 131 Runtime-Abhängigkeiten und PHP 8.2–8.5. Der Release-Rhythmus ist der engste im ganzen Vergleich: v6.7.13.0 am 05.08.2026, dabei parallel gepflegte 6.6er-Linie (v6.6.10.22 am selben Tag). Zwei aktiv gepflegte Major-Linien sind ein starkes Signal für Migrationsfreundlichkeit — du wirst nicht zum Sprung gezwungen.
Der Preis: Shopware ist ein Produkt eines börsennotierten Unternehmens mit kommerziellen Editionen. Der Core ist MIT-lizenziert, aber die Frage „Welche Funktion ist irgendwann nur noch in einer bezahlten Edition?” stellt sich hier genauso wie bei Adobe — nur mit anderem Absender. Wer wegen Adobes Preispolitik geht, sollte das nicht übersehen. Eine detaillierte Kostenaufstellung haben wir in Was kostet Shopware 6? aufgeschrieben.
Medusa — headless, wenn dein Team TypeScript kann
Medusa ist die populärste Wahl unter den JavaScript-nativen Systemen (35.640 GitHub-Sterne, MIT-Lizenz) und die einzige hier, die aus einer anderen Denkschule kommt: Es ist kein Shop mit einem Frontend, sondern ein modularer Commerce-Backend-Baukasten, zu dem du das Frontend selbst mitbringst.
Das ist eine ehrliche Bedingung, kein Nachteil — aber es ist eine. Wer Magento verlässt, weil das Frontend teuer ist, bekommt bei Medusa ein Frontend, das er komplett selbst verantwortet. Für ein Team mit Next.js-Erfahrung ist das Befreiung. Für ein Team ohne dieses Wissen ist es eine zweite Baustelle neben der Migration.
Release-Lage: v2.18.0 am 23.07.2026, davor v2.17.2 am 01.07.2026 — regelmäßiger, gut getakteter Rhythmus.
Sylius — wenn dein Shop hauptsächlich Sonderfall ist
Sylius ist ein Symfony-basiertes „E-Commerce-Framework” statt einer fertigen Shopsoftware. Wenn deine Geschäftslogik ungewöhnlich ist — B2B-Preisstaffeln, komplexe Freigabeprozesse, Konfiguratoren —, arbeitest du hier nicht gegen das System, sondern mit ihm. MIT-Lizenz, PHP ≥8.2, 125 Abhängigkeiten, Release v2.2.8 am 31.07.2026.
Der Nachteil ist die Kehrseite derselben Medaille: Was bei Shopware im Backend angeklickt wird, wird hier programmiert. Ohne Symfony-Kompetenz im Haus ist Sylius die falsche Wahl.
Saleor — API-first, Python, GraphQL
Saleor (BSD-3, 23.190 Sterne) ist konsequent GraphQL-first und in Python geschrieben. Für Teams mit Python-/Django-Hintergrund oder starkem Datenfokus ist das eine natürliche Heimat. Der Produktkern ist absichtlich schlank (11 Felder) — Erweiterungen laufen über Attribute und eigene Modelle.
Wichtig zur Einordnung: Saleor hatte im gemessenen Halbjahr mit 296 Commits die geringste Aktivität im Feld und mit 17 Beitragenden den kleinsten Kreis. Das ist kein Urteil über Qualität, aber es ist ein Konzentrationsrisiko, das man kennen sollte.
Bagisto und die Shopify-Frage
Bagisto (Laravel, MIT, 27.952 Sterne) ist für Teams mit Laravel-Hintergrund attraktiv — mit einer wichtigen Einschränkung, die wir unten in den Wartungszahlen zeigen.
Und Shopify gehört ehrlicherweise in jede Magento-Alternativen-Liste, auch wenn es hier das einzige geschlossene System ist. Für viele Händler, die Magento wegen Betriebsaufwand verlassen, ist die richtige Antwort nicht „ein anderes selbstgehostetes System”, sondern „gar kein selbstgehostetes System”. Wer damit leben kann, Erweiterungen nur im vorgesehenen Rahmen zu bauen und Transaktionsgebühren zu zahlen, spart den kompletten Betriebsaufwand. Wir haben die Systemlandschaft breiter in Bestes Shopsystem verglichen.
Die Messung, die kein Feature-Vergleich zeigt: Wer pflegt das System wirklich?
GitHub-Sterne messen Popularität, nicht Pflege. Ein Projekt mit 28.000 Sternen kann von einer Person abhängen; ein Projekt mit 3.400 Sternen kann von 150 Menschen getragen werden. Für eine Plattformentscheidung mit fünf Jahren Horizont ist das der wichtigere Wert.
Wir haben deshalb alle Commits der letzten sechs Monate (seit 08.02.2026) aus sieben Repositories geholt — vollständig, nicht als Stichprobe:
# alle Seiten durchlaufen, nicht nur die erste
curl -s -H "Authorization: token $TOKEN" \
"https://api.github.com/repos/$REPO/commits?per_page=100&page=$p&since=2026-02-08T00:00:00Z"Dann haben wir Bot-Konten ([bot], -ci, svc, GitHub Actions) und reine Dokumentations-Commits (docs:) herausgerechnet, um zu messen, wer tatsächlich am Produkt arbeitet.
| Projekt | Commits gesamt | davon Code | Beitragende | Top-1-Anteil | „Bus-Faktor 50” |
|---|---|---|---|---|---|
| shopware/shopware | 1.761 | 1.696 | 146 | 11,6 % | 13 |
| medusajs/medusa | 915 | 566 | 132 | 39,9 % | 2 |
| magento/magento2 | 1.978 | 1.876 | 88 | 7,9 % | 10 |
| mage-os/mageos-magento2 | 851 | 802 | 68 | 7,6 % | 10 |
| Sylius/Sylius | 780 | 777 | 34 | 27,2 % | 2 |
| bagisto/bagisto | 772 | 751 | 29 | 60,7 % | 1 |
| saleor/saleor | 296 | 254 | 17 | 25,6 % | 3 |
docs:-Präfix. „Bus-Faktor 50” = Anzahl Personen, die zusammen mindestens 50 % der Code-Commits stellen. Abgerufen am 08.08.2026.
Was daraus folgt — auch gegen unsere eigene erste Lesart
Drei Befunde, die eine Feature-Tabelle nie zeigt:
1. Shopware ist im Feld am breitesten getragen. 146 Beitragende, kein dominierender Einzelkopf (11,6 %), und 13 Personen braucht es, um die Hälfte der Arbeit zu erklären. Für eine Migrationsentscheidung ist das das stärkste Einzelargument in dieser Tabelle — stärker als jede Funktionsliste.
2. Magento ist nicht tot. Das muss man gegen die Stimmung im Netz deutlich sagen: 1.876 Code-Commits in sechs Monaten, 88 Beitragende, Bus-Faktor 10. Wer aus Angst vor dem Stillstand migriert, migriert aus dem falschen Grund. Der gute Grund heißt Architektur und Betriebskosten, nicht „das Projekt stirbt”.
3. Sterne lügen am zuverlässigsten. Bagisto hat mit 27.952 Sternen deutlich mehr als Shopware (3.400) — und eine einzige Person stellt 60,7 % der Code-Commits. Fällt diese Person aus, fällt das Projekt. Das ist die Sorte Risiko, die man bei einer Fünf-Jahres-Entscheidung kennen muss.
Und eine Korrektur an uns selbst: Unsere erste Auswertung ergab für Medusa einen Bus-Faktor von 1 bei 52,6 % Top-1-Anteil — ein Alarmwert. Bevor wir das schreiben, haben wir die Commit-Titel dieser Person gelesen. Ergebnis: Der Großteil waren docs:-Commits (API-Referenz, Guides, teils automatisiert). Nach Herausrechnen der Doku-Commits sinkt der Anteil auf 39,9 % und der Bus-Faktor steigt auf 2. Immer noch konzentriert, aber eine andere Aussage.
Die Lehre daraus ist allgemeiner als Medusa: Eine Kennzahl, die Dokumentation und Kernentwicklung in denselben Topf wirft, misst Fleiß, nicht Abhängigkeit. Wir hätten mit der ersten Zahl ein Projekt öffentlich als fragiler dargestellt, als es ist — und die Zahl hätte plausibel ausgesehen.
Was eine Migration wirklich kostet
Der teuerste Teil einer Shop-Migration sind nicht Design und Funktionen. Es sind die Daten — und zwar aus einem Grund, der direkt aus der EAV-Tabelle oben folgt.
Du migrierst nicht von einem Schema in ein anderes. Du rekonstruierst zuerst, was dein Schema überhaupt bedeutet. In Magento steht der Produktname nicht im Produkt. Er steht in catalog_product_entity_varchar, in einer Zeile, die über attribute_id auf einen Eintrag in eav_attribute zeigt, und die über store_id pro Store-View unterschiedlich sein kann. Ein Exportskript muss diese Auflösung für jedes Attribut, jeden Store und jedes Produkt korrekt nachbauen.
Realistische Aufwandsblöcke, in der Reihenfolge, in der sie unterschätzt werden:
- Attribut-Mapping — Welches der 43 Standard- plus deiner eigenen Attribute existiert im Ziel? Was wird Feld, was wird Eigenschaft, was wird gestrichen? Das ist Fachentscheidung, nicht Technik, und es ist der Punkt, an dem Projekte stehenbleiben.
- Kundendaten und Passwort-Hashes — Passwörter lassen sich nicht umschlüsseln. Entweder das Zielsystem unterstützt den alten Hash-Algorithmus als Übergang, oder alle Kunden müssen ihr Passwort neu setzen. Das ist eine Marketing- und Support-Entscheidung, kein Migrationsdetail.
- Bestellhistorie — Alte Bestellungen sind steuerlich aufbewahrungspflichtig und referenzieren Produktzustände, die es so nicht mehr gibt. Häufig die pragmatischste Lösung: Historie schreibgeschützt archivieren statt vollständig übernehmen.
- URLs und SEO — Jede indexierte Produkt- und Kategorie-URL braucht eine 301-Weiterleitung. Fehlt sie, verlierst du Rankings, die du dir jahrelang erarbeitet hast. Das ist der Punkt, an dem technisch saubere Migrationen wirtschaftlich scheitern.
- Extension-Logik — Jede Erweiterung, die Geschäftslogik trägt, muss ersetzt oder neu gebaut werden. Hier entstehen die Überraschungen, weil niemand mehr weiß, warum ein Modul 2019 eingebaut wurde.
Der praktische Rat: Miss vor der Migration, wie schnell dein aktueller Shop tatsächlich ist, und danach noch einmal — mit denselben Seiten und derselben Methode. Ohne Vorher-Wert ist jede Aussage über den Erfolg Meinung. Unser Core Web Vitals Test liefert dafür einen reproduzierbaren Ausgangswert.
Die Entscheidung: Welche Magento Alternative passt zu dir?
Statt einer Empfehlung, die für alle gilt (die es nicht gibt), fünf Fragen mit klarer Konsequenz:
„Läuft mein Shop technisch eigentlich gut, ich traue nur Adobe nicht mehr?” → Mage-OS. Kleinster Bruch, geringste Kosten, gleiche Extensions. Du löst ein Governance-Problem, kein Technikproblem — und behältst EAV samt Betriebsaufwand.
„Ich bin im DACH-Raum, brauche ein gepflegtes Ökosystem und will raus aus EAV.” → Shopware 6. Die breiteste Beitragendenbasis im Test (146), flaches Datenmodell mit 105 Produktfeldern, zwei parallel gepflegte Release-Linien, lokale Agenturdichte.
„Mein Team ist stark in TypeScript, das Frontend soll uns gehören.” → Medusa. Modular, API-first, aktiv. Bedingung: Ihr baut und verantwortet das Storefront selbst.
„Meine Geschäftslogik ist der eigentliche Sonderfall.” → Sylius (mit Symfony-Kompetenz) oder Saleor (mit Python/GraphQL-Kompetenz). Beide sind Frameworks, keine fertigen Shops — der Aufwand liegt vorne, die Freiheit hinten.
„Ich will vor allem den Betriebsaufwand loswerden.” → Shopify oder ein gemanagtes Hosting. Die ehrlichste Antwort für viele Händler, die aus Erschöpfung migrieren und sonst dasselbe Problem in neuer Syntax bekommen.
Drei Dinge, die du vor der Entscheidung messen solltest
- Zähl deine tatsächlich genutzten Attribute. Nicht die angelegten — die genutzten. Sind es unter 30 und über alle Produkte ähnlich, ist EAV für dich reiner Aufwand ohne Gegenwert. Sind es 300 in völlig unterschiedlichen Produktgruppen, ist Magento/Mage-OS architektonisch näher an deinem Problem als jede flache Alternative.
- Zähl deine Extensions mit echter Geschäftslogik. Reine Design-Erweiterungen sind billig zu ersetzen. Jede Erweiterung, die Preise, Verfügbarkeiten oder Prozesse berechnet, ist ein eigenes kleines Migrationsprojekt.
- Prüf die Wartungslage selbst, kurz vor der Entscheidung. Unsere Zahlen sind vom 08.08.2026. Die Befehle oben liefern dir in zehn Minuten deinen eigenen aktuellen Stand — und du solltest keinem Vergleichsartikel glauben, der dir nicht sagt, wie er gemessen hat. Auch diesem nicht.
Häufige Fragen
Ist Magento Open Source tot? Nein — das sagen die Zahlen deutlich. 1.876 Code-Commits von 88 Beitragenden in sechs Monaten und Release 2.4.9 vom 12.05.2026 sind kein Stillstand. Die berechtigte Sorge betrifft nicht das Sterben, sondern die Priorität: Adobes Entwicklungsfokus liegt sichtbar auf Adobe Commerce. Wer migriert, sollte das wegen Architektur und Betriebskosten tun, nicht wegen einer Untergangsprognose.
Was ist der Unterschied zwischen Magento Open Source, Adobe Commerce und Mage-OS? Magento Open Source ist die kostenlose, selbst gehostete Version. Adobe Commerce ist die kommerzielle Edition mit zusätzlichen Funktionen und Support. Mage-OS ist ein Community-Fork von Magento Open Source unter dem Dach einer Non-Profit-Association — technisch weitgehend kompatibel, mit eigener Release-Kadenz (3.3.0 am 05.08.2026). Wir haben die inhaltliche Seite von Magento in Magento CMS genauer untersucht.
Ist Mage-OS wirklich unabhängig von Adobe? Organisatorisch ja, personell nur teilweise. Unsere Messung: 82 % der Mage-OS-Beitragenden der letzten sechs Monate sind auch im offiziellen Magento-Repository aktiv. Das spricht für Kompetenz und Kompatibilität, aber es heißt auch, dass ein Rückzug von Adobe-finanzierter Entwicklungszeit beide Projekte gleichzeitig treffen würde.
Welche Magento Alternative ist die beste für kleine Shops? Bei kleinen Katalogen ist Magento fast immer überdimensioniert — allein die 80 Core-Abhängigkeiten mit Elasticsearch/OpenSearch, RabbitMQ und Redis sind Betriebsaufwand, den kleine Shops selten rechtfertigen können. Sinnvoll sind Shopware 6, ein gehostetes System wie Shopify oder, bei WordPress-Nähe, WooCommerce.
Kann ich meine Magento-Extensions mitnehmen? Nur zu Mage-OS. Jeder andere Wechsel bedeutet Ersatz oder Neuentwicklung. Das ist meist der größte einzelne Kostenblock einer Migration — und der Grund, vor der Entscheidung zu inventarisieren, welche Extension wirklich Geschäftslogik trägt und welche nur Optik ist.
Wie lange dauert eine Migration von Magento zu Shopware? Das hängt fast vollständig an Katalogkomplexität und Extension-Landschaft, nicht am Design. Der bestimmende Faktor ist das Attribut-Mapping: Bei einem homogenen Katalog mit wenigen Attributen ist es überschaubar, bei einem gewachsenen Katalog mit hunderten Attributen über mehrere Store-Views ist es der Hauptteil des Projekts. Plane die Datenmigration zuerst und das Design zuletzt — die umgekehrte Reihenfolge ist der häufigste Projektfehler.
Ist headless (Medusa, Saleor) automatisch besser? Nein. Headless verschiebt Verantwortung, es entfernt sie nicht. Du gewinnst Freiheit im Frontend und verlierst alles, was ein integriertes System mitliefert — Templates, Backend-Vorschau, fertige Checkout-Oberflächen. Für Teams mit starker Frontend-Kompetenz ist das ein Gewinn, für alle anderen eine zusätzliche Baustelle.
Fazit
Die ehrlichste Antwort auf „Was ist die beste Magento Alternative?” lautet: Es kommt darauf an, warum du fragst — und die meisten Vergleichslisten beantworten diese Frage nie, weil sie Features zählen statt Ursachen.
Die zwei Dinge, die wir gemessen haben, sagen mehr als jede Funktionstabelle:
Zum Datenmodell: Magentos Produkttabelle hat 8 Spalten und enthält weder Namen noch Preis noch Beschreibung. Alles Inhaltliche liegt in fünf Wertetabellen daneben, zusammengehalten von 12 Indexern. Shopware legt dieselbe Information in 105 Feldern direkt an der Entität ab. Das ist der wahre Grund für den Unterschied im Entwicklungsaufwand — und er verschwindet nicht durch besseres Hosting.
Zur Wartung: Shopware wird von 146 Menschen getragen und braucht 13 davon für die Hälfte der Arbeit. Bagisto hat achtmal so viele GitHub-Sterne wie Shopware und eine einzige Person hinter 60,7 % der Code-Commits. Sterne messen Aufmerksamkeit, nicht Zukunft.
Und der Befund, der der Erwartung am deutlichsten widerspricht: Magento ist nicht tot. 88 aktive Beitragende, 1.876 Code-Commits in sechs Monaten. Wenn du migrierst, dann wegen EAV, wegen der 80 Core-Abhängigkeiten und wegen der Betriebskosten — das sind gute, messbare Gründe. Wegen eines vermuteten Sterbedatums zu migrieren, ist der teuerste Grund von allen.
Wer den Vergleich breiter ziehen will, findet in Bestes Shopsystem die Systemlandschaft insgesamt und in Was kostet Shopware 6? die Kostenseite des häufigsten Migrationsziels. Wie sich derselbe Blick auf Content-Systeme anwenden lässt, steht in Moderne WordPress-Alternative.