Wenn J2Commerce als mögliche Zielplattform in Betracht gezogen wird, beschreibt die Vorbereitung, welche Nachweise, Entscheidungen und Zielkonfigurationen vor der Migration geklärt werden müssen.
Wenn J2Commerce als Zielplattform ausgewählt werden soll, muss die Vorbereitung Commerce-Datensätze mit den Joomla-Strukturen verbinden, die diese Daten sichtbar und nutzbar machen. Products können von Joomla-Artikeln, Kategorien, Menüs, Modulen, benutzerdefinierte Felder, Benutzergruppen, Anwendungen, Zahlungs- und Versanderweiterungen sowie Template-Layouts abhängen. Spezialisierte Product-Typen können Varianten, Downloads, Abonnements, Buchungen, Bundles, Anzahlungen oder vom Customer eingegebene Daten hinzufügen, deren Bedeutung aus einer reinen Product-Anzahl nicht hervorgeht.
Das Vorbereitungspaket sollte vor Beginn der Migration für jede Aufgabe Verantwortlichen, Nachweis und Bedingung für die Freigabereife festlegen. Gleichzeitig muss es Datensätze im Migrationsumfang von laufender Checkout-, Steuer-, Zahlungs-, Versand-, Benachrichtigungs-, Cron- und Erweiterungskonfiguration trennen, die zur Zielimplementierung gehört.
Die Vorbereitung sollte eine repräsentative J2Commerce-Stichprobe hervorbringen, mögliche Anforderungen an Zuordnungen oder individuell angepasste Behandlung sichtbar machen und den eigentlichen Migrationsumfang von Joomla- und J2Commerce-Implementierung abgrenzen, bevor eine breitere Ausführung beginnt.
Zugriff auf Joomla, J2Commerce, Hosting und Datenbank absichern
Bestätigen Sie den Zugriff auf Joomla-Administration, J2Commerce-Administration, Hosting, Datenbank, Dateisystem, Medien, geplante Tasks und externe Services. Dokumentieren Sie Joomla-Version, J2Commerce-Version, PHP- und Datenbankversion, aktives Template, aktivierte Sprachen, installierte Anwendungen, Zahlungs- und Versanderweiterungen sowie individuellen Code.
| Vorbereitungsaufgabe | Verantwortlicher | Nachweis | Bedingung für die Freigabereife |
|---|---|---|---|
| Administrativen Zugriff bestätigen | Joomla-/J2Commerce-Administrator | Funktionierende Konten und Rollenübersicht | Katalog, Orders, Customers, Anwendungen, Menüs und Konfiguration können geprüft werden. |
| Wiederherstellbare Backups erstellen | Infrastrukturverantwortlicher | Datenbankexport, Dateisystemarchiv, Hinweise zu externen Medien und benannter Restore-Verantwortlicher | Die Quelle kann wiederhergestellt werden, ohne vom Live-Shop abhängig zu sein. |
| Erweiterungsumgebung erfassen | Technischer Verantwortlicher | Inventar aus Komponenten, Plugins, Modulen, Templates und Anwendungen mit Versionen | Jede Commerce-Abhängigkeit ist erfasst und hat einen Verantwortlichen. |
| Geplante und externe Prozesse dokumentieren | Integrationsverantwortlicher | Cronjobs, Webhook-Endpunkte, ERP-/PIM-/WMS-/CRM-/Payment-/Shipping-Anbindungen und externe IDs | Weiterbestehende Integrationen und Datenhoheiten sind identifiziert. |
| Quellidentifikatoren bewahren | Migrationskoordinator | Product-, Artikel-, Kategorie-, Benutzer-, Customer-, Order-, Options-, Varianten-, Subscription- und externe IDs | Beziehungen zwischen Datensätzen bleiben nach der Extraktion nachvollziehbar. |
Wenn der Shop aus J2Store hervorgegangen ist oder einen größeren Versionswechsel durchlaufen hat, sollte diese Linie dokumentiert werden. Ähnliche Bezeichnungen können auf unterschiedliche Tabellen oder Anwendungsversionen verweisen, und ältere Anpassungen können weiterhin von Legacy-Feldern abhängen.
Products nach Verkaufsverhalten vorbereiten
J2Commerce-Products sollten nicht nur nach Name oder Anzahl klassifiziert werden. Entscheidend ist das Verhalten, das verständlich bleiben muss: einfacher Verkauf, Variantenverkauf, Download, Abonnement, Buchung, Bundle, Service, Anzahlung, personalisiertes Product oder ein von einer Anwendung gesteuerter Product-Typ.
| Product-Muster | Erforderlicher Nachweis | Bedingung für die Freigabereife |
|---|---|---|
| Einfaches physisches Product | Artikel-/Product-ID, SKU, Preis, Steuerprofil, Bestand, Gewicht, Bilder, Kategoriebeziehungen und Beispiel-Order | Ein Datensatz identifiziert das verkaufbare Angebot und seine Joomla-Inhaltsbeziehung eindeutig. |
| Varianten-Product | Optionsdefinitionen, Werte, erzeugte Varianten, SKU/Preis/Bestand/Bild je Variante und Parent-Product-ID | Jede verkaufbare Kombination ist auf Parent und ausgewählte Werte zurückführbar. |
| Download-Product | Dateidatensätze, Zugriffsregeln, Limits, Ablauf, Product-Verknüpfung und Beispiel einer abgeschlossenen Order | Datei-Verantwortung und Order-basierter Zugriff sind vollständig dokumentiert. |
| Subscription-Product | Product-Typ, Plan/Variante, Abrechnungsintervall, Testphase, Status, Zahlungsabhängigkeit, Cron-Abhängigkeit, Joomla-Benutzergruppenbeziehung und Beispiel-Subscription | Wiederkehrender Zustand und Zugriffsbeziehungen haben einen benannten Verantwortlichen und eine Zielentscheidung. |
| Buchungs- oder Reservierungs-Product | Ressource, Datum-/Zeitregeln, Kapazität, Preislogik, Customer-Eingaben und Beispielbuchung | Verfügbarkeitsdatensätze und Buchungshistorie sind von normalen Product-Feldern getrennt. |
| Bundle oder gruppiertes Product | Parent-Product, Component-Products, Mengen, Preislogik, Bestandsbeziehung und Beispiel-Order | Komponentenidentität und Verantwortlichkeit sind dokumentiert. |
| Personalisiertes Product | Eingabefelddefinitionen, Optionslogik, vom Käufer bereitgestellte Dateien, Preiseffekte und Beispiel-Order-Line | Käuferdaten bleiben klar von wiederverwendbaren Product-Attributen getrennt. |
Für jeden Product-Typ sollte dokumentiert werden, welche Werte Identität, Preis, Bestand, Steuer, Gewicht, Versand, Zugriff, Verlängerung oder Auftragsabwicklung steuern. Wenn eine Anwendung oder ein individuelles Plugin einen Teil des Verhaltens besitzt, müssen Tabellen, Schlüssel und Konfigurationsabhängigkeit Teil des Nachweispakets sein.
Optionen, Varianten, benutzerdefinierte Felder und Artikelbeziehungen vorbereiten
J2Commerce-Products können mit Joomla-Artikelinhalten sowie J2Commerce-Options- und Variantenstrukturen verbunden sein. Die Vorbereitung muss gemeinsame Product-Inhalte, Daten verkaufbarer Kombinationen und vom Customer eingegebene Werte unterscheiden.
| Beziehung | Nachweis | Bedingung für die Freigabereife |
|---|---|---|
| Joomla-Artikel zu Product | Artikel-ID, Product-ID, Aliase, Sprache, Zugriffsebene und Inhaltsfelder | Product-Inhalt wird nicht versehentlich vom Product-Datensatz getrennt. |
| Product-Option | Optionsname, Typ, Werte, Sortierung, Preiseffekt und Product-Zuweisung | Wiederverwendbare Auswahldefinitionen sind dokumentiert. |
| Variante | Parent-Product, ausgewählte Optionswerte, SKU, Bestand, Preis, Bild, Status und externe ID | Jede reale verkaufbare Einheit besitzt einen eindeutigen, nachvollziehbaren Datensatz. |
| Benutzerdefiniertes Feld | Felddefinition, Kontext, Werte, Geschäftszweck und verwendendes Layout bzw. Anwendung | Beschreibende Daten werden nicht mit Käuferauswahl oder Anwendungszustand verwechselt. |
| Customer-Eingabe | Eingabedefinition und Beispielwert aus einer Order Line | Einmalige Käuferangaben bleiben am Kaufkontext. |
Offensichtliche doppelte Optionsbezeichnungen sollten erst normalisiert werden, nachdem ursprüngliches Vokabular und Beziehungen gesichert sind. Wenn „Colour“, „Color“ und „Finish“ in der Quelle unterschiedliche geschäftliche Bedeutungen besitzen, dürfen sie nicht allein wegen sprachlicher Ähnlichkeit zusammengeführt werden.
Kategorien, Menüs, URLs, Medien und Storefront-Auffindbarkeit vorbereiten
Die Katalogauffindbarkeit in J2Commerce kann von Joomla-Kategorien, Artikelsortierung, Menüeinträgen, Modulen, Filtern, Suche, Template-Layouts und Product-Medien abhängen. Ein Product kann in der Administration vollständig sein und dennoch über die beabsichtigte Route nicht erreichbar sein.
Bereiten Sie eine Product-zu-Kategorie-Zuordnung, Kategoriehierarchie, Nachweise der Artikelsortierung, ein Menüinventar, Modulzuweisungen, Filterwerte, priorisierte URLs, Redirects, Bildreferenzen und Sprachzuweisungen vor. Berücksichtigen Sie Routen für Product-Seiten, Kategorieansichten, Kontoseiten, Downloads, Subscription-Verwaltung, Cart, Checkout und wichtige Kampagnenseiten.
| Bereich der Auffindbarkeit | Vorbereitungsnachweis | Bedingung für die Freigabereife |
|---|---|---|
| Kategoriezugehörigkeit | Product-/Artikel-IDs und Kategoriehierarchie | Products im Migrationsumfang besitzen eine bewusste Platzierung in der Auffindbarkeit. |
| Menü-Routing | Menütyp, Parent, Alias, Sprache, Zugriffsebene und Ziel | Priorisierte Storefront-Pfade haben explizite Zielrouten. |
| Module und Filter | Modulposition, Menüzuweisung, Filterquelle und besitzende Erweiterung | Auffindbarkeitslogik ist von Product-Daten getrennt. |
| Product-Medien | Dateipfade, primäre/zusätzliche/variantenbezogene Bilder, Alt-Texte und Hinweise auf externen Speicher | Medienbeziehungen sind auf das richtige Product oder die richtige Variante zurückführbar. |
| Redirects und Metadaten | Quell-URL, Zielabsicht, Metadaten, Canonical-Hinweise und Nachweise von Routing-Erweiterungen | Hochwertige Pfade besitzen genau eine beabsichtigte Behandlung. |
Es sollte nicht angenommen werden, dass die Migration von Products automatisch Joomla-Menüs, Modulpositionen, Template-Ansichten oder Such- und Filterlogik rekonstruiert. Diese Bereiche gehören zur Zielimplementierung, doch ihre Quellbeziehungen müssen dokumentiert sein.
Customers, Joomla-Benutzer, Gruppen und Adressen vorbereiten
Customer-Identität in J2Commerce kann Joomla-Benutzer, Gastkäufer, Adressdatensätze, Customer-Gruppen, Unternehmensfelder, Steuerkennungen, Mitgliedschaftsbeziehungen und externe CRM- oder ERP-Schlüssel umfassen. Diese Elemente sollten getrennt vorbereitet werden.
| Kontothema | Nachweis | Bedingung für die Freigabereife |
|---|---|---|
| Registrierter Customer | Joomla-Benutzer-ID, Customer-ID, E-Mail, Status, Gruppen, Adressen und externe IDs | Duplikate und Mehrfachgruppenfälle besitzen eine definierte Behandlung. |
| Gast-Customer | Order-bezogene Identität und Adressen | Gasthistorie wird nicht in künstlich erzeugte Benutzerkonten gezwungen. |
| Customer-Gruppe | Gruppendefinition und zugehörige Preis-, Steuer-, Zugriffs- oder Rabattlogik | Gruppenbedeutung ist über die bloße Bezeichnung hinaus dokumentiert. |
| Unternehmens- oder Steueridentität | Firmenfelder, Steuerkennungen, Validierungsstatus und externe Kontoreferenz | Geschäftskontodaten haben einen benannten Zielverantwortlichen. |
| Authentifizierung | Lokales Passwort, SSO, Social Login, MFA, Reset-Ablauf und Kommunikationsverantwortlicher | Kontozugriff ist geplant, ohne Passwortportabilität vorauszusetzen. |
Wenn eine Subscription- oder Membership-Anwendung nach dem Kauf Joomla-Benutzergruppen verändert, müssen auslösender Status, Product-Verknüpfung, Zielgruppe, Subscription-Status und relevante Beispiel-Orders dokumentiert werden. Die Gruppenzuweisung ist dann eine Anwendungsbeziehung und nicht nur Customer-Metadatum.
Orders, Zahlungen, Versand, Steuern und After-Sale-Historie vorbereiten
Historische Orders sollten erklären können, was gekauft wurde und was anschließend geschah. Bereiten Sie Order-Header, Order Lines, Product-/Variantenreferenzen, ausgewählte Optionen, vom Customer eingegebene Werte, Adressen, Preise, Rabatte, Steuern, Zahlungs- und Versandbezeichnungen, Status, Kommentare, Transaktionen, Rechnungen, Erstattungen, Downloads, Subscriptions und gegebenenfalls Buchungsreferenzen vor.
| Order-Nachweis | Verantwortlicher | Bedingung für die Freigabereife |
|---|---|---|
| Order-Header und Statushistorie | Commerce Operations | Statussequenz und Zeitstempel sind verständlich. |
| Order Lines | Katalog und Operations | Product, Variante, SKU, ausgewählte Werte, Menge und Preis sind als historische Snapshots erhalten. |
| Zahlungsnachweis | Finance oder Zahlungsverantwortlicher | Methodenbezeichnung und Transaktionsreferenz sind dokumentiert, ohne Zugangsdaten als Migrationsdaten zu behandeln. |
| Versandnachweis | Verantwortlicher für Auftragsabwicklung | Methodenbezeichnung, Kosten, Tracking und Versandkontext sind vorhanden, wo sie genutzt wurden. |
| Steuer- und Rabattnachweis | Finance oder Commerce-Verantwortlicher | Angewandte Beträge und Bezeichnungen können mit den Summen abgeglichen werden. |
| After-Sale-Datensätze | Customer-Service-Verantwortlicher | Erstattungen, Downloads, Subscription-Änderungen, Stornierungen oder Buchungsstatus sind mit der Order verbunden. |
Erstellen Sie ein Statusglossar, das erklärt, was jeder Quellstatus für Order, Zahlung, Versand, Subscription und Buchung operativ bedeutet. Ähnliche Bezeichnungen können je nach Erweiterung unterschiedliche Zustände ausdrücken.
Anwendungen, Plugins, individuelle Tabellen und Integrationen inventarisieren
J2Commerce-Anwendungen und Joomla-Erweiterungen können Subscriptions, Buchungen, Bundles, Anzahlungen, Versand, Zahlung, Rabatte, Bestandssynchronisierung, Product-Feeds, Rechnungen, Loyalty, Reviews und individuelle Checkout-Daten besitzen. Das Vorbereitungspaket muss für jeden Datensatz den tatsächlichen Verantwortlichen bestimmen.
Dokumentieren Sie für jede wichtige Erweiterung Name, Version, Tabellen, Felder, Primärschlüssel, Fremdschlüssel, Product-/Customer-/Order-Referenzen, Konfigurationsabhängigkeiten, geplante Tasks, externe Services und aktuellen fachlichen Verantwortlichen. Klassifizieren Sie die Anforderung als nativen Datensatz, erweiterungseigenen Datensatz, externen Systemdatensatz, Zielkonfiguration, Darstellung oder Stilllegungskandidat.
Externe Identifikatoren verdienen besondere Aufmerksamkeit. ERP-Product-IDs, CRM-Customer-IDs, Marketplace-Listing-IDs, Warehouse-Codes, Payment-Transaktions-IDs und Subscription-Gateway-Referenzen können kleine Felder sein, aber geschäftskritische Beziehungsschlüssel darstellen.
Der Ready-Zustand ist erreicht, wenn kein erforderlicher Commerce-Datensatz nur noch als „custom data“ oder „app data“ beschrieben wird. Jeder aktive Datenbestand braucht einen benannten Datensatztyp, Verantwortlichen, Quellnachweis und eine Zielentscheidung.
Migrierte Datensätze von Zielkonfiguration trennen
Aktuelle Steuer-, Zahlungs-, Versand-, E-Mail-, Währungs-, Cron-, Checkout-, Cache-, Template- und Sicherheitsfunktionen gehören zur Zielimplementierung. Historische Datensätze können Bezeichnungen und Beträge erhalten, ohne das heutige Verhalten zu konfigurieren.
| Vorzubereitender Quellnachweis | Getrennte zielseitige Verantwortung |
|---|---|
| Historische Zahlungsbezeichnungen und Transaktions-IDs | Gateway-Konto, Zugangsdaten, Callbacks, Fraud-Einstellungen und Live-Payment-Tests |
| Historische Versandbezeichnungen und Tracking | Carrier-Konten, Tarife, Zonen, Verpackung, Pickup und Konfiguration der Auftragsabwicklung |
| Historische Steuerbeträge und Steuerprofilreferenzen | Aktuelle Steuerregistrierungen, Sätze, Befreiungen und Berechnungseinstellungen |
| Product- und Customer-Gruppenbeziehungen | Aktive Preis-, Zugriffs- und Promotion-Konfiguration |
| Subscription-Historie und Billing-Referenzen | Unterstützung aktueller Gateway-Tokens, Renewal-Jobs, E-Mail und Zugriffsautomatisierung |
| Bestehende URLs und Metadaten | Zielmenüs, Template-Ausgabe, Suche und Redirect-Implementierung |
Die Vorbereitung ist abgeschlossen, wenn Quellnachweise die historische Bedeutung erklären und die Verantwortlichen der Zielimplementierung die laufende Konfiguration übernommen haben. Ein erfolgreicher Export aus der Quelle ist kein Nachweis dafür, dass Checkout oder wiederkehrende Abrechnung eingerichtet sind.
Repräsentative Migrationstestfälle auswählen
Wählen Sie Testfälle, die die schwierigen Beziehungen von J2Commerce sichtbar machen. Dazu gehören:
- ein einfaches Product, das mit einem Joomla-Artikel und einer Kategorie verbunden ist;
- ein Product mit mehreren Optionen, erzeugten Varianten und variantenbezogener SKU oder Bestand;
- ein Download-Product mit Nachweisen für Dateizugriff;
- eine Subscription, Buchung, ein Bundle oder ein anderer spezialisierter Product-Typ, sofern verwendet;
- ein Customer mit mehreren Adressen oder Gruppen;
- eine Gast-Order und eine Order eines registrierten Customers;
- eine Order mit Rabatt-, Steuer-, Versand- und Zahlungsreferenzen;
- ein Product mit benutzerdefinierte Felder, Customer-Eingaben oder erweiterungseigenen Daten;
- eine mehrsprachige oder zugriffsbeschränkte Product-Route;
- ein Product oder eine Order mit externer Kennung.
Für jeden Testfall sollten Quell-IDs, Auswahlgrund, geprüfte Beziehungen, benötigte Interpretationsnachweise und bewusst außerhalb des Migrationsumfangs liegende Zielkonfiguration dokumentiert werden.
Abschließendes Bereitschafts-Gate festlegen
| Bereitschaftsfrage | Bedingung für die Freigabereife |
|---|---|
| Ist die Quelle wiederherstellbar? | Datenbank, Dateisystem, Medien und Erweiterungsnachweise sind gesichert und ein Restore-Verantwortlicher ist benannt. |
| Sind Product-Typen klassifiziert? | Jede Product-Familie im Umfang besitzt Typ, Verkaufsverhalten, Verantwortlichen und repräsentativen Testfall. |
| Sind Joomla-Beziehungen sichtbar? | Artikel, Kategorien, Menüs, Module, Sprachen, Zugriffsebenen und Routen sind für priorisierte Products abgebildet. |
| Sind Customers und Orders interpretierbar? | Benutzerbeziehungen, Gruppen, Adressen, Status, Summen und After-Sale-Datensätze sind dokumentiert. |
| Sind Anwendungen und Custom Data klar zugeordnet? | Jeder aktive Erweiterungsdatenbestand besitzt Schema, Verantwortlichen, Quellschlüssel und Zielentscheidung. |
| Ist Konfiguration getrennt? | Live-Checkout, Steuer, Zahlung, Versand, Cron und Template-Verantwortung haben benannte Zielverantwortliche. |
| Sind die Testfälle ausreichend? | Repräsentative Migrationstestfälle decken Varianten, spezialisierte Products, Customer-/Order-Zustände, URLs und Erweiterungsdaten ab. |
Unklare Backups, nicht klassifizierte Product-Typen, fehlende Variantenidentität, undokumentierte Subscription- oder Buchungsdaten oder Erweiterungstabellen ohne Verantwortlichen sollten den betroffenen Umfang blockieren, bis belastbare Nachweise vorliegen.
Fazit
Die Vorbereitung auf J2Commerce erfordert mehr als einen Product- und Order-Export. Sie muss die Beziehungen zwischen Joomla-Artikeln, Kategorien, Menüs, Benutzern, J2Commerce-Products, Optionen, Varianten, Customers, Orders, spezialisierten Product-Anwendungen, Dateien, Routen und externen Systemen bewahren.
Ein belastbares Vorbereitungspaket weist jede Aufgabe einem Verantwortlichen zu, dokumentiert die benötigten Nachweise für jede Beziehung, trennt laufende Zielkonfiguration von historischen Datensätzen und wählt repräsentative Testfälle, die die tatsächliche Komplexität des Shops vor der Migration sichtbar machen.
Häufige Fragen
Was sollte für eine J2Commerce-Migration zuerst vorbereitet werden?
Sichern Sie den Zugriff auf Joomla, J2Commerce, Hosting, Datenbank, Dateisystem, geplante Tasks und externe Systeme. Erstellen Sie anschließend unveränderliche Backups und ein datiertes Inventar von Umgebung und Erweiterungen, bevor Daten bereinigt oder restrukturiert werden.
Warum sind Joomla-Artikel bei der Vorbereitung wichtig?
J2Commerce-Products können von Joomla-Artikelinhalt, Kategorien, Menüs, Sprache, Zugriffsebenen, Modulen und Routen abhängen. Der Product-Datensatz allein enthält möglicherweise nicht die vollständige Storefront-Identität oder den Discovery-Pfad.
Wie sollten J2Commerce-Varianten vorbereitet werden?
Dokumentieren Sie Parent-Product, Optionsdefinitionen, ausgewählte Werte, Varianten-SKU, Bestand, Preis, Bilder, Status und externe Identifikatoren. Verwenden Sie repräsentative Varianten, die gerade jene Kombinationen sichtbar machen, bei denen Identität während der Migration am ehesten verloren gehen könnte.
Welche Nachweise werden für J2Commerce-Subscriptions oder Buchungen benötigt?
Bereiten Sie Product-Typ, Plan oder Ressource, Zeitpläne, Status, Customer- und Order-Beziehungen, Zahlungsreferenzen, Zugriffsregeln, Abhängigkeiten von geplanten Tasks und repräsentative historische Datensätze vor. Laufende Renewal- oder Verfügbarkeitskonfiguration bleibt eine getrennte Zielverantwortung.
Sollten Zahlungs-, Versand- und Steuereinstellungen als migrierte Datensätze behandelt werden?
Historische Orders sollten Methodenbezeichnungen, Beträge sowie Transaktions- oder Trackingreferenzen bewahren. Live-Gateways, Carrier-Tarife, Zonen, Zugangsdaten und Steuerberechnung gehören zur Zielkonfiguration und benötigen eigene Verantwortliche.
Welche Datensätze eignen sich für repräsentative J2Commerce-Migrationstests?
Wählen Sie einfache und variable Products, spezialisierte Product-Typen, Downloads, komplexe Customers, Gast- und registrierte Orders, Rabatte und Steuern, mehrsprachige oder eingeschränkte Routen, benutzerdefinierte Felder, erweiterungseigene Daten und externe Identifikatoren.