Wenn EShop by Ossolution Team als mögliche Zielplattform bewertet wird, hängt die Eignung von deutlich mehr ab als davon, ob Product-, Customer- und Order-Datensätze übertragen werden können. Entscheidend ist, ob der Händler den künftigen Shop bewusst in einer Joomla-Umgebung betreiben möchte, in der Commerce-Daten, Joomla-Menüs, Module, Templates, Sprachverwaltung, Zahlungs-Plugins, Versandmethoden, Steuerregeln und Checkout-Konfiguration gemeinsam die spätere Storefront bestimmen.
Für viele Händler ist EShop ein praktikables Ziel, weil Content und Commerce eng zusammenbleiben können. Product-Kataloge lassen sich mit Joomla-Artikeln, Manufacturer-Seiten, individuellen Modulen, mehrsprachigen Inhalten und der Website-Navigation verbinden. Genau diese Stärke bringt jedoch Verantwortung mit sich: Wer EShop als Ziel wählt, muss sowohl die migrierten Commerce-Datensätze als auch die Joomla-Struktur validieren, die diese Datensätze für Kunden tatsächlich nutzbar macht.
Was Eignung für EShop in der Migrationsplanung bedeutet
Die Eignung von EShop sollte als Entscheidung über das künftige Betriebsmodell verstanden werden. Ein Shop kann äußerlich einfach wirken und dennoch von Product-Optionen, Attributen, Downloads, Kundengruppen, benutzerdefinierten Checkout-Feldern, Versandzonen, Zahlungs-Plugins, Gutscheincodes, Steuerklassen, mehrsprachigen Labels, Modulpositionen oder Template-Overrides abhängen. Diese Beziehungen beeinflussen den Migrationsumfang, weil sie bestimmen, ob EShop die nutzbare Shop-Erfahrung abbilden kann, ohne dass das Projekt in nicht unterstützte individuelle Rekonstruktion abgleitet.
Ein starkes EShop-Profil weist meist drei Merkmale auf. Erstens soll Joomla weiterhin die Website-Grundlage bilden. Zweitens lassen sich Katalog und Bestellhistorie anhand konkreter Beispiele erklären. Drittens ist klar, dass aktiver Checkout, Zahlung, Versand, Steuern, E-Mails, Layout, Menüs und Modulverhalten im Ziel eingerichtet und getestet werden müssen.
| Eignungsdimension | Was zu prüfen ist | Warum es für EShop wichtig ist |
|---|---|---|
| Joomla-Verantwortung | Ob der Händler Joomla als künftige Website-Grundlage bewusst betreiben möchte | EShop läuft innerhalb von Joomla; Seitenstruktur und Shopbetrieb sind daher verbunden. |
| Kataloglogik | Products, Categories, Manufacturers, Optionen, Attribute, Downloads, Bestand und Bilder | Katalogbedeutung muss nach der Migration verständlich bleiben und darf nicht nur in der Datenbank vorhanden sein. |
| Checkout-Verhalten | Zahlungsarten, Versandmethoden, Steuerklassen, Währungen, benutzerdefinierte Felder und Order-Status | Aktives Checkout-Verhalten hängt von Zielkonfiguration, Plugins und Validierung ab. |
| Customer- und Order-Historie | Kundengruppen, Adressen, Order-Positionen, Gutscheincodes, Wertgutscheine, Zahlungen, Erstattungen und Statuskontext | Historische Datensätze brauchen genügend geschäftliche Bedeutung für Service, Auswertung und Kontinuität. |
| Storefront-Präsentation | Joomla-Menüs, Module, Templates, Aliase, Metadaten, mehrsprachige Seiten und Weiterleitungen | Migrierte Datensätze sind nur nützlich, wenn Kunden sie finden und verstehen können. |
| Individuelle Abhängigkeiten | Eigene Felder, alte Erweiterungen, individuelle Datenbanktabellen, ERP-Kennungen oder nicht standardisierte Logik | Nicht unterstützte Daten oder Prozesse können eine gesonderte Datenprüfung oder separate Implementierungsarbeit erfordern. |
Die Eignung sollte nicht auf ein Ja oder Nein reduziert werden. EShop kann für einen Joomla-Händler sehr gut, für einen anderen nur bedingt und für ein Unternehmen mit Erwartungen an vollständig gehostete Einfachheit weniger geeignet sein. Unterschiede zeigen sich vor allem bei Implementierungsverantwortung, Katalogkomplexität, Checkout-Erwartungen und dem Anteil individuellen Verhaltens, der erhalten bleiben muss.
Profile mit hoher Eignung
EShop ist besonders geeignet, wenn ein Händler bewusst eine Joomla-zentrierte Commerce-Website betreiben möchte und die Verantwortung für die Joomla-Umgebung geklärt ist. Diese Händler suchen nicht nur einen Speicherort für Products, sondern möchten Product-Seiten, Category-Pfade, Manufacturer-Seiten, Module, Artikel, Menüs und Checkout-Abläufe innerhalb derselben Website-Struktur betreiben.
Das stärkste Profil ist ein Händler, der sich bereits strategisch für Joomla entschieden hat. Das Unternehmen kann contentreiche Seiten, SEO-relevante Category-Routen, Produktberatungsseiten, mehrsprachige Inhalte, Joomla-Benutzer oder Site-Module einsetzen, die den Kaufprozess unterstützen. In diesem Fall kann EShop sinnvoll sein, weil der Shop nicht vom CMS getrennt werden muss. Die Migrationsplanung konzentriert sich dann darauf, ob die Commerce-Daten des Quellshops in einen nutzbaren EShop-Katalog mit ausreichender Joomla-Unterstützung überführt werden können.
| Profil mit hoher Eignung | Warum EShop gut passen kann | Schwerpunkt der Planung |
|---|---|---|
| Joomla-zentrierter Händler | Die künftige Website ist bewusst auf Joomla aufgebaut. | Commerce-Migration mit Joomla-Menüs, Modulen, Templates, Sprachstruktur, Aliasen und Weiterleitungen koordinieren. |
| Content-und-Commerce-Unternehmen | Produktinformation, Artikel, Landingpages und Kaufpfade sollen eng zusammenarbeiten. | Prüfen, wie Product- und Category-Seiten mit Joomla-Inhalten und Navigation verbunden werden. |
| Händler mit strukturiertem Katalog | Products, Categories, Manufacturers, Optionen, Attribute, Bilder, Downloads und Bestand sind dokumentierbar. | Repräsentative Products verwenden, um die Katalogbedeutung im Ziel zu validieren. |
| Händler mit beherrschbaren Checkout-Anforderungen | Zahlung, Versand, Steuern, Gutscheine, Währungen und Status können gezielt eingerichtet werden. | Historische Daten von Zielkonfiguration trennen und Checkout vor dem Go-live testen. |
| Händler mit Joomla-Implementierungsunterstützung | Entwickler, Agentur oder geschultes internes Team kann Templates, Module, Plugins und Zielsetup betreuen. | Verantwortung für Konfiguration, Präsentation, Validierung und Go-live-Bereitschaft festlegen. |
Auch bei komplexeren Katalogen kann EShop gut passen, wenn die Komplexität strukturiert statt chaotisch ist. Product-Optionen, Attribute, Downloads, Manufacturer-Beziehungen, Sonderpreise, Gutscheinverläufe oder Kundengruppen sind beherrschbar, wenn das Unternehmen die Bedeutung der einzelnen Felder erklären und Testbeispiele bereitstellen kann.
Beispielsweise können Größe und Farbe auswählbare Product-Optionen sein, während Material, Kompatibilität, Marke und technische Spezifikationen eher Attribute darstellen. Downloads können auszuliefernde digitale Assets sein, Anhänge dagegen unterstützende Dokumente. Gutscheincodes und Wertgutscheine können historische Order-Kontexte, aktive Marketinglogik oder beides sein. Je klarer diese Bedeutungen vor der Festlegung des Migrationsumfangs sind, desto besser lässt sich EShop als Ziel bewerten.
Bedingt geeignete Profile
EShop ist bedingt geeignet, wenn die Plattformrichtung grundsätzlich passt, die Migration jedoch von sorgfältiger Vorbereitung, Zielkonfiguration oder einer genaueren Eignungs- und Umfangsprüfung abhängt. Solche Händler können weiterhin gute EShop-Kandidaten sein, doch das Projekt darf nicht als einfacher Datensatztransfer behandelt werden.
Ein typisches bedingtes Profil sind komplexe Checkout-Anforderungen. EShop kann zahlreiche Commerce-Einstellungen unterstützen, doch aktives Verhalten hängt von Zielkonfiguration und Plugin-Bereitschaft ab. Zahlungs-Gateways, Versandmethoden, Steuerklassen, Geozonen, Währungen, benutzerdefinierte Checkout-Felder, Order-Status, E-Mail-Templates und Benachrichtigungen gehören daher in Implementierung und Validierung und dürfen nicht als automatische Folge historischer Orders angenommen werden.
| Bedingung | Warum die Eignung geprüft werden muss | Vorzubereitender Nachweis |
|---|---|---|
| Komplexe Product-Optionen | Optionen können Preis, SKU-Bedeutung, Bilder, Pflichtauswahl und Order-Positionen beeinflussen. | Beispiel-Products mit allen wichtigen Optionsmustern. |
| Attributreicher Katalog | Attribute können Filter, Vergleiche, Spezifikationen oder Produktverständnis unterstützen. | Attributgruppen, Product-Beispiele und Erwartungen an die Darstellung. |
| Kundengruppenabhängiges Verhalten | Preise, Zugriff, Steuern oder Rabatte können von der Gruppenzugehörigkeit abhängen. | Gruppendefinitionen, Beispiel-Customers und Beispiel-Orders. |
| Benutzerdefinierte Checkout-Felder | Felder können in Orders, E-Mails, Rechnungen oder Administration erscheinen müssen. | Feldliste, Validierungsregeln, Zielzuordnung und Order-Beispiele. |
| Mehrsprachiger Shop | Product-Labels, Category-Namen, Aliase, Metadaten, Module und Checkout-Texte brauchen Sprachprüfung. | Sprachenliste, übersetzte Product-/Category-Beispiele und zentrale Seiten. |
| Modul- oder Template-intensive Storefront | Product-Auffindbarkeit kann von Joomla-Modulen oder Overrides abhängen. | Modulinventar, Template-Hinweise, Screenshots und launchkritische Seiten. |
| Integrationssensitiver Betrieb | ERP-, Buchhaltungs-, Auftragsabwicklungs-, CRM- oder Bestandsysteme können Kennungen oder Regeln besitzen. | Externe IDs, Integrationsfelder, Exportbeispiele und Verantwortungsnotizen. |
Die Kernfrage lautet nicht, ob EShop eine bestimmte Funktion grundsätzlich besitzt. Entscheidend ist, ob die konkreten Datensätze, Regeln und Abhängigkeiten des Händlers in einer wartbaren EShop-Konfiguration dargestellt werden können. Eine Funktion kann vorhanden sein und dennoch zusätzliche Konfiguration, Plugin-Installation, Layoutarbeit, Feldbehandlung oder eine gesonderte Prüfung nicht standardisierter Daten erfordern.
Bedingte Eignung tritt besonders bei Quellsystemen auf, deren Storefront-Layout, URL-Routing, Checkout-Felder oder Integrationen anders verwaltet wurden. EShop kann trotzdem das richtige Ziel sein, doch vor der endgültigen Festlegung des Umfangs muss die Differenz zwischen Quellerwartungen und Zielverantwortung geklärt sein.
Weniger geeignete oder nicht ideale Profile
EShop ist weniger geeignet, wenn ein Händler die Vorteile einer vollständig gehosteten Commerce-Plattform erwartet, ohne die Verantwortung für Joomla übernehmen zu wollen. Da EShop innerhalb von Joomla läuft, bleiben Händler oder Implementierungsteam für Hosting, Updates, Erweiterungskompatibilität, Templates und technische Wartung verantwortlich.
| Warnsignal | Warum es problematisch ist | Praktische Reaktion |
|---|---|---|
| Keine Verantwortung für Joomla-Wartung | EShop hängt von der umgebenden Joomla-Umgebung ab. | Festlegen, wer Hosting, Updates, Erweiterungen, Templates und Support betreut. |
| Erwartung eines gehosteten SaaS-Modells | Der Händler erwartet Plattformbetrieb für Checkout, Hosting, Updates und Integrationen. | EShop-Verantwortung mit dem gewünschten Betriebsmodell vergleichen. |
| Unklare Katalogstruktur | Optionen, Attribute, Categories, Downloads und Product-Beziehungen lassen sich nicht erklären. | Umfangsfreigabe verschieben, bis repräsentative Beispiele geprüft sind. |
| Nicht unterstützte individuelle Abläufe | Marketplace-, Subscription-, Membership-, Vendor- oder ERP-gesteuertes Verhalten kann außerhalb gewöhnlicher EShop-Daten liegen. | Nicht standardisierte Daten, zusätzliche Erweiterungen, separate Implementierung oder anderes Ziel prüfen. |
| Keine Storefront-Implementierungsunterstützung | Menüs, Module, Templates, Aliase und Weiterleitungen bleiben ohne Verantwortlichen. | Joomla-Implementierungsverantwortung vor Freigabe festlegen. |
| Erwartung, dass Live-Einstellungen automatisch migrieren | Zahlung, Versand, Steuern, Checkout und E-Mails müssen im Ziel eingerichtet und getestet werden. | Historische Daten konsequent von Zielkonfiguration trennen. |
EShop kann außerdem für Marketplace-ähnliche Abläufe, stark individuellen Checkout, Abonnementabrechnung, membership-gesteuerten Einkauf, Multi-Vendor-Provisionslogik, ERP-gesteuerten Bestand oder Preise sowie stark angepasste Legacy-Erweiterungen weniger geeignet sein. Einige dieser Anforderungen lassen sich mit zusätzlicher Joomla-Implementierung umsetzen, dürfen aber ohne Nachweis nicht als gewöhnlicher Migrationsumfang betrachtet werden.
Ein schwächeres Profil sollte eine echte Plattformentscheidung und Umfangsprüfung auslösen. Bleibt EShop dennoch die bevorzugte Richtung, kann das Projekt stärkere Vorbereitung, eine gesonderte Datenprüfung, zusätzliche Implementierungsunterstützung oder einen reduzierten ersten Go-live-Umfang benötigen.
Quellplattform-Erwartungen, die sich nicht sauber übertragen lassen
Probleme entstehen häufig, wenn angenommen wird, jede Funktion, Einstellung, jedes Layout und jeder Ablauf der Quellplattform habe ein direktes EShop-Pendant. Die Quellplattform kann Varianten anders modellieren, Attribute als Filter verwenden, benutzerdefinierte Felder in App-Tabellen speichern, SEO-Pfade automatisch erzeugen oder Kundengruppen getrennt von Joomla-Benutzern verwalten. Solche Unterschiede blockieren die Migration nicht zwingend, müssen aber vor der Umfangsfreigabe sichtbar sein.
| Erwartung aus dem Quellshop | EShop-Eignungsfrage | Warum sie wichtig ist |
|---|---|---|
| Varianten sollen exakt übernommen werden | Kann die Variantenlogik als EShop-Option, Attribut oder andere Zielstruktur abgebildet werden? | Product-Auswahl muss kaufbar und verständlich bleiben. |
| Product-Filter sollen identisch funktionieren | Beruhen Filter auf Categories, Attributen, Modulen, Tags oder benutzerdefinierten Feldern? | Auffindbarkeit kann zusätzliche Zielkonfiguration erfordern. |
| Customer-Konten sollen eins zu eins übereinstimmen | Wie sollen Customer-Datensätze mit Joomla-Benutzern, Kundengruppen, Adressen und Order-Historie verbunden werden? | Kontinuität hängt von Commerce-Daten und Joomla-Identität ab. |
| Checkout-Felder sollen sofort weiterarbeiten | Sind die Felder standardisiert, konfigurierbar, individuell oder erweiterungseigen? | Individuelles Checkout-Verhalten kann Zuordnung oder gesonderte Prüfung erfordern. |
| Zahlungs- und Versandeinstellungen sollen übernommen werden | Welche Angaben sind historische Order-Evidenz und welche aktive Zielkonfiguration? | Go-live-Bereitschaft hängt von eingerichteten und getesteten Ziel-Plugins ab. |
| SEO-URLs sollen unverändert bleiben | Können Aliase, Menüs, Metadaten und Weiterleitungen Kontinuität ermöglichen? | Sichtbarkeit und Lesezeichen können Joomla-Routingarbeit erfordern. |
| Daten alter Erweiterungen sollen normal übertragen werden | Liegen sie in unterstützten Quellexporten oder in individuellen Erweiterungstabellen? | Nicht unterstützte Daten können gesonderte Extraktion und Transformation benötigen. |
Diese Erwartungen sollten anhand konkreter Quellbeispiele geprüft werden. Eine kleine Auswahl repräsentativer Products, Customers, Orders, Checkout-Datensätze, URLs und individueller Felder zeigt meist mehr als eine breite Funktionscheckliste.
Nachweise, die vor der Auswahl von EShop bestätigt werden sollten
Die besten EShop-Kandidaten können bereits vor der endgültigen Festlegung des Migrationsumfangs konkrete Nachweise liefern. Diese müssen nicht komplex sein, sollten aber spezifisch genug sein, um zu zeigen, dass das Zielsetup das künftige Geschäftsmodell tragen kann.
Geeignete Nachweise sind unter anderem repräsentative Products mit Optionen und Attributen, komplexe Products mit Bildern und Downloads, Category-/Manufacturer-Beispiele, Customer-Datensätze mit Adressen und Gruppen, abgeschlossene Orders mit Rabatten und Steuern, erstattete oder angepasste Orders, mehrsprachige Products, Checkout-Feldbeispiele, wichtige URLs sowie Seiten, deren Darstellung von Joomla-Modulen oder Templates abhängt.
| Eignungssignal | Starker Nachweis | Schwacher Nachweis |
|---|---|---|
| Katalogklarheit | Product-Beispiele zeigen Category, Manufacturer, Optionen, Attribute, Bilder, Bestand und Preisbedeutung. | Product-Daten existieren, aber niemand kann erklären, welche Felder Kaufverhalten beeinflussen. |
| Checkout-Klarheit | Zahlung, Versand, Steuern, Währungen, Gutscheincodes, Wertgutscheine und Checkout-Felder sind dokumentiert. | Es wird erwartet, dass sich der Live-Checkout ohne Zielsetup reproduziert. |
| Customer-/Order-Klarheit | Gruppen, Adressen, Order-Positionen, Statushistorie, Rabatte, Steuern und Erstattungen sind verstanden. | Historische Orders existieren, aber ihre geschäftliche Bedeutung ist unklar. |
| Joomla-Bereitschaft | Menüs, Module, Templates, Aliase, Metadaten, Weiterleitungen und Mehrsprachigkeit haben Verantwortliche. | Shop-Daten werden losgelöst von der Website betrachtet, die sie darstellen muss. |
| Klarheit des Migrationspfads | Standardumfang, zusätzliche Projektkoordination, Zielkonfiguration und Grenzen nicht standardisierter Daten sind verstanden. | Individuelles Verhalten wird ohne Prüfung als normaler Migrationsumfang angenommen. |
Fehlen diese Signale, kann EShop weiterhin passen. Vor einer belastbaren Entscheidung ist dann jedoch zusätzliche Vorbereitung nötig. Repräsentative Prüfung ist besonders wertvoll, weil sie die Eignungsdiskussion in sichtbare Evidenz übersetzt statt auf Annahmen zu stützen.
Entscheidungs-Gates für die EShop-Eignung
Die Eignung hängt davon ab, ob Joomla künftig die Website-Grundlage bilden soll und ob das Commerce-Modell von EShop die benötigten Products, Customers, Orders, Preise, Erweiterungen und Storefront-Abläufe tragen kann.
| Gate | Bestehenskriterium | Warnsignal |
|---|---|---|
| Joomla-Grundlagen-Gate | Das Unternehmen möchte Joomla bewusst für Inhalte, Benutzer, Templates und Website-Administration einsetzen. | Joomla wird nur beibehalten, weil es im bisherigen System bereits vorhanden ist. |
| Product-Modell-Gate | Product-Optionen, Attribute, Manufacturers, Categories, Bestand und digitale oder physische Verkaufsanforderungen sind dokumentiert. | Quellstrukturen sollen ohne Interpretation übernommen werden. |
| Customer- und Preis-Gate | Kundengruppen, Steuern, Rabatte, Preise und Kontoerwartungen haben definierte Zielergebnisse. | Gruppennamen oder Preisregeln existieren ohne klare geschäftliche Verantwortung. |
| Erweiterungs-Gate | Zahlung, Versand, Auswertung, Integrationen und EShop-Erweiterungen haben Verantwortliche und Kompatibilitätspläne. | Es wird angenommen, dass verfügbare Erweiterungen automatisch jede Anforderung lösen. |
| Storefront-Gate | Joomla-Templates, Module, Navigation, Inhalte, URLs und Product-Präsentation haben einen Zielplan. | Es wird erwartet, dass Datenmigration das Kundenerlebnis rekonstruiert. |
| Wartungs-Gate | Joomla, EShop, Erweiterungen, Sicherheit, Backups und Updates haben verantwortliche Stellen. | Selbstgehostete Kontrolle wird ohne Lifecycle-Verantwortung erwartet. |
EShop ist stark geeignet, wenn Joomla und EShop gemeinsam das künftige Betriebsmodell unterstützen. Die Eignung ist bedingt, wenn Erweiterungs-, Katalog- oder Verantwortungsfragen offen sind, und geringer, wenn der Händler vor allem einen standardisierten gehosteten Shop sucht.
Fazit
EShop by Ossolution Team ist häufig eine gute Zielplattform für Händler, die Joomla bewusst als Website-Grundlage beibehalten und Commerce als Teil dieser Joomla-Umgebung betreiben möchten. Besonders gut passt die Plattform, wenn Katalogstrukturen, Product-Optionen, Attribute, Customers, Kundengruppen, Order-Historie, Checkout-Erwartungen, Steuern, Versand, Zahlungskontext, Mehrsprachigkeit und Storefront-Präsentation anhand repräsentativer Beispiele dokumentiert und validiert werden können.
Die Eignung wird bedingt oder schwächer, wenn gehostete Einfachheit erwartet wird, Joomla-Implementierungsverantwortung fehlt, nicht unterstützte individuelle Abläufe den Betrieb bestimmen oder angenommen wird, Zahlung, Versand, Steuern, Checkout, SEO und Storefront-Verhalten würden automatisch mitmigrieren. Eine belastbare Entscheidung übersetzt die Plattformpräferenz daher in einen klaren Umfang aus unterstützten Datensätzen, Zielkonfiguration, Joomla-Implementierung, repräsentativen Nachweisen und gesonderter Prüfung nicht standardisierter Daten.
Häufige Fragen
Ist EShop für Händler geeignet, die bereits Joomla verwenden?
Ja. EShop kann sehr gut passen, wenn Joomla Teil der künftigen Website-Strategie bleibt und die umgebende Joomla-Umgebung aktiv verwaltet wird. Katalogstruktur, Checkout-Erwartungen, Module, Templates, Mehrsprachigkeit und Implementierungsverantwortung müssen trotzdem bestätigt werden.
Ist EShop für komplexe Product-Optionen geeignet?
Es kann geeignet sein, wenn die Product-Logik klar erklärt werden kann. Optionen, Attribute, Attributgruppen, Sonderpreise, Downloads, benutzerdefinierte Felder und Kundengruppenverhalten sollten anhand repräsentativer Beispiele geprüft werden.
Wann ist EShop ein weniger geeignetes Ziel?
Wenn ein vollständig gehostetes Commerce-Erlebnis erwartet wird, Joomla-Implementierungsunterstützung fehlt, der Shop stark von nicht unterstützten individuellen Abläufen abhängt oder Live-Zahlung, Versand, Steuern und Storefront-Setup automatisch mitmigrieren sollen.
Passt EShop zu mehrsprachigen Shops?
Ja, sofern Sprachumfang, Aliase, übersetzte Product-/Category-Inhalte, Metadaten, Module, Checkout-Sprachverhalten und Validierungsbeispiele sorgfältig geplant werden. Mehrsprachige Komplexität darf nicht als automatische Übernahme vorausgesetzt werden.
Erfordert die Wahl von EShop automatisch individuelle Datenprüfung oder separate Implementierung?
Nein. Ein klar unterstützter Umfang kann ohne individuelle Behandlung auskommen. Eine gesonderte Prüfung wird relevant, wenn nicht unterstützte Erweiterungsdaten, eigene Felder, externe Systemkennungen, individuelle Transformationen oder Anpassungen der Migrationslogik erforderlich sind.
Reicht Joomla-Erfahrung allein aus, um EShop als geeignet zu bewerten?
Nein. Joomla-Erfahrung hilft bei Administration und Verantwortung, ersetzt aber nicht die Prüfung, ob Product-, Options-, Customer-, Order-, Preis-, Erweiterungs- und Storefront-Strukturen von EShop zum künftigen Commerce-Modell passen.