ECommerce-Software Ranking 2026: Methodik und Definitionen

Für das Ranking wurden deshalb genaue Definitionen und Abgrenzungen festgelegt, nach denen die Angaben zu den untersuchten Systemen erhoben und eingeordnet wurden. Die folgenden Ausfüllhinweise dokumentieren diese Methodik. Sie waren Bestandteil des Fragebogens, der an die Hersteller verschickt wurde.

Stand der Definitionen: 28. Mai 2026

Grundprinzip der Bewertung

Bewertet wird nicht, was mit einem Shopsystem theoretisch irgendwie umsetzbar ist, sondern was der Hersteller offiziell, produktiv, nachvollziehbar und für typische Kunden reproduzierbar bereitstellt.

Funktionen, die ausschließlich über projektspezifische Individualentwicklung, freie Drittanbieterintegration, kundenspezifische Sonderlösungen oder angekündigte Roadmap-Themen realisierbar sind, werden deshalb nicht als voll verfügbare Standardfunktion gewertet.

3-stufiges Prüfverfahren

Den Herstellern wurde ein von der Redaktion vorausgefüllter Fragebogen zur Prüfung zugeschickt ("Korrekturabzug"). Diesen konnten sie im Rahmen der Datenprüfung korrigieren und mit Belegen ergänzen. Als Nachweise wurden beispielsweise Produktseiten, technische Dokumentationen, API-Dokumentationen, Marketplace-Einträge, Help-Center-Dokumente oder Whitepaper akzeptiert. Entscheidend war dabei insbesondere, ob nachvollziehbar war, in welcher Edition, über welches Modul, welchen Connector oder welche offiziell vorgesehene Erweiterung eine Funktion verfügbar ist. Unstimmigkeiten oder Unplausibilitäten wurden redaktionell beseitigt.

Blieben die Hersteller eine Antwort schuldig, wurde die redaktionelle Ersteinschätzung von einem zweiten Redakteur überprüft ("Vier-Augen-Prinzip") und gegebenenfalls korrigiert.

Zuletzt wurden alle Angaben durch eine KI nochmals kontrolliert. Bei Unstimmigkeiten erfolgte eine weitere manuelle redaktionelle Prüfung.

Einheitliche Antwortlogik

Für die funktionalen Kriterien verwendet das Ranking grundsätzlich folgende Einstufungen:

Ja: Die Funktion ist offiziell vorgesehen, produktiv nutzbar und ohne projektspezifische Individualentwicklung verfügbar.

Teilweise: Die Funktion ist eingeschränkt, editionsabhängig oder über ein offizielles Zusatzmodul, einen Standardconnector, eine zertifizierte App, eine API-Grundlage oder eine Partnerlösung verfügbar.

Nein: Die Funktion ist nicht vorhanden oder nicht offiziell als Standardfunktion vorgesehen.

Unbekannt: Es liegen keine belastbaren öffentlichen Informationen vor oder vorhandene Quellen widersprechen sich.

Nicht anwendbar: Das Kriterium passt fachlich nicht zum System, Geschäftsmodell oder Produkttyp.

Ist eine Funktion nur in bestimmten Editionen, für bestimmte Kundengruppen oder mithilfe zusätzlicher Module verfügbar, wird dies bei der Einordnung berücksichtigt.

1. Informationen zum Hersteller

1.1 Hersteller und Produkt

Erfasst wird der Name des Herstellers sowie des eigentlichen Core-Systems. Varianten und Editionen, beispielsweise Community-, B2B- oder unterschiedliche kommerzielle Editionen, werden nicht als eigenständige Systeme behandelt, sondern über den Leistungsumfang berücksichtigt.

Bei der Bewertung des Funktionsumfangs kann dabei die leistungsfähigste offiziell verfügbare Edition eines Systems berücksichtigt werden.

1.2 Unternehmenskennzahlen

Unter "Am Markt aktiv seit" wird das Jahr erfasst, seit dem das Produkt unter seinem heutigen Namen und innerhalb des heutigen Unternehmens angeboten wird. Bei einem zugekauften oder umbenannten Produkt zählt entsprechend der Zeitpunkt des Zukaufs beziehungsweise der Umbenennung.

Mit "Go live" ist der Start der ersten produktiven Kundenshops gemeint, nicht die Gründung des Unternehmens oder der Beginn der Softwareentwicklung.

Bei Mitarbeiterzahl und Umsatz werden die Zahlen des gesamten Unternehmens beziehungsweise Konzerns weltweit betrachtet. Ist für ein abgefragtes Jahr keine Umsatzzahl verfügbar, kann die nächstmögliche belastbare Angabe herangezogen und mit dem zugehörigen Jahr dokumentiert werden.

Als Niederlassung in Deutschland gilt eine feste Repräsentanz mit lokalen Ansprechpartnern.

1.3 Release-Frequenz

Erfasst wird, wie häufig größere, offiziell veröffentlichte Hauptversionen oder wesentliche Plattform-Releases bereitgestellt werden. Ein Major Release umfasst typischerweise größere funktionale, technische oder architektonische Änderungen und ist von Bugfixes, Sicherheitsupdates, Patches und kleineren laufenden Aktualisierungen zu unterscheiden.

Die Kategorien sind:

• quartalsweise: ungefähr vier größere Releases pro Jahr
• halbjährlich: ungefähr zwei größere Releases pro Jahr
• jährlich: ungefähr ein größeres Release pro Jahr
• seltener als jährlich: unregelmäßige Hauptversionen oder Abstände von mehr als einem Jahr

Bei SaaS-Systemen mit kontinuierlichen Updates wird der Rhythmus größerer, gebündelter Funktions- oder Plattform-Releases zugrunde gelegt und nicht die Frequenz kleiner laufender Verbesserungen.

2. Technologie

2.1 Betriebsmodell: Cloud und On Premise

Für die Einordnung ist nicht allein entscheidend, ob Server technisch in einem Rechenzentrum oder einer Public Cloud laufen. Ausschlaggebend ist vielmehr, wer Betrieb, Infrastruktur, Updates und Skalierung verantwortet.

Cloud: SaaS, PaaS, Managed Cloud, Private Cloud oder eine dedizierte Cloud, bei der Betrieb, Infrastruktur, Updates oder Skalierung ganz oder überwiegend durch den Hersteller oder einen offiziellen Betriebspartner verantwortet werden.

On Premise: Der Kunde oder ein von ihm beauftragter Dienstleister kann die Software selbst installieren, betreiben und technisch kontrollieren. Das kann auch innerhalb einer selbst verwalteten Cloud-Infrastruktur geschehen.

Cloud + On Premise: Beide Betriebsmodelle werden offiziell unterstützt.

Multi-Tenancy ist ein typisches Merkmal vieler SaaS-Systeme, aber keine Voraussetzung für die Einstufung als Cloud. Auch Single-Tenant-, Private-Cloud- oder dedizierte Instanzen können als Cloud gelten, wenn der Betrieb offiziell vom Anbieter oder einem Betriebspartner verantwortet wird.

Umgekehrt bedeutet On Premise nicht zwingend, dass die Server physisch beim Kunden stehen. Installiert und betreibt ein Kunde die Software selbst beispielsweise in AWS, Azure oder einer anderen Cloud-Umgebung, wird dies als On Premise beziehungsweise Self-hosted eingeordnet.

2.2 Headless-Fähigkeit

Ein System gilt als headless-fähig, wenn Frontend und Commerce-Backend technisch entkoppelt betrieben werden können und externe Frontends zentrale Shopfunktionen über APIs nutzen können. Dazu gehören je nach System beispielsweise Produktdaten, Warenkorb, Preise, Kundenfunktionen, Checkout und Bestellungen.

Ja: Externe Frontends können zentrale Commerce-Funktionen produktiv über APIs nutzen.

Teilweise: Headless-Szenarien sind möglich, jedoch mit funktionalen oder architektonischen Einschränkungen.

Nein: Frontend und Backend sind im Kern fest miteinander gekoppelt.

2.3 API-First-Ansatz

API-first bezeichnet nicht lediglich das Vorhandensein von Schnittstellen, sondern eine Architektur- und Produktphilosophie. Ein System wird als API-first eingeordnet, wenn APIs zentraler Bestandteil der Produktarchitektur sind und wesentliche Funktionen systematisch über dokumentierte Schnittstellen bereitgestellt werden.

Ja: APIs sind zentraler Bestandteil der Architektur und wesentliche Funktionen API-seitig verfügbar.

Teilweise: Moderne APIs sind vorhanden, die Kernarchitektur bleibt jedoch teilweise historisch monolithisch oder frontendzentriert.

Nein: APIs dienen überwiegend als zusätzliche Schnittstellen; wesentliche Funktionen bleiben intern oder frontendgebunden.

2.4 Architektur

Die Architektur beschreibt die strukturelle Kopplung einer Plattform. "Monolithisch" ist dabei ausdrücklich nicht als Werturteil über technische Qualität oder Modernität zu verstehen.

Modular: Wesentliche Funktionen sind entkoppelt, serviceorientiert oder komponentenbasiert organisiert.

Monolithisch: Wesentliche Commerce-Funktionen sind in einem eng gekoppelten Kernsystem gebündelt.

Hybrid beziehungsweise teilweise modular: Ein monolithischer Kern wird mit modularen Erweiterungen kombiniert oder modulare Komponenten arbeiten mit einem zentralen Core zusammen.

Pluginfähigkeit allein macht ein System nicht modular. Auch monolithische Systeme können über eine große Zahl von Plugins verfügen. Entscheidend ist, ob Kernfunktionen selbst entkoppelt, separat skalierbar oder austauschbar sind.

2.5 API-Typ

Erfasst werden offiziell dokumentierte und produktiv nutzbare Schnittstellen. Typische Kategorien sind REST, GraphQL sowie Events oder Webhooks. Interne, experimentelle oder nicht dokumentierte Endpunkte werden nicht berücksichtigt.

Das Vorhandensein von APIs bedeutet ausdrücklich nicht automatisch, dass ein System API-first oder headless-fähig ist. API-Typ, API-First-Ansatz und Headless-Fähigkeit werden deshalb getrennt bewertet.

3. Nativer Funktionsumfang

Eine Funktion gilt für das Ranking als nativ, wenn sie Bestandteil des Kernsystems, einer offiziellen Edition oder eines offiziellen Herstellermoduls ist und ohne projektspezifische Individualentwicklung produktiv genutzt werden kann.

Zertifizierte Apps, Standardconnectoren oder offiziell vorgesehene Partnerlösungen können eine Funktion unterstützen, werden jedoch in der Regel als "Teilweise" eingeordnet, sofern sie nicht vollständig Bestandteil des Kernprodukts sind.

Reine Individualentwicklungen, freie Drittanbieterintegrationen oder externe Systeme ohne offizielle Produktunterstützung gelten nicht als native Funktion.

3.1 Marketing-Automation

Geprüft wird, ob automatisierte Marketingprozesse nativ oder offiziell unterstützt werden. Dazu zählen beispielsweise Segmentierung, Trigger-Mails, Kampagnen, Warenkorbabbrecher, Customer Journeys oder Marketing-Workflows. Reine Newsletter-Exporte oder einfache Mailversandfunktionen reichen dafür nicht aus.

3.2 Content-Management / CMS

Bewertet wird, ob redaktionelle Inhalte wie Seiten, Landingpages, Medien, Content-Blöcke, Blogfunktionen oder Page-Builder-Inhalte innerhalb des Systems gepflegt werden können. Produktbeschreibungen oder einzelne HTML-Felder gelten noch nicht als vollwertiges CMS.

3.3 Product Information Management / PIM

Geprüft wird, ob Produktinformationen strukturiert und zentral verwaltet werden können, beispielsweise Attribute, Varianten, Medien, Übersetzungen, Kataloge, Klassifikationen oder Produktdatenmodelle. Eine einfache Produktverwaltung im Shopbackend wird nicht automatisch als vollwertiges PIM eingeordnet.

3.4 Customer Relationship Management / CRM

Bewertet wird, ob Kundenbeziehungen über die Verwaltung einfacher Kundenkonten hinaus abgebildet werden können. Dazu zählen etwa Kundenprofile, Segmente, Kommunikationshistorien, Account-Funktionen sowie Service- oder Vertriebsfunktionen. Eine reine Kundenliste oder Bestellhistorie reicht nicht aus.

3.5 Marktplatzanbindung

Geprüft wird, ob Produkte, Preise, Bestände oder Bestellungen offiziell mit externen Marktplätzen wie Amazon, eBay, Otto oder Kaufland sowie vergleichbaren Plattformen verbunden werden können.

Die Anbindung externer Marktplätze ist dabei nicht mit der Fähigkeit gleichzusetzen, selbst einen Multi-Vendor-Marktplatz zu betreiben.

3.6 Fulfillment-Dienstleister

Bewertet wird, ob offizielle Integrationen oder Schnittstellen zu Versand-, Lager-, OMS-, WMS-, Retouren- oder Fulfillment-Dienstleistern vorgesehen sind. Manuelle Exporte oder ausschließlich individuell umgesetzte ERP-Anbindungen reichen für eine volle Bewertung nicht aus.

3.7 Appstore / Erweiterungsmarktplatz

Geprüft wird, ob ein offizielles und strukturiertes Verzeichnis für Apps, Plugins, Themes, Erweiterungen oder Connectoren existiert. Reine Partnerlisten, einzelne GitHub-Repositories oder lose Downloadseiten gelten nicht als vollwertiger Appstore.

3.8 Anzahl Plugins, Apps und Erweiterungen

Erfasst wird die Zahl öffentlich verfügbarer Erweiterungen im offiziellen Appstore, Plugin-Verzeichnis oder Marketplace. Da sich diese Bestände laufend verändern und nicht alle Plattformen dieselben Kategorien verwenden, kann die Zahl als gerundete Schätzung angegeben werden. Dabei wird berücksichtigt, ob Apps, Themes, Connectoren, Integrationen oder Partnerlösungen in der jeweiligen Zahl enthalten sind.

4. B2B-Funktionsumfang

4.1 Angebotsanfrage

Geprüft wird, ob B2B-Kunden Produkte oder Warenkörbe als Anfrage einreichen können und daraus ein Angebot, ein individueller Preisprozess oder eine spätere Bestellung entstehen kann. Ein einfaches Kontaktformular reicht dafür in der Regel nicht aus.

4.2 Rollen und Rechte innerhalb von Firmenkonten

Bewertet wird, ob B2B-Kunden innerhalb eines Firmenkontos mehrere Nutzer mit unterschiedlichen Rollen und Rechten verwalten können, beispielsweise Einkäufer, Freigeber, Administratoren oder Kostenstellenverantwortliche. Backend- beziehungsweise Adminrollen des Shopbetreibers sind damit nicht gemeint.

4.3 Komplexe Konfigurationen

Geprüft wird, ob technisch anspruchsvolle Produkte mit Regeln, Abhängigkeiten, Varianten, Stücklisten, Plausibilitätsprüfungen oder dynamischer Preislogik konfiguriert werden können. Einfache Varianten wie Farbe oder Größe reichen dafür nicht aus.

4.4 Mandantenfähigkeit

Mandantenfähigkeit bedeutet, dass mehrere organisatorisch, rechtlich, markenbezogen oder länderbezogen getrennte Einheiten auf einer Plattform verwaltet werden können. Beispiele sind Ländergesellschaften, Marken, Vertriebseinheiten, Händlerportale oder getrennte Geschäftskanäle.

Mehrsprachigkeit oder mehrere Storefronts allein reichen dafür nicht zwingend aus.

Mandantenfähigkeit wird außerdem von B2B-Account-Strukturen unterschieden: Ein Unternehmenskunde mit mehreren Benutzern, Budgets und Preislisten ist eine B2B-Organisation, aber nicht automatisch ein Mandant auf Plattformebene.

4.5 Production on Demand

Gemeint ist die Fähigkeit, Produkte erst nach Bestellung, Konfiguration oder Individualisierung zu produzieren, zu fertigen oder an einen Produktionsprozess zu übergeben. Beispiele sind Maßmöbel, Druckprodukte, Werbemittel, individualisierte Textilien, technische Komponenten oder Sonderanfertigungen.

Dropshipping, Streckenversand oder eine normale Lieferantenbestellung gelten nicht automatisch als Production on Demand. Entscheidend ist, ob ein Produktions-, Fertigungs-, Individualisierungs- oder Konfigurationsprozess ausgelöst wird und sich der Preis in Abhängigkeit von der Konfiguration bestimmen kann.

4.6 Punchout

Bewertet wird, ob sich das Shopsystem in B2B-Beschaffungssysteme integrieren lässt, typischerweise über OCI, cXML oder vergleichbare Punchout-Standards.

Eine allgemeine API wird nicht automatisch als Punchout-Funktion gewertet. Punchout bezeichnet speziell den katalog- und warenkorbbezogenen Wechsel aus einem Procurement-System in den Shop und anschließend zurück in das Beschaffungssystem.

5. Ökosystem

5.1 Installationen international

Erfasst wird die geschätzte weltweite Zahl produktiver Shops, aktiver Commerce-Installationen, SaaS-Kunden oder Enterprise-Deployments. Testinstallationen, lokale Entwicklerumgebungen, Demos oder abgeschaltete Instanzen werden nicht berücksichtigt.

Wo keine exakte Zahl belastbar ermittelt werden kann, sind Bandbreiten möglich.

5.2 Installationen in DACH

Erfasst wird entsprechend die geschätzte Zahl produktiver Installationen in Deutschland, Österreich und der Schweiz. Ist keine belastbare Regionalisierung möglich, werden konservative Schätzungen, Bandbreiten oder die Angabe "Unbekannt" verwendet.

5.3 Partnerverzeichnis

Bewertet wird, ob ein offizielles Partnerverzeichnis existiert, beispielsweise für Agenturen, Integratoren, Technologie-, Implementierungs- oder Lösungspartner. Einzelne Referenzpartner oder Kundenlisten reichen dafür nicht aus.

5.4 Anzahl genannter Partner

Erfasst wird die Zahl öffentlich genannter Partner innerhalb offizieller Partnerprogramme oder Verzeichnisse. Kunden, reine Marktplatzanbieter ohne Partnerstatus oder nicht öffentlich gelistete Partner werden nicht mitgezählt. Auch hier können Bandbreiten verwendet werden.

5.5 Anzahl Partner in DACH

Berücksichtigt werden Partner mit Sitz, Niederlassung oder klar erkennbarem Tätigkeitsschwerpunkt in Deutschland, Österreich oder der Schweiz. Internationale Partner ohne erkennbare DACH-Präsenz werden nicht berücksichtigt.

5.6 Entwicklercommunity

Geprüft wird, ob eine erkennbare öffentliche Entwicklercommunity besteht. Indizien können beispielsweise ein Forum, öffentliche GitHub-Aktivität, Slack- oder Discord-Communities, StackOverflow-Aktivität, Community-Events oder öffentliche Issue-Tracker sein.

Reine Supportportale oder Marketing-Communities reichen dafür nicht aus.

5.7 Entwicklerdokumentation

Bewertet wird, ob technische Dokumentation für Entwickler verfügbar ist, beispielsweise API-Dokumentationen, SDKs, Developer-Portale, Plugin-Guides, Webhook-Dokumentationen, Integrationsleitfäden oder Deployment-Dokumentationen.

Reine Benutzerhandbücher oder Marketingseiten erfüllen dieses Kriterium nicht.

6. Preisgestaltung

6.1 Lizenz

Erfasst wird, ob für die produktive Nutzung grundsätzlich Lizenz-, SaaS-, Subskriptions- oder Plattformgebühren anfallen. Kostenlose Trials, Demos, Developer-Sandboxen oder zeitlich begrenzte Testversionen werden nicht als kostenlose Nutzung gewertet.

Kostenlos: Das System kann dauerhaft produktiv ohne Lizenzgebühr genutzt werden. Kosten für Betrieb, Hosting oder Dienstleister können trotzdem entstehen.

Kostenpflichtig: Für die produktive Nutzung fallen regelmäßig Lizenz-, SaaS-, Subskriptions- oder Plattformgebühren an.

Kostenlos & kostenpflichtig: Es existieren sowohl dauerhaft kostenlose Varianten als auch kostenpflichtige Editionen, Cloud-Angebote oder Enterprise-Versionen.

6.2 Lizenzmodell

Bei kostenpflichtigen Angeboten wird zusätzlich die Kostenlogik erfasst. Mehrfachnennungen sind möglich.

• Kostenlos: kostenloses Lizenzmodell, beispielsweise bei Open Source
• Abo: regelmäßige monatliche, jährliche, nutzungs- oder umsatzbasierte Zahlung
• Einmalkauf: einmalige Lizenzzahlung, gegebenenfalls ergänzt um Wartung oder Support
• Sonstige: beispielsweise Enterprise-Verträge, Umsatzbeteiligung, projektbasierte Lizenzierung, Open-Source-plus-Enterprise-Modelle, Mischmodelle oder individuell verhandelte Konditionen

6.3 Jährliche Betriebskosten eines Einsteigershops

Als Orientierung dient ein kleiner professioneller Shop mit Standardfunktionen, begrenztem Sortiment, einem Markt, einer Sprache, wenigen Integrationen und moderatem Traffic.

Berücksichtigt werden insbesondere:

• Lizenz beziehungsweise SaaS
• Hosting
• Basis-Apps
• einfache Wartung
• Updates
• technische Betreuung

Nicht berücksichtigt werden Relaunch, Designprojekt, größere Migration, umfangreiche Individualentwicklung oder Online-Marketing.

Da die tatsächlichen Kosten stark vom konkreten Projekt abhängen können, werden auch Bandbreiten akzeptiert.

6.4 Jährliche Enterprise-Betriebskosten

Für die Enterprise-Kategorie werden die plattformnahen jährlichen Kosten eines größeren professionellen Commerce-Betriebs betrachtet. Dazu gehören insbesondere Lizenz beziehungsweise SaaS, Hosting oder Cloud-Betrieb, Wartung, Support, Monitoring, technischer Betrieb und unmittelbar plattformbezogene Kosten.

Weiter gefasste Gesamtbetriebskosten wie Agenturleistungen, laufende Entwicklung, Integrationen und projektspezifische Weiterentwicklung werden davon getrennt betrachtet.

Als Vergleichsszenario dient ein größerer professioneller E-Commerce-Betrieb mit:

• etwa 80 bis 250 Millionen Euro Online-Umsatz pro Jahr,
• 500.000 bis 3 Millionen Bestellungen,
• 50.000 bis 500.000 Artikeln,
• mehreren Märkten oder Sprachen,
• hoher Integrationsdichte und
• einem professionellen E-Commerce-Team.

Die zugrunde gelegte Lizenz beziehungsweise Edition muss für komplexe Handelsorganisationen geeignet sein. Relevante Aspekte sind insbesondere Skalierbarkeit, Internationalisierung, Multi-Shop- oder Mandantenfähigkeit, API- und Integrationsfähigkeit, Erweiterbarkeit, Performance, Betriebssicherheit und professioneller Support.

Auch bei den Enterprise-Kosten können Bandbreiten verwendet werden.

7. Umgang mit Grenzfällen und Herstellerkorrekturen

Gerade bei modernen Commerce-Plattformen lässt sich Funktionsumfang nicht immer eindeutig mit "Ja" oder "Nein" beschreiben. Deshalb wurde bei der Datenprüfung zusätzlich betrachtet,

• ob eine Funktion Bestandteil des Kernsystems, einer Edition oder eines offiziellen Moduls ist,
• ob eine bestimmte Edition, ein Zusatzmodul, eine App, ein Connector oder ein Partner erforderlich ist,
• ob Individualentwicklung notwendig ist,
• ob die Funktion produktiv verfügbar ist oder lediglich als Roadmap-Thema, Beta-Version oder kundenspezifischer Einzelfall existiert und
• welche öffentliche Quelle die jeweilige Angabe belegt.

Roadmap-Funktionen, Beta-Versionen und kundenspezifische Einzelfälle werden nicht als voll verfügbare Standardfunktion gewertet. Sie können jedoch als ergänzende Information dokumentiert werden.

Damit soll das Ranking weder die maximal denkbare technische Machbarkeit eines Systems noch einzelne besonders weitreichende Kundenprojekte vergleichen. Entscheidend ist vielmehr, welche Fähigkeiten ein Shopsystem zum Zeitpunkt der Erhebung offiziell, nachvollziehbar und reproduzierbar für den Markt bereitstellt.