Wenn EasyStore by JoomShaper als Zielplattform ausgewählt werden soll, muss die Vorbereitung Commerce-Datensätze mit den Joomla- und JoomShaper-Strukturen verbinden, die sie darstellen und verwalten. Products können von Varianten, Categories, Tags, Marken, Collections, Bildern, Bestand, Coupons, Bewertungen, Customers, Orders, Erstattungen, Joomla Menu Items, SP-Page-Builder-Layouts, Zahlungs- und Versandintegrationen sowie externen Systemen abhängen.
Jede erforderliche Vorbereitungsmaßnahme sollte einem verantwortlichen Verantwortlicher, einem wiederherstellbaren Nachweisartefakt und einer expliziten Freigabebedingung zugeordnet werden. Quellfakten müssen erhalten bleiben, ohne Live-Checkout-, Zahlungs-, Versand-, Steuer-, Benachrichtigungs- oder Page-Builder-Verhalten fälschlich als migrierte Datensätze zu behandeln.
Joomla-, EasyStore-, Hosting- und Datenbankzugriff absichern
Bestätigen Sie Zugriff auf Joomla-Administration, EasyStore-Administration, Hosting, Datenbank, Dateisystem, Product-Medien, SP Page Builder, Zahlungs- und Versandintegrationen, geplante Tasks und verbundene Systeme. Dokumentieren Sie Versionen von Joomla, EasyStore, PHP, Datenbank, Template, SP Page Builder, Plugins, Modulen und Sprachen.
| Vorbereitungsmaßnahme | Verantwortlicher | Nachweis | Freigabebedingung |
|---|---|---|---|
| Administrativen Zugriff bestätigen | Joomla-/EasyStore-Administrator | Funktionsfähige Konten und Rollenübersicht | Products, Varianten, Customers, Orders, Coupons, Bewertungen und Konfiguration sind prüfbar. |
| Wiederherstellbare Backups erstellen | Infrastruktur-Verantwortlicher | Datenbankexport, Datei-/Medienarchiv und Wiederherstellungsverantwortlicher | Die Quelle kann unabhängig vom Live-Shop wiederhergestellt werden. |
| Erweiterungsumgebung dokumentieren | Technischer Verantwortlicher | Inventar von Joomla, EasyStore, SP Page Builder, Template, Plugins, Modulen, Zahlung und Versand | Jede Commerce-Abhängigkeit hat einen Verantwortlicher. |
| Anpassungen erfassen | Entwicklungs-Verantwortlicher | Individuelle Erweiterungen, Template-Overrides, Snippets, API-/Webhook-Code und direkte Datenbankänderungen | Individuelles Verhalten, das Datensätze erzeugt oder interpretiert, ist dokumentiert. |
| Verbundene Systeme zuordnen | Integrations-Verantwortlicher | ERP-/PIM-/WMS-/CRM-/Accounting-/Fulfillment-/Marketplace-Endpunkte und externe IDs | Fortbestehende Systeme und Datenautoritäten sind bekannt. |
Erhalten Sie Product-, Varianten-, Category-, Tag-, Marken-, Collection-, Customer-, Order-, Coupon-, Review-, Refund-, Medien-, Joomla-Benutzer-, Menü- und externe IDs, die zur Nachverfolgung von Beziehungen benötigt werden.
Products, Varianten, Categories, Marken und Collections vorbereiten
EasyStore-Products können Namen, Aliase, Beschreibungen, Bilder, Video, Preise, Rabatte, Kosten, Steuerstatus, Kennungen, Bestand, Maße, Categories, Tags, Marken, Collections, Spezifikationen, Upsell-/Cross-Sell-Links, Zugriff, Metadaten und Varianten enthalten. Bereiten Sie Products nach Verkaufsverhalten und nicht nach Anzahl vor.
| Product-Muster | Vorzubereitender Nachweis | Freigabebedingung |
|---|---|---|
| Einfaches Product | Product-ID, SKU, Preis, Rabatt, Steuerstatus, Bestand, Category, Marke, Bilder und Beispiel-Order | Ein Datensatz identifiziert den verkauften Artikel eindeutig. |
| Varianten-Product | Variationstypen/-werte, erzeugte Varianten, SKU, Preis, Rabatt, Bestand, Gewicht, Paket, Bild und Sichtbarkeit je Variante | Jede reale verkaufbare Kombination ist zu Parent und ausgewählten Werten zurückverfolgbar. |
| Out-of-Stock- oder Preorder-Product | Bestandsstatus, Continue-Selling-Status, Release-Datum, Menge und verantwortliches Bestandssystem | Verfügbarkeit wird nicht auf leeres Feld oder Nullmenge reduziert. |
| Multi-Category- oder Collection-Product | Category-, Tag-, Marken-, Collection- und Kampagnenbeziehungen | Auffindbarkeit- und Merchandising-Strukturen werden nicht zu einer Taxonomie zusammengeführt. |
| Spezifikationsreiches Product | Additional-Data-Schlüssel/-werte, Darstellungszweck, Such-/Filternutzung und Product-Zuordnungen | Beschreibende Spezifikationen bleiben von Varianten getrennt. |
| Upsell-/Cross-Sell-Product | Quell-Product, verknüpfte Products, Beziehungstyp und Priorität | Merchandising-Beziehungen bleiben von Categories getrennt erhalten. |
Dokumentieren Sie unveröffentlichte, Featured-, Sale- und Restricted-Access-Products, Mindest-/Höchstmengen, Continue-Selling, Kennungen und Metadaten. Diese Zustände können unterschiedliche Zielbehandlung erfordern.
Variationsbibliotheken, Product-Optionen, Preise und Bestand vorbereiten
EasyStore-Variationstypen können über mehrere Products wiederverwendet werden; jede erzeugte Variante kann eigene SKU, standardisierte Kennungen, Preis, Rabatt, Steuerstatus, Versandpaket, Gewicht, Menge, Verfügbarkeit und Sichtbarkeit tragen. Product Options können außerdem Upsell- und Cross-Sell-Beziehungen tragen, während Additional Data Spezifikationen beschreibt.
| Struktur | Nachweis | Freigabebedingung |
|---|---|---|
| Variationstyp und Werte | Name, Darstellungstyp, Werte, Farbdaten, Reihenfolge und Product-Zuordnungen | Wiederverwendbares Variantenvokabular ist dokumentiert. |
| Erzeugte Variante | Parent Product, ausgewählte Werte, SKU, GTIN/UPC/EAN/ISBN, Preis, Rabatt, Bestand, Gewicht, Paket, Bild, Sichtbarkeit und externer Schlüssel | Jede gekaufte Kombination hat eigenständige Nachweise. |
| Product-Level-Pricing | Normalpreis, Rabatttyp/-wert, Steuerstatus, Base-Unit-Daten, Kosten und Währung | Parent-Werte ersetzen nicht variantenspezifische Werte. |
| Bestand | Product-/Variantenmenge, Tracking-Status, Bestandsstatus, Continue-Selling-Regel, Min-/Max-Menge und externer Verantwortlicher | Die autoritative verkaufbare Menge ist bekannt. |
| Additional Data | Schlüssel, Wert, Product-Zuordnungen, Darstellungszweck und externe Quelle | Spezifikationen bleiben von Käuferauswahl getrennt. |
| Upsell/Cross-Sell | Beziehungstyp, verknüpfte Product-IDs, Categories/Collections/Marken für die Auswahl | Merchandising-Beziehungen sind nachvollziehbar. |
Enthält der Quellkatalog sehr große Optionsmatrizen, dokumentieren Sie ursprüngliche Kombinationsanzahl und technische Umgebungsgrenzen. Gehen Sie nicht davon aus, dass jede theoretische Kombination eine reale verkaufbare Variante ist.
Customers, Joomla-Benutzer, Adressen, Bewertungen und Identität vorbereiten
EasyStore-Customers können mit Joomla-Benutzern, Orders, Adressen, Bewertungen, Unternehmens- oder Steuerdaten, Einwilligung und externen CRM-/ERP-Kennungen verbunden sein. Gastkäufer benötigen eigene Behandlung, weil ihre Order-Historie auch ohne dauerhaftes Konto wertvoll bleiben kann.
| Kontobereich | Nachweis | Verantwortlicher | Freigabebedingung |
|---|---|---|---|
| Registrierter Customer | Joomla-User-ID, EasyStore-Customer-ID, E-Mail, Status, Adressen und externe IDs | Customer-Data-Verantwortlicher | Dubletten und systemübergreifende Identitäten haben eine definierte Behandlung. |
| Gastkäufer | Order-Level-Identität, E-Mail, Adressen und Order-Verknüpfungen | Order-Data-Verantwortlicher | Gasthistorie bleibt erhalten, ohne ein Benutzerkonto zu erfinden. |
| Adresse | Billing-/Shipping-Werte, Land/Region, Default-Status und Customer-/Order-Zuständigkeit | Customer-Service-Verantwortlicher | Gespeicherte Adressen und historische Order-Snapshots sind unterscheidbar. |
| Bewertung | Product, Customer-/Gastidentität, Rating, Text, Status, Datum und Sprache | Katalog-/Content-Verantwortlicher | Bewertungen bleiben mit dem richtigen Product und Moderationsstatus verbunden. |
| Unternehmens-/Steuerinformationen | Unternehmen, Steuernummer, Validierungsstatus und externer Account-Schlüssel | Finanz-/B2B-Verantwortlicher | Geschäftsidentität hat ein benanntes Ziel oder einen fortbestehenden Verantwortlicher. |
| Authentifizierung | Lokales Passwort, SSO/Social Login, Reset-Ablauf und Kommunikations-Verantwortlicher | Security-Verantwortlicher | Kontozugriff ist geplant, ohne Passwortübertragbarkeit anzunehmen. |
Wählen Sie Customers mit mehreren Adressen, Gast-Orders, Bewertungen, Dubletten, wichtigen externen IDs und wertvoller Order-Historie aus.
Orders, Coupons, Erstattungen, Steuern, Versand und Zahlungsnachweise vorbereiten
Historische EasyStore-Orders sollten erklären, was gekauft wurde und was anschließend geschah. Bereiten Sie Order-Header, Customer oder Gast, Adressen, Product- und Variantenpositionen, Mengen, Preise, Rabatte, Coupons, Steuern, Versand, Zahlungsbezeichnungen, Status, Notizen, Tracking, Erstattungen, Rechnungen und externe Referenzen vor.
| Order-Nachweis | Verantwortlicher | Freigabebedingung |
|---|---|---|
| Order-Header und Statushistorie | Commerce Operations | Customer/Gast, Daten, Statusfolge, Währung und Quell-Channel sind dokumentiert. |
| Product- und Variantenpositionen | Katalog-/Order-Verantwortlicher | Parent Product, Variante, SKU, ausgewählte Werte, Menge und Snapshot-Text sind vollständig. |
| Coupons und Rabatte | Marketing-/Finanz-Verantwortlicher | Coupon-Code, Regel, Positions-/Order-Rabatt und historische Wirkung sind dokumentiert. |
| Steuer und Versand | Finanz-/Fulfillment-Verantwortlicher | Historische Steuerbeträge, Versandkosten, Methodenbezeichnung, Carrier und Tracking sind erhalten. |
| Zahlungskontext | Finanz-Verantwortlicher | Methodenbezeichnung, Transaktions-/Referenz-IDs, Status und Provider-Zuständigkeit sind bekannt. |
| Erstattungen und Anpassungen | Finanz-/Customer-Service-Verantwortlicher | Teil-/Vollerstattungen, betroffene Positionen, Daten, Gründe und externe Referenzen sind dokumentiert. |
| Externe Order-IDs | Integrations-Verantwortlicher | ERP-, Accounting-, Marketplace- oder Fulfillment-Kennungen bleiben nachvollziehbar. |
Aktive Coupon-, Steuer-, Versand-, Zahlungs-, Checkout- und Erstattungsverarbeitung gehört zur Zielkonfiguration. Historische Orders erhalten Nachweise vergangener Transaktionen und keine aktuellen Betriebsregeln.
Joomla-Menüs, SP Page Builder, Routen, Medien und SEO vorbereiten
EasyStore-Products können über Joomla Menu Items und SP-Page-Builder-Elemente dargestellt werden. Menüs, Page-Builder-Layouts, Template-Positionen, Product-Blöcke, Medien, Metadaten und Weiterleitungen benötigen daher explizite Vorbereitungsnachweise.
| Shop-Bereich | Nachweis | Freigabebedingung |
|---|---|---|
| Product- und Category-Routen | Quell-URL, Alias, Product-/Category-ID, Menükontext, Metadaten und Zielabsicht | Jede wichtige Commerce-Route hat eine Keep-, Change-, Merge-, Retire- oder Redirect-Entscheidung. |
| Joomla Menu Items | Menu-Item-Typ, Parent, Alias, Sprache, Zugriff, gewählte Category und Hierarchieverhalten | Shop-Einstiege und Category-Ansichten sind dokumentiert. |
| SP-Page-Builder-Layouts | Page-ID, EasyStore-Elementtypen, Filter, Product-Quellen, Custom Styling und verknüpfte Routen | Darstellungsabhängigkeiten sind von Commerce-Datensätzen getrennt. |
| Product-Medien | Bilder, Video, Alt-Kontext, Variantenmedien, Remote Assets und Dateipfade | Priorisierte Medien lassen sich dem richtigen Product oder der Variante zuordnen. |
| Verbundener CMS-Content | Landingpages, Buying Guides, Blog Posts, interne Links, Product-Blöcke und Kampagnen | Commerce-bezogener Content hat einen Verantwortlicher und eine Routenentscheidung. |
| SEO und Weiterleitungen | Metadaten-Verantwortlicher, Canonical-Daten, Sitemap-Quelle, Redirect-Regeln und wichtige URLs | Routen-Kontinuität hat einen expliziten Verantwortlicher. |
Das allgemeine Joomla-CMS-Inventar gehört zum Joomla-Umfang. Die EasyStore-Vorbereitung erfasst nur Joomla- und SP-Page-Builder-Beziehungen, die für Commerce-Daten und Routen benötigt werden.
Erweiterungen, Custom Data, Importe und externe Systeme inventarisieren
Erstellen Sie ein Abhängigkeits-Ledger für Zahlung, Versand, Steuern, Bewertungen, Analysen, Import/Export, SP-Page-Builder-Elemente, individuelle Felder, ERP, PIM, CRM, Accounting, Fulfillment und Marketplace-Verbindungen.
| Abhängigkeit | Vorzubereitender Nachweis | Freigabebedingung |
|---|---|---|
| EasyStore-Erweiterung/Integration | Name, Version, Zweck, Konfiguration, eigene Datensätze und verbundene Core-IDs | Erweiterungseigene Datensätze haben ein Ziel oder einen fortbestehenden Verantwortlicher. |
| SP-Page-Builder-Element | Elementtyp, Page-/Layout-IDs, Product-Quelle, Filter und individueller Code | Darstellungsstrukturen werden nicht mit Product-Daten verwechselt. |
| Import-/Export-Ablauf | Dateiformat, Spaltendefinitionen, Product-/Variantenkennungen, Beziehungen und letzter erfolgreicher Lauf | Exportdateien lassen sich mit autoritativen Datenbankdatensätzen abgleichen. |
| individuelles Feld/Tabelle | Schema, Schlüssel, Geschäftszweck und konsumierender Code | Individuelle Werte können interpretiert statt blind kopiert werden. |
| Externes System | Endpoint, autoritative Entitäten, Synchronisationsrichtung, IDs und Cutover-Verantwortlicher | Systemübergreifende Identität und Autorität sind dokumentiert. |
| Generierte Daten | Caches, Logs, Sessions, Indizes, abgebrochene Importe und temporäre Dateien | Nicht autoritative technische Daten werden bewusst ausgeschlossen. |
Inaktive Erweiterungen bleiben relevant, wenn ihre Datensätze weiterhin Orders, Products, Customers, Erstattungen oder Auswertungen unterstützen.
Repräsentative Migrationstest-Stichproben auswählen
Dokumentieren Sie Quell-IDs, SKUs, URLs, verbundene Datensätze, externe Schlüssel und den Auswahlgrund für jede Stichprobe.
| Stichprobe | Vorzubereitender Nachweis | Vorbereitungszweck |
|---|---|---|
| Einfaches Product | Preis, Steuer, Bestand, Category, Marke, Bilder und Order | Etabliert den normalen Product-Baseline-Fall. |
| Varianten-Product | Variationsbibliothek, erzeugte Varianten, SKUs, Preise, Bestand, Bilder, Sichtbarkeit und Order-Position | Repräsentiert Parent-Varianten-Beziehungen. |
| Spezifikations-/Merchandising-Product | Additional Data, Tags, Marke, Collection, Upsell/Cross-Sell und Product-Route | Repräsentiert beschreibende und Merchandising-Strukturen. |
| Registrierter Customer und Gast-Order | Joomla-/Customer-IDs, Adressen, Bewertungen, Order-Links und externe IDs | Repräsentiert beide Identitätsmodelle. |
| Komplexe Order | Variantenposition, Coupon, Steuer, Versand, Zahlung, Erstattung, Tracking und externe Referenz | Repräsentiert historischen Geschäftskontext. |
| SP-Page-Builder-Route | Seite/Layout, EasyStore-Elemente, Product-Quelle, Menülink, Medien, SEO und Redirect-Absicht | Repräsentiert Darstellungs- und Routingabhängigkeiten. |
| Datensatz eines externen Systems | Product-/Varianten-/Customer-/Order-ID, autoritatives System, Synchronisationsrichtung und Schlüssel | Macht Integrationszuständigkeit vor der Ausführung sichtbar. |
Die Vorbereitung repräsentativer Tests besitzt Auswahl und Nachweis der Stichproben. Der tatsächliche Migrationsnachweis und die Go-live-Interpretation gehören zum Validierungs-Workstream.
Abschließendes EasyStore-Bereitschaft-Gate durchführen
| Bereitschaft-Bereich | Freigabebedingung |
|---|---|
| Zugriff und Wiederherstellung | Joomla, EasyStore, Hosting, Datenbank, Dateien, Backups und Wiederherstellungsverantwortung sind bestätigt. |
| Katalog | Products, Varianten, Categories, Tags, Marken, Collections, Spezifikationen, Medien, Preise, Bestand und Kennungen sind dokumentiert. |
| Customers | Joomla-Benutzer, Customers, Gäste, Adressen, Bewertungen, Unternehmens-/Steuerdaten und Authentifizierungsabhängigkeiten sind klassifiziert. |
| Orders | Positionen, Varianten, Rabatte, Coupons, Steuern, Zahlung, Versand, Erstattungen, Tracking und externe IDs haben Nachweise. |
| Shop | Menüs, SP-Page-Builder-Layouts, Routen, Medien, verbundener Content, SEO und Weiterleitungen sind dokumentiert. |
| Abhängigkeiten | Erweiterungen, Importe, Custom Data, externe Systeme und autoritative Verantwortlicher sind erfasst. |
| Stichproben | Repräsentative Datensätze decken alle wesentlichen Product-, Customer-, Order-, Routen-, Erstattungs- und Integrationsmuster ab. |
Der EasyStore-Umfang ist bereit, wenn jeder ausgewählte Datensatz zu Quell-Verantwortlicher, verbundenen Datensätzen, Nachweisartefakt und vorgesehenem Ziel oder fortbestehendem System zurückverfolgt werden kann.
Fazit
Die Vorbereitung auf EasyStore erfordert koordinierte Nachweise über Joomla, Products, Varianten, Categories, Marken, Bestand, Customers, Orders, Coupons, Erstattungen, Bewertungen, SP Page Builder, URLs, Erweiterungen und externe Systeme. Ein Product-Export oder eine visuelle Shop-Prüfung allein kann diese Beziehungen nicht erklären.
Ein starkes Vorbereitungspaket sichert wiederherstellbare Backups, identifiziert autoritative Datensätze, trennt historische Transaktionen von Live-Konfiguration, wählt repräsentative Stichproben aus und weist jeder wesentlichen Abhängigkeit einen Verantwortlicher und eine Freigabebedingung zu.
Häufige Fragen
Was sollte für eine EasyStore-Migration zuerst vorbereitet werden?
Bestätigen Sie Zugriff auf Joomla, EasyStore, Hosting, Datenbank, Dateisystem, SP Page Builder und Integrationen. Erstellen Sie wiederherstellbare Backups und dokumentieren Sie die Erweiterungsumgebung, bevor die Katalogzuordnung beginnt.
Warum benötigen EasyStore-Varianten getrennte Nachweise vom Parent Product?
Jede Variante kann eigene SKU, standardisierte Kennung, Preis, Rabatt, Bestand, Gewicht, Paket, Sichtbarkeit und Bildbeziehung tragen. Reine Parent-Nachweise können deshalb die tatsächlich verkaufbaren Datensätze auslassen.
Wie sollten Categories, Marken, Collections und Tags vorbereitet werden?
Dokumentieren Sie jede Struktur separat, einschließlich Product-Zuordnungen und Shop-Nutzung. Ähnliche Bezeichnungen beweisen nicht, dass die Strukturen denselben Auffindbarkeit- oder Merchandising-Zweck erfüllen.
Welche Order-Nachweise sollten gesammelt werden?
Bereiten Sie Product- und Variantenpositionen, Customer- oder Gastidentität, Adressen, Rabatte, Coupons, Steuern, Zahlungs- und Versandkontext, Status, Tracking, Erstattungen und externe IDs vor, die Support oder Finanzen benötigen.
Warum sollte SP Page Builder Teil der Vorbereitung sein?
EasyStore-Elemente können Products, Categories, Filter, Bewertungen, Preise und Warenkorbfunktionen in Seitenlayouts auswählen und darstellen. Layouts und Datenquellen sind Darstellungsabhängigkeiten, keine gewöhnlichen Product-Felder.
Wie sollten Joomla- und EasyStore-Vorbereitung aufgeteilt werden?
Joomla-Vorbereitung besitzt allgemeine CMS-Inhalte, Benutzer, Menüs, Templates und Erweiterungen. EasyStore-Vorbereitung besitzt Products, Varianten, Customers, Orders, Erstattungen, Coupons, Bewertungen und Commerce-Integrationen und dokumentiert nur die dafür benötigten Joomla-Abhängigkeiten.