Wenn EShop by Ossolution Team 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 EShop by Ossolution Team als Zielplattform ausgewählt wird, muss die Vorbereitung die Beziehungen hinter Products, Categories, Manufacturers, Optionen, Attributen, benutzerdefinierten Feldern, Attachments, Customer-Konten, Orders, Steuern, Versand, Zahlung, Mehrsprachigkeit und Joomla-Präsentation dokumentieren. Product-Optionen können eigene SKU-, Preis- oder Bilddaten tragen, während Attribute und benutzerdefinierte Felder Products beschreiben oder filtern können, ohne eine eigenständige verkaufbare Einheit zu bilden.
Das Vorbereitungspaket sollte vor der Ausführung für jede Aufgabe Verantwortlichen, Nachweis und Freigabekriterium festhalten. Historische Transaktionen und Quellbeziehungen müssen erhalten bleiben, während aktiver Checkout, Zahlung, Versand, Steuer, E-Mail-, Template- und Modulverhalten als Zielimplementierung behandelt werden.
Joomla-, EShop-, Hosting- und Datenbankzugriff absichern
Zugriff auf Joomla-Administration, EShop-Administration, Hosting, Datenbank, Dateisystem, Product-Bilder und Attachments, Download-Dateien, geplante Prozesse, Zahlungs- und Versand-Plugins sowie verbundene Systeme bestätigen. Joomla-, EShop-, PHP-, Datenbank-, Template-, Sprach-, Plugin-, Modul- und Anpassungsversionen dokumentieren.
| Vorbereitungsmaßnahme | Verantwortlicher | Nachweis | Freigabekriterium |
|---|---|---|---|
| Administrativen Zugriff bestätigen | Joomla-/EShop-Administrator | Funktionierende Konten und Rollenübersicht | Products, Optionen, Customers, Orders, Berichte und Konfiguration können geprüft werden. |
| Wiederherstellbare Backups erstellen | Infrastrukturverantwortlicher | Datenbankexport, Dateisystem-/Medien-/Download-Archiv und Restore-Verantwortlicher | Die Quelle kann ohne Abhängigkeit vom Live-Shop wiederhergestellt werden. |
| Software und Erweiterungen dokumentieren | Technikverantwortlicher | Joomla-, EShop-, PHP-, Datenbank-, Template-, Zahlungs-, Versand-, Plugin-, Modul- und Erweiterungsinventar | Versionsabhängige Datensätze und Abhängigkeiten sind dokumentiert. |
| Anpassungen erfassen | Entwicklungsverantwortlicher | Template-Overrides, eigene Module/Plugins, Source-Edits, benutzerdefinierte Felder, SQL-Änderungen und Skripte | Jede Anpassung, die Commerce-Daten liest oder schreibt, hat einen Verantwortlichen. |
| Verbundene Systeme zuordnen | Integrationsverantwortliche | ERP/PIM/WMS/CRM/Buchhaltung/Auftragsabwicklung/Marketplace/Feed-Endpunkte und externe IDs | Weiterlaufende Systeme und Datenautoritäten sind bekannt. |
IDs für Products, Categories, Manufacturers, Optionen, Optionswerte, Attribute, benutzerdefinierte Felder, Customers, Orders, Order-Positionen, Status, Steuern, Versand, Zahlung, Attachments, Sprachen und externe Systeme sichern, soweit sie zur Rekonstruktion von Beziehungen benötigt werden.
Products, Categories, Manufacturers, Medien und Attachments vorbereiten
EShop-Products können Kennungen, Beschreibungen, Categories, Manufacturers, Preise, Bestand, Abmessungen, Bilder, Videos, Optionen, Attribute, benutzerdefinierte Felder, Attachments, Labels, Related Products, Bewertungen, Metadaten, Downloads und Sprachzuordnungen enthalten. Products nach Verkaufsverhalten und geschäftlicher Bedeutung vorbereiten.
| Product-Muster | Vorzubereitender Nachweis | Freigabekriterium |
|---|---|---|
| Einfaches physisches Product | Product-ID, SKU, Preis, Steuer, Bestand, Category, Manufacturer, Bilder und Beispiel-Order | Ein Datensatz identifiziert das verkaufte Element eindeutig. |
| Optionsintensives Product | Optionsdefinitionen, Werte, Kombinationen, separate SKU-/Preis-/Bilddaten, Bestandsbeziehung und Order-Beispiel | Jede kaufbare Auswahl ist auf Product und Optionswerte zurückführbar. |
| Download-Product | Datei, Product-Link, Zugriffsregel, Downloadhistorie und abgeschlossene Order | Dateiverantwortung und Order-basierter Zugriff sind dokumentiert. |
| Product in mehreren Categories | Product-to-Category-Verknüpfungen, priorisierte Route und Sprache | Auffindbarkeitsbeziehungen bleiben ohne doppelte Products erhalten. |
| Product mit vielen Attachments | Dokumente, Handbücher, Spezifikationen, Pfade, Labels und Product-Zuordnung | Nicht-Bild-Assets bleiben mit dem richtigen Product verbunden. |
| Related-/Compare-Product | Beziehungstyp, verknüpfte Product-IDs, Darstellungszweck und Priorität | Merchandising-Beziehungen sind getrennt von Taxonomie dokumentiert. |
Unveröffentlichte, hervorgehobene, Call-for-Price-, Out-of-Stock-, Download-, mehrsprachige, mengenbegrenzte und individuell gelabelte Fälle erfassen. Diese Zustände benötigen eine bewusste Zielbehandlung.
Optionen, Attribute, benutzerdefinierte Felder und Product-Attachments trennen
Mehrere EShop-Strukturen können in einem Quellexport wie gewöhnliche Product-Attribute aussehen. Optionen sind auswählbare Kaufentscheidungen und können eigene SKU-, Preis- oder Bildwerte tragen. Attribute beschreiben Products. Benutzerdefinierte Felder enthalten zusätzliche strukturierte Werte. Attachments verbinden Dateien mit Products.
| Struktur | Nachweis | Freigabekriterium |
|---|---|---|
| Product-Option | Name, Typ, Werte, Reihenfolge, Pflicht-/Defaultstatus, Product-Zuordnung und Order-Positionsbeispiel | Auswählbare Werte bleiben mit Käufen verbunden. |
| Optionswert mit kommerziellen Daten | Product, Option/Wert, separate SKU, Preisänderung, Bild, Bestandslogik und externe Kennung | Verkaufbare Auswahldaten werden nicht in beschreibende Attribute abgeflacht. |
| Product-Attribut | Attributgruppe/Wert, Product-Zuordnung, Filter-/Vergleichsnutzung und Sprache | Beschreibende Merkmale bleiben von Varianten getrennt. |
| Benutzerdefiniertes Feld | Felddefinition, Datentyp, Geschäftszweck, Product-Zuordnung und konsumierendes Modul/Plugin | Individuelle Werte haben einen benannten Verantwortlichen und eine Bearbeitungsoberfläche. |
| Attachment | Dateipfad, Typ, Label, Sprache, Product-Link und Zugriffserwartung | Product-Dateien bleiben wiederherstellbar und korrekt verknüpft. |
| Extra Product-Tab oder Label | Titel, Inhalt, Sprache, Product-Zuordnung und Präsentationsverantwortlicher | Redaktioneller Inhalt wird nicht mit Product-Identität oder Optionsdaten verwechselt. |
Ein Feldverzeichnis erstellen, das Zweck, Verantwortlichen, Datentyp, Product-Umfang und Migrationsbehandlung dokumentiert. Ähnliche Namen dürfen nicht zusammengeführt werden, wenn ihr kommerzielles Verhalten unterschiedlich ist.
Preise, Bestand, Steuern, Rabatte, Währungen und Mengenregeln vorbereiten
EShop-Preislogik kann reguläre und Sonderpreise, Optionsaufschläge, Steuern, Gutscheine, mehrere Währungen, Mengenregeln und Customer-spezifisches Verhalten umfassen. Bestand kann zu Product, Optionskombination, externem System oder einem nicht bestandsgeführten Download-Product gehören.
| Geschäftsbereich | Vorzubereitender Nachweis | Freigabekriterium |
|---|---|---|
| Product- und Optionspreise | Product-/Options-ID, Währung, reguläre/Sonderwerte, Laufzeiten und Preisänderungen | Preise hängen am richtigen verkaufbaren Kontext. |
| Bestand | Product-/Optionsmenge, Status, Verfügbarkeitsregel, externer Verantwortlicher und Sync-Key | Autoritative Menge und Verkaufseinheit sind bekannt. |
| Steuern | Steuerklasse/-satz, Geozone, Product-Zuordnung, Customer-Kontext und historische Orders | Steuerkonfiguration ist von historischen Steuerbeträgen getrennt. |
| Gutscheine und Rabatte | Code/Regel, Wert, Laufzeit, Limits, Product-/Category-Umfang und historische Orders | Aktive Aktionsregeln und historische Evidenz sind unterscheidbar. |
| Währung | Code, Rate-Verantwortlicher, Dezimal-/Rundungserwartung, Product-Preise und Order-Währung | Historische und aktuelle Währungsbedeutung ist dokumentiert. |
| Mengenregeln | Mindest-/Maximalmenge, Verpackung, Schritt, Staffelpreis oder eigene Logik | Mengenverhalten ist nicht nur in Notizen oder Template-Code versteckt. |
Wenn ERP, Lieferantenfeed, Marketplace oder Buchhaltung Preis oder Bestand besitzt, klären, ob der EShop-Wert autoritativ, synchronisiert oder nur Start-Snapshot ist.
Customers, Joomla-Benutzer, Adressen, Gruppen und Bewertungen vorbereiten
Customer-Vorbereitung verbindet Joomla-Benutzer, EShop-Customer, Gastkäufer, Rechnungs- und Lieferadressen, Checkout-Felder, Firmen-/Steuerkennungen, Gruppen, Bewertungen, Wunschlisten, externe IDs und gegebenenfalls Consent-Beziehungen.
| Kontobereich | Nachweis | Verantwortlicher | Freigabekriterium |
|---|---|---|---|
| Registrierter Customer | Joomla-User-ID, EShop-Customer-ID, E-Mail, Status, Adressen, Gruppe und externe IDs | Customer-Datenverantwortlicher | Doppelte und systemübergreifende Identitäten haben eine geplante Behandlung. |
| Gastkäufer | Order-Identität, E-Mail, Adressen und Order-Referenzen | Order-Datenverantwortlicher | Gast-Historie bleibt nützlich, ohne ein Konto zu erfinden. |
| Billing-/Shipping-Custom-Field | Felddefinition, Pflicht-/Anzeigeregeln, gespeicherte Werte und Order-/Customer-Verantwortung | Customer-Service-Verantwortlicher | Custom-Customer-Daten gehen nicht verloren und landen am richtigen Objekt. |
| Firmen-/Steueridentität | Firma, Steuernummer, Validierungsstatus, Gruppe und externe Account-ID | Finance-/B2B-Verantwortlicher | Geschäftsidentität hat ein benanntes Ziel oder einen weiter bestehenden Verantwortlicher. |
| Bewertung/Wunschliste | Product, Customer-/Gastidentität, Rating/Text/Status oder Wishlist-Beziehung | Katalog-/Content-Verantwortlicher | Customer-generierte Daten bleiben am richtigen Product und an der richtigen Identität. |
| Authentifizierung | Lokales Passwort, SSO/Social Login, Reset-Prozess und Kommunikationsverantwortung | Security-Verantwortlicher | Kontozugriff ist geplant, ohne Passwortportabilität vorauszusetzen. |
Customers mit mehreren Adressen, Gast-Orders, gruppenabhängiges Verhalten, benutzerdefinierte Felder, Bewertungen, Wunschlisten, doppelte E-Mails und wichtige externe IDs aufnehmen.
Orders, Status, Zahlung, Versand, Rechnungen und Downloads vorbereiten
Historische EShop-Orders müssen Transaktionen unabhängig von der aktuellen Shop-Konfiguration erklären. Order-Header, Customer-/Gastidentität, Adressen, Product-/Optionspositionen, Attachments/Downloads, Mengen, Preise, Rabatte, Steuern, Gutscheine, Währung, Zahlung, Versand, Status, Kommentare, Rechnungen, Refunds/Anpassungen und externe Referenzen vorbereiten.
| Order-Nachweis | Verantwortlicher | Freigabekriterium |
|---|---|---|
| Order-Header und Statushistorie | Commerce Operations | Customer/Gast, Daten, Währung, Statusfolge und Quellkanal sind dokumentiert. |
| Product- und Optionspositionen | Katalog-/Order-Verantwortliche | Product-IDs, Optionswerte, SKU, Menge, Preis, Steuer und Snapshot-Text sind vollständig. |
| Summen und Anpassungen | Finance | Zwischensumme, Rabatt, Gutschein, Steuer, Versand, Zahlungsgebühr, Währung und Endsumme stimmen. |
| Zahlung und Versand | Finance/Auftragsabwicklung | Historische Methodenlabels, Transaktions-/Tracking-IDs, Carrier und Provider-Verantwortung sind bekannt. |
| Rechnung und Downloadzugriff | Finance/digitale Auslieferung | Rechnungsnummern/-dateien, Downloads, Limits und Order-Beziehungen sind wiederherstellbar. |
| Refund-/Return-Kontext | Finance/Customer Service | Beträge, betroffene Positionen, Datum, Gründe, Status und externe Referenzen sind dokumentiert. |
| Externe Order-IDs | Integration | ERP-, Accounting-, Marketplace- oder Schlüssel der Auftragsabwicklung bleiben nachvollziehbar. |
Gewöhnliche, Gast-, optionsintensive, rabattierte, Multi-Tax-, mehrsprachige, Download-, Refund- und getrackte Orders auswählen, sofern diese Muster existieren.
Joomla-Menüs, mehrsprachige Inhalte, URLs, Medien und Präsentation vorbereiten
EShop-Commerce-Datensätze können über Joomla-Menüs, Module, Templates, Product-/Category-/Manufacturer-Routen, Suchmodule, Sprachzuordnungen, Medien und Metadaten sichtbar werden. Diese Beziehungen getrennt von Product-Daten inventarisieren.
| Storefront-Bereich | Nachweis | Freigabekriterium |
|---|---|---|
| Product-, Category- und Manufacturer-URLs | Quellroute, Alias, Record-ID, Menükontext, Sprache, Metadaten und Zielabsicht | Priorisierte Routen haben eine Entscheidung: behalten, ändern, zusammenführen, stilllegen oder weiterleiten. |
| Joomla-Menüs und Module | Menütyp, Parent, Alias, Sprache, Zugriff, Modulposition, Filter und ausgewählte Datensätze | Shop-Einstiegspunkte und Discovery-Abhängigkeiten sind dokumentiert. |
| Mehrsprachige Datensätze | Product-/Category-/Manufacturer-Zuordnungen, übersetzte Optionen/Attribute, Menüs, Metadaten und Fallbacks | Übersetzungen werden nicht als unabhängige Duplikate behandelt. |
| Templates und Overrides | Template, EShop-Layouts, Modul-Chrome, Custom Tabs und betroffene Routen | Präsentationsabhängigkeiten sind von Commerce-Datensätzen getrennt. |
| Product-Medien und Attachments | Bilder, Thumbnails, Videos, Attachments, Downloads, Remote Storage und Dateirechte | Priorisierte Assets bleiben verfügbar und korrekt verknüpft. |
| SEO und Redirects | Metadata-Verantwortlicher, SEF-/Routing-Erweiterung, Sitemap-Quelle, Weiterleitungsregeln und hochwertige URLs | URL-Kontinuität hat einen Verantwortlichen. |
Der allgemeine Joomla-Umfang besitzt CMS-Artikel und Seiten. Die EShop-Vorbereitung erfasst nur Joomla-Strukturen, die Commerce-Datensätze und -Routen materiell beeinflussen.
Erweiterungen, Zahlungs-/Versand-Plugins, Custom Data und externe Systeme inventarisieren
Ein Abhängigkeitsverzeichnis für EShop-Erweiterungen, Zahlungs- und Versand-Plugins, Such-/Filtermodule, Import-/Export-Tools, Templates, benutzerdefinierte Felder, CRM, ERP, Accounting, Auftragsabwicklung, Marketplaces, Analyse und individuellen Code erstellen.
| Abhängigkeit | Nachweis | Freigabekriterium |
|---|---|---|
| EShop-Erweiterung/Plugin | Name, Version, Zweck, Konfiguration, eigene Datensätze und verknüpfte Product-/Customer-/Order-IDs | Erweiterungseigene Records haben ein Ziel oder einen weiter bestehenden Verantwortlicher. |
| Zahlungs-/Versand-Plugin | Provider, gespeicherte Transaktions-/Trackingdaten, Status und historische Order-Abhängigkeiten | Historische Referenzen sind von Live-Plugin-Konfiguration getrennt. |
| Import-/Export-Ablauf | Format, Spalten, Kennungen, Options-/Attributbeziehungen und letzter erfolgreicher Lauf | Extrahierte Records lassen sich mit Datenbankevidenz abstimmen. |
| Benutzerdefiniertes Feld/Tabelle | Schema, Keys, Geschäftszweck und konsumierender Code | benutzerdefinierte Datensätze können interpretiert statt blind kopiert werden. |
| Externes System | Endpoint, autoritative Datensätze, Sync-Richtung, IDs und Cutover-Verantwortlicher | Systemübergreifende Identität und Autorität sind dokumentiert. |
| Generierte Daten | Caches, Logs, Sessions, temporäre Exporte, Indizes und verwaiste Records | Nicht autoritative technische Daten werden bewusst ausgeschlossen. |
Inaktive Erweiterungen bleiben im Verzeichnis, wenn sie Datensätze erzeugt haben, die weiterhin für Orders, Customers, Products, Downloads oder Auswertung benötigt werden.
Repräsentative Prüfmuster für die Migration auswählen
Quell-IDs, SKUs, URLs, Sprache, verbundene Records, externe Keys und den Grund für jedes Sample dokumentieren.
| Sample | Nachweis | Zweck |
|---|---|---|
| Einfaches Product | Preis, Bestand, Steuer, Category, Manufacturer, Medien und Order | Baseline eines gewöhnlichen EShop-Products und seines Commerce-Kontexts. |
| Optionsintensives Product | Optionen/Werte, separate SKUs/Preise/Bilder, Bestand, Attribute und Order-Position | Käuferauswahl und verkaufbare Optionsbeziehungen. |
| Product mit Attributen/benutzerdefinierte Felder | Attributgruppen, benutzerdefinierte Felder, Attachments, Tabs, Filter und Product-Route | Beschreibende und erweiterte Product-Daten. |
| Registrierter Customer und Gast-Order | Joomla-/Customer-IDs, Adressen, Gruppen, benutzerdefinierte Felder und externe IDs | Beide Customer-Identitätsmodelle. |
| Komplexe Order | Optionspositionen, Gutschein, Steuer, Währung, Zahlung, Versand, Rechnung, Refund, Download und externe Referenz | Historischer Geschäftskontext. |
| Mehrsprachige Route | Zugeordnete Products/Categories, übersetzte Optionen, Aliase, Menüs, Metadaten und Redirect-Ziel | Joomla-Sprach- und Routing-Abhängigkeiten. |
| Erweiterungseigener Record | Kernrecord, Plugin-Verantwortlicher, benutzerdefinierte Tabelle/Feld und externer Key | Nicht-Kernumfang wird vor der Ausführung sichtbar. |
Die Vorbereitung definiert Samples und Quellevidenz. Spätere Zielprüfung und Go-live-Entscheidung gehören zur Validierung.
Abschließendes EShop-Bereitschafts-Gate
| Bereich | Freigabekriterium |
|---|---|
| Zugriff und Wiederherstellung | Joomla, EShop, Hosting, Datenbank, Dateien, Backups und Restore-Verantwortung sind bestätigt. |
| Katalog | Products, Categories, Manufacturers, Optionen, Attribute, benutzerdefinierte Felder, Attachments, Medien, Bestand, Preise und Kennungen sind dokumentiert. |
| Customers | Joomla-Benutzer, Customers, Gäste, Adressen, Gruppen, benutzerdefinierte Felder, Bewertungen, Wunschlisten und Authentifizierungsabhängigkeiten sind klassifiziert. |
| Orders | Positionen, Optionen, Summen, Status, Zahlung, Versand, Rechnungen, Downloads, Refunds und externe IDs besitzen Nachweise. |
| Storefront | Menüs, Module, Sprachen, Templates, Routen, Medien, SEO und Redirects sind dokumentiert. |
| Abhängigkeiten | Erweiterungen, Plugins, Importe, individueller Code, externe Systeme und autoritative Verantwortlicher sind erfasst. |
| Samples | Repräsentative Records decken jedes wesentliche Product-, Customer-, Order-, Routing-, Download- und Erweiterungsmuster ab. |
Der EShop-Umfang ist bereit, wenn jeder wesentliche Record einen Quellverantwortlichen, eine Beziehungskarte, einen Nachweis und eine geplante Ziel- oder Retained-System-Entscheidung hat.
Fazit
Die Vorbereitung auf EShop erfordert koordinierte Evidenz über Joomla, Products, Optionen, Attribute, benutzerdefinierte Felder, Attachments, Customers, Orders, Steuern, Versand, Zahlung, Währungen, mehrsprachige Routen, Plugins und externe Systeme. Diese Beziehungen lassen sich nicht zuverlässig durch einen flachen Product- oder Order-Export darstellen.
Ein vollständiges Vorbereitungspaket sichert wiederherstellbare Evidenz, identifiziert autoritative Records, trennt historische Transaktionen von aktueller Konfiguration und klärt die Verantwortung jeder wesentlichen Abhängigkeit.
Häufige Fragen
Was sollte für eine EShop-Migration zuerst vorbereitet werden?
Zugriff auf Joomla, EShop, Hosting, Datenbank, Dateisystem, Medien, Downloads, Zahlungs-/Versand-Plugins und Integrationen bestätigen. Wiederherstellbare Backups und Softwareversionen dokumentieren, bevor die Detailarbeit am Katalog beginnt.
Was ist bei der Vorbereitung der Unterschied zwischen EShop-Optionen und Attributen?
Optionen können auswählbare Käuferwerte darstellen und eigene SKU-, Preis- oder Bilddaten tragen. Attribute beschreiben Product-Eigenschaften und unterstützen häufig Filter oder Vergleiche. Definitionen und Product-Zuordnungen sollten getrennt bleiben.
Warum müssen Product-Attachments und Extra-Tabs inventarisiert werden?
Attachments können Handbücher, Spezifikationen, Downloads oder andere Dateien enthalten; Extra-Tabs können Product-spezifischen Content tragen. Wer nur die Hauptbeschreibung übernimmt, kann wichtige Product-Information verlieren.
Wie sollten Customer- und Gastidentitäten vorbereitet werden?
Joomla-User-/EShop-Customer-Beziehungen, E-Mail, Adressen, Gruppen, Checkout-Felder, externe IDs und Order-Beziehungen dokumentieren. Gast-Historie bleibt Order-Evidenz und sollte nicht zwangsläufig in neue Konten umgewandelt werden.
Welche EShop-Orders eignen sich als repräsentative Samples?
Gewöhnliche und Gast-Orders, Products mit Optionen, Rabatten, Gutscheinen, mehreren Steuern oder Währungen, Downloads, Rechnungen, Refunds/Anpassungen, Tracking und externe Referenzen.
Wie sollte die Vorbereitung zwischen Joomla und EShop aufgeteilt werden?
Joomla besitzt allgemeinen CMS-Content, Benutzer, Menüs, Module, Templates und Zugriffsarchitektur. EShop besitzt Commerce-Products, Optionen, Customers, Orders, Preise, Bestand und Erweiterungen; dokumentiert werden zusätzlich nur die Joomla-Abhängigkeiten, die diese Commerce-Records tatsächlich beeinflussen.