Wenn J2Store als mögliche Zielplattform ausgewählt werden soll, muss die Vorbereitung berücksichtigen, dass Products auf Joomla-Artikeln basieren und über mehrere Produkttypen und Anwendungen erweitert werden können. Ein Product kann von Joomla-Inhalten, Kategorien, Menüs, Modulen, Benutzergruppen, Optionen, Varianten, Downloads, gebündelten Products, Buchungs- oder Abonnementanwendungen, Zahlungs- und Versand-Plugins, Template-Overrides und individuellen Tabellen abhängen.
Ein belastbares Vorbereitungspaket macht jede Abhängigkeit sichtbar, bevor die Migration beginnt. Für jeden wesentlichen Bereich sollten Maßnahme, Verantwortlicher, Nachweis und Freigabekriterium definiert werden. Historische Commerce-Datensätze müssen dabei von der aktiven Zielkonfiguration getrennt bleiben. Da viele J2Store-Installationen seit Jahren betrieben oder stark erweitert wurden, muss das Paket außerdem dokumentieren, wer Wartung, Wiederherstellung und Kompatibilitätsentscheidungen für die Quellumgebung verantwortet.
Zugriff, Wiederherstellung und Lebenszyklusverantwortung der Quelle bestätigen
Beginnen Sie mit funktionierendem Zugriff auf Joomla Administrator und J2Store sowie, soweit erforderlich, auf Hosting, Datenbank, Dateisystem, Medien, geplante Aufgaben und externe Dienste. Halten Sie die Versionen von Joomla, J2Store, PHP, Datenbank, Template und Erweiterungen fest.
| Vorbereitungsmaßnahme | Verantwortlicher | Nachweis | Freigabekriterium |
|---|---|---|---|
| Administrationszugriff bestätigen | Joomla-/J2Store-Administrator | Funktionierende Konten und Rollenübersicht | Products, Customers, Orders, Anwendungen und Joomla-Strukturen können geprüft werden. |
| Wiederherstellbare Backups erstellen | Infrastrukturverantwortlicher | Datenbankexport, Dateisystemarchiv, Medienhinweise und Restore-Verfahren | Die Quelle kann unabhängig vom Live-Shop wiederhergestellt werden. |
| Installierte Umgebung erfassen | Technischer Verantwortlicher | Versionsinventar für Joomla, J2Store, PHP, Datenbank, Template, Plugins, Module und Anwendungen | Der tatsächliche Quell-Stack ist einschließlich veralteter oder individueller Komponenten dokumentiert. |
| Lebenszyklusverantwortung zuweisen | Geschäfts- und technische Verantwortliche | Benannte Zuständigkeit für Hosting, Sicherheit, Kompatibilität, Ersatz von Erweiterungen und Wiederherstellung | Der Migrationsumfang wird nicht als Ersatz für die Wartung der Quell- oder Zielumgebung verwendet. |
| Kennungen bewahren | Migrationskoordinator | Artikel-, Product-, Kategorie-, Options-, Varianten-, Customer-, Benutzer-, Order-, Anwendungs- und externe IDs | Beziehungen zwischen Datensätzen können nach der Extraktion nachvollzogen werden. |
Wird der Shop nicht mehr aktiv gepflegt, sollte dieser Zustand ausdrücklich dokumentiert werden. Vermeiden Sie Bereinigung, Upgrades oder die Entfernung von Erweiterungen, bevor unveränderliche Backups und Schemanachweise gesichert sind. Eine scheinbar ungenutzte Tabelle oder ein Plugin kann weiterhin Order- oder Product-Historie besitzen.
Artikelbasierte Products und Produkttypen vorbereiten
J2Store verwendet Joomla-Artikel als Products. Die Vorbereitung muss deshalb sowohl die Identität des Joomla-Artikels als auch den zugehörigen J2Store-Commerce-Datensatz bewahren. Je nach Installation können Produkttypen einfache, variable, konfigurierbare, herunterladbare, flexivariable, advanced-variable, Buchungs-, Abonnement-, gruppierte, gebündelte oder anwendungsspezifische Muster umfassen.
| Product-Muster | Nachweis | Freigabekriterium |
|---|---|---|
| Einfaches Product | Artikel-/Product-IDs, SKU, Preis, Bestand, Steuerprofil, Gewicht, Bilder, Kategoriebeziehungen und Beispiel-Order | Inhalts- und Commerce-Identität verweisen auf dasselbe verkaufbare Element. |
| Variables Product | Optionen, erzeugte Kombinationen, SKU, Preis, Bestand, Gewicht, Bild und Status je Kombination | Jede verkaufbare Kombination ist nachvollziehbar und vollständig. |
| Flexivariable oder Advanced-Variable Product | Kombinationsdatensätze, Veröffentlichungsstatus, Nicht-Varianten-Eingaben und benutzerdefinierte Felder | Variantenkombinationen und Kundeneingaben sind getrennt. |
| Herunterladbares Product | Dateidatensätze, Download-Limits, Ablauf, Route zum Customer-Bereich und abgeschlossene Beispiel-Order | Product-zu-Datei- und Order-zu-Zugriff-Beziehungen sind dokumentiert. |
| Gruppiertes oder gebündeltes Product | Parent, Komponenten, Mengen, Preis-/Rabattlogik, Bestandsverantwortung und Beispiel-Order | Zusammensetzung und Bestandsbeziehung sind eindeutig. |
| Buchungs- oder Abonnement-Product | Ressource/Plan, Zeitplan, Status, Zahlungsabhängigkeit, Verhalten der Joomla-Gruppe und historische Datensätze | Zuständigkeit der spezialisierten Anwendung ist dokumentiert. |
Klassifizieren Sie jede Product-Familie danach, was sich ändert, wenn der Käufer eine Option auswählt: SKU, Bestand, Preis, Gewicht, Versand, Steuer, Dateizugriff, Buchungsverfügbarkeit, Abonnementzeitplan oder Kundeneingabe. Daraus ergibt sich, ob der Wert zu einer echten Variante, einer Product-Option, einer einmaligen Eingabe auf der Order-Position oder einem Anwendungsdatensatz gehört.
Optionen, Varianten, Bilder und Kundeneingaben vorbereiten
J2Store-Optionsstrukturen können je nach Produkttyp und installierten Anwendungen unterschiedliche Ergebnisse erzeugen. Ein variables Product kann eine Matrix von Kombinationen mit eigenständiger SKU, Preis und Bestand erzeugen. Ein Advanced-Variable Product kann Variantendimensionen mit freier Eingabe kombinieren. Ein gruppiertes Product kann Products ablehnen, die bereits Optionen besitzen.
| Vorbereitungsbereich | Nachweis | Freigabekriterium |
|---|---|---|
| Optionsdefinitionen | Namen, Typen, Werte, Reihenfolge, Product-Zuweisungen und Preiseffekte | Gleichartige und unterschiedliche Optionsvokabulare sind verstanden. |
| Variantenkombinationen | Parent-Product, Wertekombination, SKU, Preis, Bestand, Bild, Status und externer Schlüssel | Jedes verkaufbare Kind besitzt eine stabile Identität. |
| Vom Customer eingegebener Text oder Dateien | Eingabedefinition und Beispielwerte auf Order-Positionen | Einmalige Eingabe wird nicht als wiederverwendbare Product-Metadaten missverstanden. |
| Product- und Variantenbilder | Hauptbild, Thumbnail, zusätzliche und kombinationsspezifische Dateien | Medien sind dem richtigen Product oder der richtigen Variante zugeordnet. |
| Veraltete oder ungenutzte Kombinationen | Status, Verwendung in Order-Historie und Stilllegungsentscheidung | Historische Referenzen bleiben erhalten, auch wenn die Live-Kombination ausgeschlossen wird. |
Erzeugen Sie Variantenmatrizen nicht neu, bevor die ursprünglichen Kombinationen und ihre IDs dokumentiert wurden. Eine Regeneration kann Identität verändern oder Daten entfernen, die an bestehenden Kombinationen hängen. Falls Bereinigung notwendig ist, führen Sie ein Zuordnungsprotokoll von Quelle zu bereinigter Struktur.
Joomla-Kategorien, Menüs, Module und URLs vorbereiten
Da J2Store-Products Joomla-Artikel sind, hängt ihre Auffindbarkeit von Joomla-Kategorien, Artikelreihenfolge, Menüeinträgen, Modulen, Zugriffsebenen, Sprachen, Template-Views und Anwendungsrouten ab. Bereiten Sie diese Beziehungen für hochwertige Products und zentrale Storefront-Seiten vor.
| Auffindbarkeitsbeziehung | Nachweis | Freigabekriterium |
|---|---|---|
| Product-Artikel zu Kategorie | Artikel-/Product-IDs und Kategoriehierarchie | Produktplatzierung ist bewusst und nachvollziehbar. |
| Kategorie- und Artikelreihenfolge | Quell-Reihenfolgewerte und Anzeigeregeln des Menüs | Wichtige Merchandising-Reihenfolge ist dort dokumentiert, wo sie geschäftlich relevant ist. |
| Menüeintrag zur Shop-Ansicht | Menütyp, Alias, Parent, Sprache, Zugriffsebene und Ziel | Product-, Kategorie-, Warenkorb-, Checkout-, Profil-, Download- und Kontorouten sind bekannt. |
| Modulzuweisung | Position, Menüzuordnung, Sprache und Verantwortlicher | Storefront-Module sind als Inhalt, Darstellung oder Anwendungsausgabe klassifiziert. |
| URL und Weiterleitung | Aktueller Pfad, Objektverantwortlicher, Zielabsicht und Routing-Erweiterung | Prioritätsrouten besitzen genau ein vorgesehenes Ziel. |
| Mehrsprachige Beziehung | Sprachzuweisungen und Joomla-Assoziationen | Übersetzte Product- und Navigationsfamilien sind nachvollziehbar. |
Ein Product-Export stellt Joomla-Menüs oder Module nicht wieder her. Bereiten Sie deshalb Inhalts- und Routennachweise vor, die Datenmigration von Ziel-Template- und Navigationsimplementierung unterscheiden.
Customers, Joomla-Benutzer, Gruppen und Adressen vorbereiten
J2Store-Customers können mit Joomla-Benutzern, Gast-Orders, Adressen, Joomla-Gruppen, anwendungsspezifischen Profilen, Steuerfeldern, Firmendaten und externen Kennungen verbunden sein. Bereiten Sie diese Beziehungen getrennt vor.
| Kontomuster | Nachweis | Freigabekriterium |
|---|---|---|
| Registrierter Customer | Joomla-Benutzer-ID, Customer-Profil, E-Mail, Gruppen, Adressen, Status und Orders | Doppelte E-Mails und Konten mit mehreren Gruppen besitzen eine dokumentierte Behandlung. |
| Gast-Customer | Order-bezogene Identität und Adressen | Gast-Historie bleibt verständlich, ohne nicht belegte Konten zu erzeugen. |
| Gruppenbasierter Commerce | Joomla-Gruppe, Product-Verknüpfung, auslösender Order-Status, Preis-/Zugriffseffekt und verantwortliche Anwendung | Gruppenzuweisung wird als Geschäftsbeziehung und nicht nur als Bezeichnung verstanden. |
| Firmen- oder Steuerkonto | Firmenfelder, Steuer-ID, Befreiungsstatus und externe Konto-ID | Geschäftsidentität besitzt einen benannten Verantwortlichen. |
| Authentifizierungsabhängigkeit | Passwortquelle, SSO/Social Login, MFA, Reset-Ablauf und Kommunikationsverantwortlicher | Kontozugriff ist geplant, ohne Portabilität der Quell-Anmeldedaten vorauszusetzen. |
Fügt eine Anwendung einen Benutzer nach dem Kauf einer Joomla-Gruppe hinzu, erfassen Sie Product, ausgewählte Gruppe, auslösenden Order-Status, aktuelle Mitgliedschaft und Beispielhistorie. Dieser Ablauf kann geschützte Inhalte oder Dienstleistungen nach dem Kauf steuern.
Orders und historische Commerce-Nachweise vorbereiten
Bereiten Sie Order-Köpfe, Order-Positionen, Product- und Variantenreferenzen, ausgewählte Optionen, Kundeneingaben, Rechnungs- und Lieferadressen, Preise, Rabatte, Steuern, Zahlungs- und Versandbezeichnungen, Statuswerte, Kommentare, Tracking, Rechnungen, Downloads, Abonnements, Buchungen, Gutscheine und anwendungsspezifische Datensätze vor, soweit vorhanden.
| Historischer Datensatz | Nachweis | Freigabekriterium |
|---|---|---|
| Order-Statushistorie | Statusdefinitionen, Zeitstempel, Kommentare und operative Bedeutung | Jeder Status lässt sich ohne Rückgriff auf die alte Oberfläche interpretieren. |
| Product-Positionen | Artikel-/Product-/Varianten-IDs, SKU, ausgewählte Werte, Menge, Preis und Steuer | Gekauftes Element bleibt identifizierbar, auch wenn sich der Live-Katalog verändert. |
| Zahlungskontext | Methodenbezeichnung und Transaktionsreferenz | Historischer Zahlungsnachweis ist verfügbar, ohne Zugangsdaten zu übertragen. |
| Versandkontext | Methodenbezeichnung, Gebühr, Tracking und Hinweise zur Auftragsabwicklung | Historischer Liefernachweis ist von aktueller Carrier-Konfiguration getrennt. |
| Download-Zugriff | Product-Datei, Order-Status, Limit, Ablauf und Customer-Beziehung | Historie digitaler Berechtigungen ist nachvollziehbar. |
| App-eigene Historie | Abonnement-, Buchungs-, Bundle-, Gruppenzuweisungs-, Gutschein- oder Bonusdatensätze | Zugehörige Anwendungsdatensätze sind mit der richtigen Order und dem richtigen Customer verbunden. |
Erstellen Sie ein Statusglossar für Order-, Zahlungs-, Versand-, Download-, Abonnement- und Buchungsstatus. Ähnliche Begriffe wie New, Confirmed, Pending, Failed oder Completed können je nach Erweiterung unterschiedliche operative Bedeutung tragen.
Anwendungen, Plugins, benutzerdefinierte Felder und individuelle Tabellen inventarisieren
J2Store-Anwendungen können gruppierte Products, Bundles, zusätzliche Gebühren, Mengenrabatte, Customer-Gruppenaktionen, Buchungen, Abonnements, Downloads, Versand, Zahlung, Analysen und weitere Datensätze besitzen. Joomla-Plugins, Template-Overrides und individuelle Tabellen können dieselben Objekte zusätzlich erweitern.
Dokumentieren Sie für jede wichtige Abhängigkeit:
- Name und Version;
- geschäftlicher Zweck;
- Tabellen und Felder;
- Product-, Customer-, Benutzer- und Order-Schlüssel;
- geplante Aufgaben oder Event-Auslöser;
- externe Dienste und Kennungen;
- Zielverantwortlicher oder Stilllegungsentscheidung;
- repräsentative Quelldatensätze.
Beschreiben Sie Anforderungen nicht lediglich als „App-Daten“. Benennen Sie das tatsächliche Objekt: Abonnement, Buchung, Bundle-Komponente, Gebühr, Gruppenzuweisung, Download-Berechtigung, individuelles Checkout-Feld, Listing oder Integrationsstatus. Erst eine klare Objektdefinition erlaubt die Wahl eines geeigneten Ziels.
Historische Datensätze von aktiver Zielkonfiguration trennen
Historische Bezeichnungen und Beträge können als Nachweise migriert werden. Aktive Steuer-, Zahlungs-, Versand-, E-Mail-, Cron-, Template-, Sicherheits- und Erweiterungsfunktionen müssen jedoch separat implementiert werden.
| Quellnachweis | Separate Verantwortung im Ziel |
|---|---|
| Zahlungsartbezeichnung und Transaktions-ID | Gateway-Konto, Zugangsdaten, Callbacks, Betrugskontrollen und aktives Testing |
| Versandmethode, Gebühr und Tracking | Carrier-Konto, Zonen, Tarife, Abholung, Verpackung und Auftragsabwicklung |
| Historischer Steuerbetrag und Profilbezeichnung | Aktuelle Steuerregistrierungen, Sätze, Befreiungen und Berechnungsregeln |
| Product- und Customer-Gruppenbeziehung | Aktuelle Zugriffs-, Preis- oder Mitgliedschaftsautomatisierung |
| Download-Historie | Aktueller Dateischutz, Customer-Bereich, E-Mail-Zustellung und Zugriffsrichtlinie |
| Abonnement- oder Buchungshistorie | Aktuelle Gateway-Unterstützung, geplante Aufgaben, Kapazitätsregeln, Benachrichtigungen und Verlängerungslogik |
| Bestehende Shop-URLs | Zielmenüs, Aliasse, Template-Ausgabe, Weiterleitungen und Suchimplementierung |
Das Vorbereitungspaket ist freigabereif, wenn sowohl Quellnachweise als auch Zuständigkeiten für die Zielimplementierung ausdrücklich dokumentiert sind. Historische Datensätze dürfen nicht so behandelt werden, als würden sie zukünftige Betriebsfunktionen konfigurieren.
Repräsentative Migrationsstichproben auswählen
Wählen Sie anspruchsvolle, beziehungsreiche Stichproben statt nur sauberer einfacher Products. Dazu gehören:
- ein einfaches Product, das mit einem Joomla-Artikel und einer Kategorie verknüpft ist;
- ein variables oder flexivariables Product mit eigenständigen Kombinationsdaten;
- ein Advanced-Variable Product mit Kundeneingabe, sofern verwendet;
- ein herunterladbares Product mit Zugriffshistorie;
- ein gruppiertes, gebündeltes, Buchungs- oder Abonnement-Product, sofern verwendet;
- eine mehrsprachige oder zugriffsbeschränkte Product-Route;
- ein Customer mit mehreren Adressen oder Gruppen;
- eine Gast-Order und eine Order eines registrierten Customers;
- eine Order mit Rabatt-, Steuer-, Zahlungs-, Versand- und Tracking-Nachweisen;
- ein anwendungseigener Datensatz oder eine externe Kennung.
Halten Sie für jede Stichprobe Quell-IDs, verknüpfte Joomla- und J2Store-Datensätze, Auswahlgrund, benötigte Nachweise und jedes Live-Verhalten fest, das bewusst der Zielimplementierung zugewiesen wurde.
Abschließendes Freigabekriterium für die Bereitschaft festlegen
| Bereitschaftsfrage | Freigabekriterium |
|---|---|
| Kann der Shop wiederhergestellt werden? | Unveränderliche Datenbank- und Dateisystembackups existieren und ein Restore-Verantwortlicher ist benannt. |
| Ist die Lebenszyklusverantwortung klar? | Hosting, Sicherheit, Kompatibilität, Ersatz von Erweiterungen und Wiederherstellung besitzen benannte Verantwortliche. |
| Sind Produkttypen und Varianten klassifiziert? | Für jedes wichtige Product-Muster existieren Quellnachweise und eine repräsentative Stichprobe. |
| Sind Joomla-Beziehungen erfasst? | Product-Artikel, Kategorien, Menüs, Module, Sprachen, Zugriffsebenen und URLs sind nachvollziehbar. |
| Sind Customers und Orders verständlich? | Benutzerbeziehungen, Gruppen, Adressen, Statuswerte, Summen und app-eigene Historie sind dokumentiert. |
| Sind Anwendungen und individuelle Daten zugeordnet? | Jeder aktive Datensatz besitzt Schema, Verantwortlichen, Quellschlüssel und Zielentscheidung. |
| Ist Zielkonfiguration getrennt? | Zuständigkeiten für Checkout, Zahlung, Versand, Steuer, Cron, Template und Sicherheit sind zugewiesen. |
| Sind offene Punkte kontrolliert? | Jede ungeklärte Abhängigkeit hat einen Verantwortlichen, eine Frist und eine dokumentierte Auswirkung auf den Umfang. |
Fehlende Backups, ungeklärte Lebenszyklusverantwortung, neu erzeugte Varianten ohne Quellzuordnungsprotokoll, unbekannte App-Tabellen oder nicht nachvollziehbare spezialisierte Product-Historie sollten den jeweils betroffenen Umfang blockieren.
Fazit
Die Vorbereitung einer J2Store-Migration muss die Verbindung zwischen Joomla-Artikeln und Commerce-Datensätzen bewahren und gleichzeitig Produkttypen, Varianten, Dateien, Customers, Orders, Anwendungen, URLs und langjährige Anpassungen berücksichtigen. Das Vorbereitungspaket sollte zeigen, wer jede Maßnahme verantwortet, welcher Nachweis die Quellbeziehung belegt und welche Bedingung den jeweiligen Umfang freigabereif macht.
Dieser Ansatz hält historische Datensätze von aktiver Zielkonfiguration getrennt und verhindert, dass Legacy-Erweiterungslogik in einem generischen Product- oder Order-Export verborgen bleibt.
Häufige Fragen
Was sollte vor einer J2Store-Migration zuerst vorbereitet werden?
Bestätigen Sie den Zugriff auf Joomla, J2Store, Hosting, Datenbank, Dateisystem, Medien und geplante Aufgaben. Erstellen Sie unveränderliche Backups und dokumentieren Sie die exakten Quellversionen sowie installierten Anwendungen, bevor Bereinigungen oder Upgrades beginnen.
Warum benötigen J2Store-Products sowohl Joomla- als auch Commerce-Nachweise?
J2Store verwendet Joomla-Artikel als Products. Inhalte, Kategorien, Sprache, Zugriff, Menüs und Routen können zu Joomla gehören, während SKU, Preis, Bestand, Optionen, Varianten und Order-Beziehungen zu J2Store gehören.
Wie sollten variable J2Store-Products vorbereitet werden?
Dokumentieren Sie Optionsdefinitionen und jede erzeugte Kombination mit Parent-Product, ausgewählten Werten, SKU, Preis, Bestand, Bildern, Status und externen Kennungen. Erzeugen Sie Kombinationen nicht neu, bevor die ursprüngliche Identitätszuordnung bewahrt wurde.
Welche Nachweise werden für herunterladbare Products benötigt?
Bereiten Sie Product-zu-Datei-Beziehungen, Dateispeicherorte, Download-Limits, Ablaufeinstellungen, Routen zum Customer-Bereich, relevante Order-Statuswerte und repräsentative abgeschlossene Orders mit Zugriffshistorie vor.
Wie sollten J2Store-Anwendungen und individuelle Tabellen dokumentiert werden?
Benennen Sie Anwendung und Objekt, erfassen Sie Tabellen, Schlüssel, Product-/Customer-/Order-Beziehungen, Auslöser, geplante Aufgaben, externe Abhängigkeiten und repräsentative Datensätze. Behandeln Sie nicht sämtliche erweiterungseigenen Informationen als generische benutzerdefinierte Daten.
Welche Datensätze eignen sich als repräsentative Migrationsstichproben für J2Store?
Wählen Sie artikelbasierte einfache Products, Varianten-Products, erweiterte oder spezialisierte Produkttypen, beschränkte oder mehrsprachige Routen, komplexe Customers, Gast- und registrierte Orders, digitale Berechtigungen, anwendungseigene Daten und externe Kennungen.