Joomla ist eine starke potenzielle Zielplattform, wenn das Unternehmen eine CMS-zentrierte Umgebung benötigt und nicht nur einen Ort für Products und Orders. Besonders gut passt Joomla, wenn Inhaltsstruktur, Menüs, Zugriffskontrolle, mehrsprachige Seiten, Templates, Module und Erweiterungen für den Betrieb der Website zentral sind. Schwächer ist die Passung, wenn Joomla Core wie ein nativer Online-Shop funktionieren soll, ohne dass feststeht, welche Commerce-Erweiterung oder individuelle Komponente die Commerce-Datensätze verantwortet.
Eine Eignungsentscheidung für Joomla sollte deshalb mit der Frage nach der Zuständigkeit beginnen. Geht es bei der Migration vor allem um Inhalte, Benutzer, Menüs, Kategorien, Zugriffsebenen, Mehrsprachigkeit und Website-Architektur, kann Joomla das richtige Ziel sein. Geht es dagegen um Products, Orders, Customers, Checkout, Versand, Zahlung, Bestand, Coupons oder Bewertungen, muss feststehen, welche Commerce-Erweiterung oder individuelle Implementierung diese Datensätze im Ziel besitzen wird.
Was Joomla-Eignung in der Migrationsplanung bedeutet
Die praktische Frage lautet nicht: „Kann Joomla eine Website betreiben?“ Joomla kann viele Arten von Websites unterstützen. Entscheidend ist vielmehr, ob der Händler die betrieblichen Verantwortlichkeiten übernehmen will, die mit einem Joomla-zentrierten Ziel verbunden sind: Erweiterungsverwaltung, Template-Verhalten, Governance von Menüs und Aliasen, Zugriffsplanung, Mehrsprachigkeit sowie technische Verantwortung durch Entwickler oder Agentur.
| Eignungsdimension | Starkes Joomla-Signal | Schwaches Joomla-Signal |
|---|---|---|
| Zweck der Website | Inhalte, Zugriff, Mehrsprachigkeit oder erweiterungsgetriebene Struktur sind wichtig. | Der Händler möchte lediglich einen einfachen gehosteten Shop-Oberfläche. |
| Technische Verantwortung | Ein Joomla-erfahrenes Team, eine Agentur oder ein Entwickler betreut die Umgebung. | Niemand ist darauf vorbereitet, Joomla-Updates, Templates, Erweiterungen oder Einrichtung zu verwalten. |
| Commerce-Modell | Commerce wird durch eine benannte Erweiterung oder individuelle Komponente bereitgestellt. | Joomla Core soll allein natives Shop-Verhalten bereitstellen. |
| URL- und Navigationsanforderungen | Menüs, Aliase, Weiterleitungen und Inhaltsrouten sind wichtige Migrationswerte. | Die URL-Struktur soll ohne Prüfung des Joomla-Routings einfach übernommen werden. |
| Anpassung | Erweiterungsflexibilität ist gewünscht und dokumentiert. | Individuelle Komponenten sind undokumentiert, aber geschäftskritisch. |
Diese Logik verhindert, Joomla zu überschätzen. Joomla kann sehr leistungsfähig sein, wenn das Unternehmen CMS-Flexibilität benötigt. Dieselbe Flexibilität erhöht jedoch die Planungs- und Betriebsverantwortung.
Profile mit starker Eignung
Joomla passt häufig gut zu Händlern und Organisationen, die strukturierte Inhalte, kontrollierten Zugriff, Mehrsprachigkeit oder eine durch Erweiterungen geprägte Website benötigen. Solche Unternehmen verstehen üblicherweise, dass Joomla keine native Commerce-Plattform ist, und sind bereit festzulegen, welche Erweiterung oder individuelle Komponente das Shop-Verhalten übernimmt.
Zu typischen starken Profilen gehören inhaltsreiche Unternehmen, Verbände, Bildungseinrichtungen, Mitgliederportale, gemeinnützige Organisationen, Dienstleister, mehrsprachige Marken oder Händler, die bereits mit Joomla-Spezialisten arbeiten. Auch ein Commerce-Projekt kann gut passen, wenn der Shop Teil einer umfassenderen Joomla-Website ist und nicht das gesamte Betriebsmodell darstellt.
| Starkes Profil | Warum Joomla passt |
|---|---|
| Inhaltsorientierte Organisation | Joomla kann strukturierte Artikel, Kategorien, Menüs, Module, Metadaten und Zugriffsregeln verwalten. |
| Mitglieder- oder geschützte Website | Benutzer, Gruppen und Zugriffsebenen können zentral für die Zielumgebung sein. |
| Mehrsprachige Website | Sprachzuordnungen, sprachspezifische Menüs und übersetzte Inhalte können als Teil der Zielstruktur geplant werden. |
| Von einer Agentur betreutes Joomla-Projekt | Technische Verantwortung ist realistischer, wenn Joomla-Kompetenz auch nach dem Launch verfügbar bleibt. |
| Commerce innerhalb einer umfassenderen Website | Shop-Datensätze können einer Commerce-Erweiterung gehören, während Joomla Inhalte und Website-Architektur besitzt. |
| Erweiterungsgetriebener Betrieb | Joomla passt, wenn der Händler bewusst von Komponenten, Modulen, Plugins oder individuellen Implementierungen abhängt. |
Eine starke Eignung bedeutet nicht, dass die Migration automatisch ist. Sie bedeutet, dass die Plattformentscheidung zum künftigen Betriebsmodell passt. Menüs, URLs, Benutzer, Zugriffsebenen, mehrsprachige Beziehungen, Erweiterungsdaten und Inhaltsdarstellung benötigen weiterhin belastbare Nachweise.
Profile mit bedingter Eignung
Viele Händler können Joomla erfolgreich einsetzen, allerdings nur, wenn Umfang und Zuständigkeiten früh geklärt werden. Bedingte Eignung liegt häufig vor, wenn die Flexibilität von Joomla attraktiv ist, Commerce-Komponente, Erweiterungsanforderungen, Template-Abhängigkeiten oder Support-Verantwortung aber noch nicht definiert sind.
Ein bedingt passendes Projekt kann gute Gründe für Joomla haben und gleichzeitig offene Risiken besitzen: unbekannte Alt-Erweiterungen, individuelle Datenbanktabellen, veraltete Templates, nicht unterstützte Module, komplexe Benutzergruppen, mehrsprachige Inhalte oder SEO-kritische Menürouten. Diese Faktoren schließen Joomla nicht aus, verändern aber Migrationsansatz und Validierungsaufwand.
| Bedingtes Signal | Was geklärt werden muss |
|---|---|
| Commerce-Erweiterung ist noch nicht entschieden | Welche Komponente Products, Customers, Orders, Checkout, Versand, Zahlung, Rabatte und Bestand besitzen wird. |
| Viele Erweiterungen beeinflussen die Website | Welche Datensätze unterstützt, nicht unterstützt, individuell oder reine Zielkonfiguration sind. |
| Benutzerdefinierte Felder oder Tabellen sind wichtig | Ob die Daten in unterstützten Umfang, Zielkonfiguration, individuelle Datenprüfung oder separate Implementierungsarbeit fallen. |
| Menüs und Aliase treiben Traffic | Welche URLs, Weiterleitungen, Metadaten und Navigationspfade erhalten bleiben müssen. |
| Benutzergruppen steuern geschäftlichen Zugriff | Ob das Ziel Zugriffskontrolle, Mitgliedschaftsverhalten, Commerce-Customers oder mehrere Ebenen gleichzeitig benötigt. |
| Joomla-Version oder Template-Pfad ist unsicher | Ob Erweiterungskompatibilität und Frontend-Ausgabe Einrichtung oder Neuaufbau erfordern. |
Bedingte Eignung wird zu starker Eignung, sobald der Händler die zukünftige Joomla-Umgebung klar definieren kann. Sie wird schwächer, wenn Flexibilität gewünscht ist, aber Einrichtung, Erweiterungsentscheidungen und Validierungsverantwortung nicht übernommen werden können.
Schwächere oder weniger geeignete Profile
Joomla ist häufig weniger geeignet, wenn ein Händler ein natives E-Commerce-Betriebsmodell erwartet, aber keine Joomla-spezifische Verantwortung übernehmen möchte. Wer eine vollständig gehostete Commerce-Plattform, eingebaute Shop-Abläufe, native Product- und Order-Strukturen, einfache App-Verwaltung oder geringe technische Administration bevorzugt, ist möglicherweise mit einer SaaS-Commerce-Plattform oder einem spezifischen unterstützten Shop-System besser bedient.
Joomla kann auch dann weniger geeignet sein, wenn der Quellshop geschäftskritische individuelle Erweiterungsdaten enthält, aber Dokumentation, Entwicklerunterstützung und eindeutige Zielverantwortung fehlen. Eine Migration kann trotzdem möglich sein, doch die Plattformentscheidung ist erst belastbar, wenn die Last durch individuelle Daten verstanden ist.
| Weniger geeignetes Muster | Warum es Risiko erzeugt |
|---|---|
| Joomla Core soll wie ein vollständiger Shop funktionieren | Products, Orders, Checkout, Versand, Zahlung und Customer-Verhalten benötigen eine Commerce-Erweiterung oder individuelle Implementierung. |
| Nach dem Launch gibt es keinen Joomla-Verantwortlichen | Erweiterungsupdates, Template-Verhalten, Zugriffsregeln und Website-Wartung können zu Betriebsrisiken werden. |
| Umfangreiche individuelle Komponenten sind undokumentiert | Umfang, Datenzuständigkeit und Validierungsnachweis lassen sich ohne individuelle Datenprüfung möglicherweise nicht bestätigen. |
| Source-Datensätze sind überwiegend shopspezifisch und nicht inhaltsorientiert | Eine native Commerce-Zielplattform kann ein klareres Betriebsmodell bieten. |
| Benutzerkonten sollen automatisch zu Customers werden | Joomla-Benutzeridentität und Commerce-Customer-Identität stimmen möglicherweise nicht überein. |
| Kontinuität der Shop-Oberfläche hängt von alten Template-Overrides ab | Layout und Ausgabe müssen möglicherweise neu aufgebaut statt gewöhnlich migriert werden. |
Eine schwächere Eignung sollte nicht dadurch gelöst werden, Joomla in den Plan zu zwingen. Besser ist zu klären, ob das Unternehmen Joomla wirklich als CMS-Architektur wählt oder ob eine andere Plattform den Commerce-Betrieb besitzen sollte.
Erwartungen der Quellplattform, die sich nicht sauber übertragen lassen
Eine der wichtigsten Eignungsfragen ist, ob Joomla Core oder eine Joomla-Commerce-Erweiterung das Zentrum der Planung sein sollte. Geht es um Inhaltsstruktur, Benutzer, Zugriff, Menüs, Seiten und Website-Architektur, sollte Joomla Core die Planung führen. Geht es um Products, Customers, Orders, Coupons, Bewertungen, Versand, Zahlung, Bestand oder Checkout-Verhalten, sollte die ausgewählte Commerce-Erweiterung die Planung führen.
| Zielerwartung | Besseres Planungszentrum |
|---|---|
| Artikel, Menüs, Kategorien, Module, Templates, Benutzer, ACL und mehrsprachige Inhalte | Joomla-Core-Planung. |
| Products, Product-Kategorien, Customers, Orders, Coupons, Checkout, Versand, Zahlung und Bestand | Commerce-Erweiterung oder individuelle Komponente. |
| Inhaltsseiten, die Kaufentscheidungen unterstützen | Joomla-Planung, ergänzt um Prüfung der Verknüpfungen zur Commerce-Erweiterung. |
| Shop-Seiten, die durch eine Erweiterung erzeugt werden | Erweiterungsplanung, ergänzt um Joomla-Menü- und Routing-Prüfung. |
| Individuelle Datensätze oder Datenbanktabellen | Individuelle Datenprüfung, wenn geschäftskritische Daten erhalten werden müssen. |
Diese Trennung verhindert falsche Support-Erwartungen. Ein Händler darf nicht annehmen, jeder Shop-Datensatz werde von Joomla Core verwaltet, nur weil die Zielwebsite auf Joomla basiert.
Die Eignung hängt außerdem von der Quellplattform ab. Ein Händler, der Shopify, BigCommerce, Magento, WooCommerce, OpenCart, PrestaShop, eine Joomla-Commerce-Erweiterung oder einen individuellen Shop verlässt, bringt möglicherweise Annahmen mit, die nicht direkt nach Joomla übertragbar sind. Eine Quellplattform-Kategorie entspricht nicht automatisch einem Joomla-Menüeintrag. Ein Customer-Konto entspricht nicht zwingend einem Joomla-Benutzer. Eine Product-Seite kann eine Commerce-Erweiterung statt eines Artikels benötigen.
| Annahme aus der Quellplattform | Joomla-Frage |
|---|---|
| Product-Seiten können zu normalen Joomla Articles werden | Geht es wirklich um Inhaltsmigration, oder sollten Products einer Commerce-Erweiterung gehören? |
| Customer-Konten können zu Joomla-Benutzern werden | Sind die Datensätze für Login/Zugriff, Commerce-Customers oder beides bestimmt? |
| Kategorie-URLs können direkt kopiert werden | Werden URLs durch Joomla-Menüs, Aliase, Erweiterungsrouting oder Weiterleitungen bestimmt? |
| App-, Plugin-, Modul- oder Erweiterungsdaten sind Teil der normalen Migration | Sind die Daten unterstützt, erweiterungseigen, individuell oder außerhalb des Umfangs? |
| Theme-Ausgabe wird mit den Inhalten migriert | Benötigt das Ziel Template-Einrichtung, Modulzuweisung oder Layout-Neuaufbau? |
| Mehrsprachigkeit ist lediglich übersetzter Text | Gehören Sprachzuordnungen, Menüeinträge und Erweiterungsdatensätze zur Zielerwartung? |
Eine belastbare Eignungsprüfung macht diese Annahmen sichtbar, bevor der Projektumfang bestätigt wird. Es ist besser, früh zu erkennen, dass das Projekt primär eine Commerce-Erweiterungsmigration ist, als Joomla Core zum Besitzer von Commerce-Daten zu machen, die es nativ nicht verwaltet.
Signale, die vor der Wahl von Joomla bestätigt werden sollten
Joomla sollte anhand praktischer Signale bewertet werden, nicht nur anhand der Vertrautheit mit dem CMS. Das Projekt ist belastbarer, wenn der Händler benennen kann, wer Joomla wartet, welche Commerce-Erweiterung oder individuelle Komponente das Shop-Verhalten besitzt, welche Menüs und URLs wichtig sind, welche Zugriffsregeln fortbestehen müssen und welche Erweiterungen geschäftskritisch statt dekorativ sind.
| Zu bestätigendes Signal | Warum es für die Migration wichtig ist |
|---|---|
| Nach dem Launch gibt es einen klaren Joomla-Verantwortlichen. | Jemand muss Erweiterungen, Templates, Updates, Zugriffsregeln und Website-Konfiguration pflegen. |
| Commerce-Verantwortung ist benannt. | Products, Customers, Orders, Checkout, Zahlung, Versand, Rabatte und Bestand brauchen bei Commerce-Umfang einen definierten Besitzer außerhalb von Joomla Core. |
| Menü- und URL-Prioritäten sind bekannt. | Joomla-Routing, Aliase, versteckte Menüs, Weiterleitungen und Metadaten können SEO und Besucherzugriff beeinflussen. |
| Zugriffsregeln sind dokumentiert. | Benutzergruppen, Berechtigungen, Mitgliedschaften und geschützte Seiten benötigen Validierung über die reine Datensatzübertragung hinaus. |
| Erweiterungen sind inventarisiert. | Core-Datensätze, erweiterungseigene Daten, Zielkonfiguration, separate Implementierung und akzeptierte Ausschlüsse können unterschieden werden. |
| Repräsentative Beispiele enthalten echte Beziehungen. | Die Eignung ist belastbarer, wenn Beispiele Inhalte, Menüs, Benutzer, Zugriff, Mehrsprachigkeit und Erweiterungsdatensätze im Zusammenhang beweisen. |
Fehlen diese Signale, kann Joomla trotzdem nutzbar sein, die Migrationsentscheidung ist aber unvollständig. Der sicherere nächste Schritt ist, Zuständigkeiten und repräsentative Validierungsfälle zu klären, bevor Joomla als bestätigtes Ziel behandelt wird.
Joomla Core und Commerce-Erweiterung getrennt bewerten
Joomla kann die richtige Website-Plattform sein, während eine bestimmte Commerce-Erweiterung dennoch die falsche operative Wahl ist. Beide Entscheidungen hängen zusammen, sind aber nicht austauschbar.
Joomla Core verwaltet die CMS-Umgebung: Artikel, Kategorien, Menüs, Module, Templates, Benutzer, Zugriffsebenen, Sprachzuordnungen, Aliase und das Laden von Erweiterungen. Eine Commerce-Erweiterung oder individuelle Komponente verwaltet shopspezifische Datensätze und Abläufe wie Products, Customers, Orders, Checkout, Versand, Zahlung, Bestand, Rabatte und Reviews. Die Eignung wird unzuverlässig, sobald diese Verantwortungsebenen zu einer einzigen Annahme verschmelzen.
| Entscheidung | Benötigter Nachweis |
|---|---|
| Joomla ist die richtige CMS-Grundlage | Das Unternehmen benötigt CMS-Flexibilität, Mehrsprachigkeit, Zugriffskontrolle, menübasierte Navigation oder erweiterungsbasierte Website-Komposition. |
| Die Commerce-Erweiterung ist die richtige Shop-Grundlage | Ihre Product-, Customer-, Order-, Preis-, Checkout-, Zahlungs-, Versand- und Bestandsstrukturen passen zum vorgesehenen Geschäftsbetrieb. |
| Die kombinierte Architektur ist betreibbar | Ein benannter Verantwortlicher kann Joomla, Commerce-Erweiterung, Templates, Plugins, Hosting, Backups und Kompatibilität pflegen. |
| Die Migrationsgrenze ist verständlich | Core-CMS-Datensätze, Commerce-Datensätze, erweiterungseigene Daten, individuelle Tabellen und Zielimplementierung sind getrennt klassifiziert. |
Diese Trennung ist besonders wichtig beim Wechsel von einer nativen Commerce-Plattform. Ein Quellshop kann Products, Inhalte, Konten und Navigation als integrierte Umgebung darstellen. In Joomla können diese Bereiche auf Core-CMS-Strukturen und eine oder mehrere Erweiterungen verteilt sein. Die Plattform kann weiterhin gut passen, aber nur, wenn das künftige Zuständigkeitsmodell ausdrücklich festgelegt ist.
Entscheidungstore vor der Wahl von Joomla
Ein Joomla-Ziel sollte fünf Entscheidungstore passieren, bevor sich der Händler auf die Plattform festlegt.
1. CMS-Zweck
Das Unternehmen sollte erklären können, warum Joomla benötigt wird. Starke Gründe sind strukturierte Veröffentlichung, mehrsprachige Website-Verwaltung, zugriffsgesteuerte Inhalte, erweiterungsbasierte Funktionalität, komplexe Navigation oder eine umfassendere Website, in der Commerce nur ein Betriebsbereich ist. Die bloße Anpassbarkeit reicht nicht aus; die Anpassung muss einem definierten Geschäftszweck dienen.
2. Commerce-Verantwortung
Wenn das Ziel Commerce umfasst, muss die konkrete Erweiterung oder individuelle Komponente benannt sein. Ihre unterstützten Datenstrukturen und Abläufe sind unabhängig zu bewerten. Eine Joomla-Eignungsentscheidung ist unvollständig, wenn Products und Orders erwartet werden, aber kein künftiger Commerce-Besitzer gewählt wurde.
3. Wartungsfähigkeit
Eine gut geeignete Organisation hat ein verantwortliches internes Team, eine Agentur oder einen Entwickler. Dieser Verantwortliche versteht Hosting, Updates, Erweiterungskompatibilität, Templates, Zugriffskontrolle, Sicherheitspraktiken, Backups und Wiederherstellung. Joomla passt schlechter, wenn diese Verantwortlichkeiten nach der Migration vermeintlich verschwinden sollen.
4. Datenverantwortung
Repräsentative Datensätze sollten nach Besitzer klassifiziert werden: Joomla Core, Commerce-Erweiterung, andere Erweiterung, individuelle Tabelle oder externes System. Diese Zuordnung zeigt, ob die Zielarchitektur die benötigte geschäftliche Bedeutung tragen kann. Sie verhindert auch, dass benutzerdefinierte Felder oder Plugin-Daten als gewöhnlicher Joomla-Inhalt behandelt werden, nur weil sie in derselben Datenbank liegen.
5. Kontinuität der Benutzererfahrung
Der Händler sollte Menüs, Aliase, Sprachrouten, zugriffsgeschützte Pfade, Inhaltsbeziehungen, Shop-Seiten und URLs identifizieren, die nach dem Launch wichtig sind. Joomla passt besser, wenn diese Anforderungen bewusst rekonstruiert werden können. Es passt schlechter, wenn Source-Routing und Template-Ausgabe ohne Zielgestaltung und Konfiguration übernommen werden sollen.
| Ergebnis der Eignungsprüfung | Interpretation |
|---|---|
| Starke Eignung | Joomla hat einen klaren CMS-Zweck, Commerce-Verantwortung ist definiert, Wartungsfähigkeit besteht und repräsentative Datensätze besitzen klare Ziele. |
| Bedingte Eignung | Joomla ist strategisch geeignet, aber Commerce-Verantwortung, Erweiterungskompatibilität, individuelle Daten oder Implementierungsverantwortung benötigen noch Nachweise. |
| Schwächere Eignung | Das Unternehmen möchte hauptsächlich einen wartungsarmen gehosteten Shop, besitzt keine Joomla-Verantwortung oder kann nicht definieren, wo geschäftskritisches Commerce-Verhalten leben wird. |
Die Eignungsentscheidung sollte an dieser Grenze enden. Ihr Zweck ist zu bestätigen, ob Joomla und die gewählte Commerce-Erweiterung zum künftigen Betriebsmodell passen, nicht Zuordnung, Implementierung oder Launch-Validierung vollständig zu lösen.
Fazit
Joomla ist eine starke Zielplattform, wenn der Händler eine CMS-zentrierte, erweiterungsbewusste, inhaltsreiche, zugriffsgesteuerte, mehrsprachige oder entwicklerbetreute Website-Umgebung möchte. Es ist weniger geeignet, wenn Joomla Core ein vollständiges natives Shop-Modell bereitstellen soll oder ein gehosteter Commerce-Ablauf ohne Joomla-Verantwortung erwartet wird.
Eine gute Joomla-Eignungsentscheidung beginnt damit, festzulegen, was Joomla besitzen soll. Geht es um Inhalte, Benutzer, Zugriff, Menüs und Website-Architektur, kann Joomla das richtige Ziel sein. Geht es um Commerce-Datensätze, sollte die gewählte E-Commerce-Erweiterung die Planung dieser Datensätze führen. Hängt das Projekt von undokumentierten individuellen Komponenten, nicht unterstützten Erweiterungsdaten oder maßgeschneidertem Verhalten ab, muss der Umfang geklärt werden, bevor Joomla als migrationsbereit gilt.
Häufige Fragen
Ist Joomla für jede E-Commerce-Migration geeignet?
Nein. Joomla kann E-Commerce über Erweiterungen oder individuelle Komponenten unterstützen, ist aber selbst keine native Shop-Plattform. Besonders geeignet ist es, wenn der Händler Joomla-Funktionen für CMS, Zugriffskontrolle, Mehrsprachigkeit und Erweiterungen als Teil der Zielumgebung benötigt.
Wann sollte eine Joomla-Commerce-Erweiterung die Migrationsplanung bestimmen?
Wenn die Zielmigration primär erweiterungseigene Shop-Datensätze wie Products, Customers, Orders, Coupons, Reviews, Zahlung, Versand, Bestand, Checkout oder erweiterungsspezifisches Katalogverhalten betrifft.
Welche Händlerprofile passen typischerweise gut zu Joomla?
Dazu gehören inhaltsorientierte Organisationen, mehrsprachige Websites, Mitglieder- oder zugriffsgesteuerte Websites, Joomla-erfahrene Teams, agenturbetreute Projekte und Händler, die Commerce-Funktionen innerhalb einer umfassenderen Joomla-Website einsetzen.
Was macht Joomla zu einer schwächeren Wahl?
Joomla passt schwächer, wenn ein einfacher gehosteter Shop-Oberfläche gewünscht wird, natives Shop-Verhalten von Joomla Core erwartet wird, niemand Joomla betreuen kann oder geschäftskritische individuelle Erweiterungen und Daten ohne klaren Zielplan bestehen.
Kann Zielkonfiguration jede Joomla-Komplexität lösen?
Nein. Zielkonfiguration kann bei unterstützter Filterung, Zuordnung oder Konfiguration helfen. Nicht unterstützte Erweiterungsdatensätze, individuelle Komponenten, individuelle Tabellen, maßgeschneiderte Transformationen und Änderungen an individueller Migrationslogik erfordern eine separate Prüfung oder Implementierung.
Kann Joomla gewählt werden, bevor die Commerce-Erweiterung feststeht?
Joomla kann als CMS-Grundlage gewählt werden. Eine Commerce-Migrationsentscheidung bleibt jedoch unvollständig, bis die Erweiterung oder individuelle Komponente, die Products, Customers, Orders, Checkout, Zahlung, Versand und Bestand besitzen wird, definiert und bewertet wurde.