Wenn Cafe24 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 Cafe24 als Zielplattform ausgewählt werden soll, beginnt die Vorbereitung mit einer sauberen Trennung der Bereiche. Ein Cafe24-Konto kann einen Standard-Store, lokalisierte Stores, sprachspezifische Categories und Inhalte, Product-Sichtbarkeitsregeln, mehrere Optionsmodelle, Variantenbestände, Customer-Stufen sowie operative Apps oder externe Systeme umfassen. Diese Beziehungen bleiben leicht unsichtbar, wenn die Vorbereitung nur mit einem einzelnen Product- oder Order-Export beginnt.
Ziel ist ein belastbarer Quellnachweis, der zeigt, welcher Store, welche Sprache, welche Customer-Stufe, welches Product-Optionsmodell und welches externe System für ein bestimmtes Verhalten verantwortlich ist. Für jeden wesentlichen Bereich sollten Maßnahme, Verantwortlicher, Nachweis und Freigabebedingung feststehen, bevor die Migrationskonfiguration endgültig festgelegt wird.
Zugriff sicherstellen und Cafe24-Store-Umfang definieren
Dokumentieren Sie das genaue Cafe24-Konto, Standard- und lokalisierte Stores, Domains, aktive Sprachen, Währungen, regionalen Betriebskontext, Administratorrollen und die Teams für Katalog, Customers, Orders, Content, Datenschutz, Steuern, Fulfillment und Integrationen. Klären Sie außerdem, welche Informationen lokalisierter Stores vom Standard-Store geerbt und welche unabhängig bearbeitet wurden.
| Maßnahme | Verantwortlicher | Nachweis | Freigabebedingung |
|---|---|---|---|
| Standard- und lokalisierte Stores auflisten | Plattformadministrator | Store-Liste, Domains, Sprachen, Währungen, Status | Jeder einbezogene Store hat eine dokumentierte Rolle. |
| Zugriff auf die Quelle bestätigen | Zugriffsverantwortlicher | Administratorzugriff, Exportberechtigungen, technischer Kontakt | Erforderliche Quelldaten können erhoben werden. |
| Vererbung und Lokalisierung erfassen | Content- und Katalogverantwortliche | Vergleich von Product-, Category-, Content- und Einstellungsdaten | Gemeinsame und lokalisierte Informationen sind unterscheidbar. |
| Regionale Verantwortlichkeiten identifizieren | Legal-, Finance- und Operations-Verantwortliche | Notiz zu Steuer-, Datenschutz-, Versand-, Zahlungs- und Fulfillment-Verantwortung | Regionale Einstellungen haben benannte Verantwortliche. |
| Aktive Apps und Integrationen inventarisieren | Systemverantwortlicher | App-Liste, Zweck, Datenobjekte, Status | Nicht-native Daten und Abläufe sind sichtbar. |
| Änderungsprotokoll beginnen | Projektverantwortlicher | Datierte Änderungen an Katalog, Customers, Orders, URLs und Konfiguration | Der Nachweisbestand bleibt aktuell. |
Products, Optionen, Varianten und Bestand vorbereiten
Cafe24 unterstützt mehrere Product-Optionsmodelle. Voreingestellte oder Mehrfachoptionen können Varianten aus Optionskombinationen erzeugen. Bei unabhängiger Auswahl werden Optionswerte einzeln hinzugefügt; benutzerdefinierte Auswahl kann verpflichtende oder optionale Käuferentscheidungen erfassen und Product-bezogenen statt variantenbezogenen Bestand verwenden. Freitext- und Dateiupload-Felder können ebenfalls kaufbezogene Informationen aufnehmen.
Bereiten Sie Product-Nummer, Product-Code, individuellen Product-Code, Name, Status, Anzeige- und Verkaufsbereich je Store, Category-Zuordnung, Preis, Steuer, Bilder, Beschreibungen, Optionsmodell, Optionswerte, Variantencode, individuellen Variantencode, Bestandseinstellungen, Grundlage des Bestandsabzugs, Zusatzkosten, Freitext-/Dateieingaben und externe Kennungen vor.
| Product-Muster | Vorbereitungsmaßnahme | Nachweis | Freigabebedingung |
|---|---|---|---|
| Product mit voreingestellten oder Mehrfachoptionen | Optionsnamen, Werte, Kombinationen, Variantencodes, Preis, Bestand, Anzeige- und Verkaufsstatus erfassen | Product- und Bestands-Exports | Bedeutung auf Kombinationsebene ist vollständig. |
| Product mit unabhängiger Auswahl | Pflicht-/optionale Werte, individuelles Kaufverhalten und Bestandsgranularität erfassen | Product-Seite und Order-Zeilen | Einzeln gewählte Optionen werden nicht als eine Variante missverstanden. |
| Product mit benutzerdefinierter Auswahl | Eingaberegeln, Pflichtstatus, Preiseffekt und Product-bezogenes Bestandsverhalten erfassen | Product- und Order-Beispiele | Käuferspezifische Auswahl hat einen definierten Verantwortlichen. |
| Freitext oder Dateiupload | Zweck des Felds, Pflichtstatus, Verantwortlicher für Dateiaufbewahrung und Order-Beziehung erfassen | Product-Einstellungen und historische Orders | Kaufbezogene Eingaben sind im Quellnachweis repräsentiert. |
| Lokalisiertes Product | Standard- und lokalisierte Titel, Beschreibungen, Preise sowie Anzeige-/Verkaufseinstellungen erfassen | Store-übergreifender Product-Vergleich | Lokalisierung und Store-Scope sind explizit. |
| Bestandsausnahme | Bestandstyp, Abzugsgrundlage, Negativ-/Sold-out-Verhalten und Mindestbestand erfassen | Bestands-Export und Ausnahmeliste | Bedeutung der Verfügbarkeit ist dokumentiert. |
Optionsbezeichnungen und Variantencodes sollten nicht vereinheitlicht oder zusammengeführt werden, bevor der fachliche Verantwortliche bestätigt, dass die Datensätze in allen Stores und Orders tatsächlich dieselbe Bedeutung haben.
Categories, Anzeigeregeln, Navigation und SEO-Pfade vorbereiten
Cafe24-Categories können verschachtelt sein, storespezifische übersetzte Namen besitzen, Anzeige- und Verkaufskontext steuern, verschiedene Product-Layoutbereiche verwenden und den Zugriff nach Konto oder Customer-Stufe begrenzen. Category-Datensätze und Storefront-Navigation sollten als zusammenhängende, aber getrennte Nachweise vorbereitet werden.
| Auffindbarkeit-Bereich | Verantwortlicher | Nachweis | Freigabebedingung |
|---|---|---|---|
| Category-Hierarchie | Katalogverantwortlicher | Parent-Child-Baum, Status, Product-Zuordnungen | Jede erhaltene Category hat einen bekannten Parent und Zweck. |
| Lokalisierte Category-Information | Content-Verantwortlicher | Standard-/lokalisierte Namen, Beschreibungen, Routen | Übersetzungsumfang ist dokumentiert. |
| Product-Layoutbereiche | Merchandising-Verantwortlicher | Zuordnung von Products, Recommended Products und New Products | Anzeigeplatzierung wird nicht allein aus Category-Mitgliedschaft abgeleitet. |
| Zugriffsbeschränkungen | Customer-/B2B-Verantwortlicher | Beispiele für Account-only, Customer-Level, Admin-only, Adult- oder IP-Regeln | Eingeschränkte Auffindbarkeit hat einen benannten Regelverantwortlichen. |
| Menüs und Theme-Navigation | Storefront-Verantwortlicher | Navigationskarte, Screenshots, verknüpfte Categories und Seiten | Präsentationspfade sind von Category-Daten getrennt. |
| SEO-Routen | SEO-Verantwortlicher | Category-/Product-URLs, Metadaten, Prioritätsrouten, Redirects | Hochwertige Pfade haben eine definierte Behandlung. |
Customers, Customer-Stufen, Konten und Einwilligungsnachweise vorbereiten
Cafe24 kann registrierte Customers, Käufer ohne Konto, Customers mit Kaufhistorie, Customer-Stufen, Registrierungsfelder, Datensätze gelöschter Konten und automatisierte Kommunikation verwalten. Bereiten Sie Customer-Identität und Segmentierung nach ihrem tatsächlichen Geschäftszweck vor.
Erfassen Sie Customer-Nummer/-ID, Name, E-Mail, Login-/Kontostatus, Sprache oder Store, Adressen, Registrierungsfelder, Customer-Stufe, Bezug zur Kaufhistorie, Einwilligungs- und Kommunikationsstatus, Steuer-/Unternehmensinformationen, Punkte-/Guthabenkontext soweit genutzt und externe Kennungen.
| Customer-Muster | Vorbereitungsmaßnahme | Nachweis | Freigabebedingung |
|---|---|---|---|
| Registrierter Customer | Identität, Store, Kontostatus, Adressen und Stufe erfassen | Customer- und Order-Beispiele | Kontoverantwortung ist klar. |
| Gastkäufer | Order-Identität erfassen, ohne registriertes Konto zu unterstellen | Gast-Order-Set | Gast-Historie bleibt getrennt. |
| Customer mit Stufe | Bedeutung der Stufe, Vorteile, Rabatte, Zugriffsregeln und Verantwortlichen erfassen | Customer-Level-Regelmatrix | Segmentierung hat dokumentierte Geschäftslogik. |
| Individuelle Registrierungsfelder | Jedes Feld nach Zweck, Sensibilität und Downstream-Nutzung klassifizieren | Feldwörterbuch | Erforderlicher Kontokontext hat eine Behandlung. |
| Gelöschtes/inaktives Konto | Aufbewahrungsgrund und zugehörige Order-Historie erfassen | Ausnahmeregister | Historische Identität wird bewusst behandelt. |
| Customer in externem System | CRM-, ERP-, Zahlungs-, Fulfillment- oder Support-Kennungen erfassen | Integrationsreferenzen | Lookup-Schlüssel bleiben nachvollziehbar. |
Sensible Customer-Felder sollten auf den vereinbarten Umfang begrenzt und gemäß Datenschutz- und Zugriffskontrollen des Unternehmens behandelt werden.
Orders, Zahlungen, Erstattungen und Fulfillment-Kontext vorbereiten
Die Order-Vorbereitung sollte Beispiele aus verschiedenen Stores, Sprachen, Customer-Zuständen, Product-Optionsmodellen, Zahlungsmethoden, Versandarten, Steuerkontexten, Rabatten, Punkten, Erstattungen, Stornierungen, Umtausch, Retouren und Fulfillment-Zuständen umfassen. Im Bereich All Orders können Orders nach Zeitraum und Geschäftsszenario gefunden und exportiert werden; speichern Sie die verwendeten Filter und Zeiträume für jede Datei.
| Order-Bereich | Maßnahme | Nachweis | Freigabebedingung |
|---|---|---|---|
| Store und Sprache | Store, Locale, Währung und Customer-Kontext einschließen | Store-übergreifende Order-Beispiele | Jede Order ist in ihrem ursprünglichen Store-Kontext interpretierbar. |
| Product-Auswahl | Optionswerte, Variantencodes, individuelle Eingaben, Menge, Preis und Product-Text einschließen | Repräsentative Order-Zeilen | Gekaufte Konfiguration bleibt verständlich. |
| Status und Fulfillment | Statuslabels, Zahlungsstatus, Versandstatus, Tracking, Storno-, Retouren- und Umtauschkontext erfassen | Statuswörterbuch und Orders | Historischer Ablauf ist interpretierbar. |
| Summen | Product-Betrag, Optionsaufschlag, Steuer, Versand, Rabatt, Punkte, Erstattung und Gebühren identifizieren | Beispiele der Summenbestandteile | Finanzieller Kontext ist vollständig. |
| Adressen | Aktuelle Customer-Adressen von Billing-/Shipping-Snapshots der Order trennen | Customer- und Order-Beispiele | Aktuelle Kontodaten werden nicht mit Historie vermischt. |
| Externe Referenzen | Zahlungs-, Logistik-, Marketplace-, ERP-, Accounting- und Support-IDs erfassen | Integrationssensitive Orders | Systemübergreifende Lookup-Anforderungen sind dokumentiert. |
Historische Zahlungs- und Versanddaten beschreiben vergangene Transaktionen. Sie konfigurieren keine aktiven Zahlungs-Gateways, Steuern, Versand- oder Fulfillment-Regeln im Ziel.
Content, Themes, lokalisierte Seiten und Medien vorbereiten
Bereiten Sie Seiten, Richtlinien, Product- und Category-Content, Homepage-Bereiche, Banner, Themes, mobile Darstellung, Formulare, Bilder, Download-Dateien, Metadaten, interne Links und lokalisierte Versionen vor. Cafe24-Themes können konfigurierten Content und Quellcode-Anpassungen enthalten; der Theme-Verantwortliche sollte deshalb Daten oder Geschäftslogik identifizieren, die in Templates eingebettet sind.
| Content-Bereich | Verantwortlicher | Nachweis | Freigabebedingung |
|---|---|---|---|
| Seiten und Richtlinien | Content-/Legal-Verantwortlicher | Seiteninventar, Store, Sprache, Status, Route | Entscheidungen zu Erhalt, Neubau, Zusammenführung oder Ausschluss sind dokumentiert. |
| Product- und Category-Content | Katalogverantwortlicher | Standard-/lokalisierte Exporte oder Beispiele | Content lässt sich dem richtigen Datensatz und Store zuordnen. |
| Theme-Bereiche | Theme-Verantwortlicher | Theme-Backup/-Quellbestand, individuelle Bereiche, Screenshots | Präsentationsbezogener Content ist sichtbar. |
| Medien | Content-Verantwortlicher | Originaldateien, Pfade, Product-/Seitenbeziehungen | Quellmaterialien sind verfügbar. |
| SEO-Metadaten und Routen | SEO-Verantwortlicher | Titel, Beschreibungen, URLs, Canonical-Erwartungen, interne Links | Suchkontext begleitet den Content-Nachweis. |
Apps, APIs, Webhooks und externe Systeme inventarisieren
Erstellen Sie ein Abhängigkeitsregister für Cafe24-Apps, API-Integrationen, Webhooks, Marketplaces, Zahlungsdienste, Versand-/Logistikprovider, ERP, Accounting, CRM, Warehouse, Analysen, Marketing, Reviews und individuellen Code. Dokumentieren Sie, welchen Store und welche Sprache jede Abhängigkeit betrifft.
| Feld der Abhängigkeit | Erforderliches Detail | Freigabebedingung |
|---|---|---|
| Verantwortlicher und Zweck | Business-/Technikverantwortliche, unterstützter Ablauf | Zuständigkeit ist explizit. |
| Store-Scope | Standard-Store, lokalisierter Store oder alle Stores | Regionale Verantwortung ist bekannt. |
| Datenobjekte | Products, Varianten, Bestand, Customers, Orders, Content oder Einstellungen | Betroffene Nachweise sind identifiziert. |
| Richtung und Timing | Lesen, Schreiben, bidirektional, geplant, eventgetrieben oder manuell | Datenautorität ist dokumentiert. |
| Kennungen | Product-Code, Variantencode, Customer-ID, Order-Nummer, externer Schlüssel | Lookup-Abhängigkeiten bleiben erhalten. |
| Übergangsentscheidung | Wieder verbinden, neu bauen, stilllegen, ersetzen oder prüfen | Kontinuität wird nicht vorausgesetzt. |
Exporte, Medien, Backups und Change Control vorbereiten
Erstellen Sie datierte Quellarchive für Products, Optionen, Varianten, Bestand, Categories, Customers, Orders, Content, Apps und Integrationsfelder. Speichern Sie Filterkriterien, Store-/Sprach-Scope, ausgewählte Spalten, Zeiträume und Prüfsummen. Originalexporte bleiben unverändert; für Bereinigung werden Arbeitskopien verwendet.
| Nachweisbestand | Erforderliche Inhalte | Freigabebedingung |
|---|---|---|
| Product- und Bestandsdateien | Product-, Options-, Varianten-, Bestands-, Store- und Category-Felder | Katalog- und Verfügbarkeitsnachweis ist vollständig. |
| Customer- und Order-Dateien | Store, Kontostatus, Stufen, Adressen, Orders, Status, Summen und externe IDs | Historische Beziehungen sind zuordenbar. |
| Content- und Theme-Archiv | Seiten, lokalisierter Content, Medien, Theme-Backup/-Quellbestand | Präsentation und Quellmaterial sind verfügbar. |
| Abhängigkeitsnachweis | App-Liste, API-/Webhook-Notizen, Felder externer Systeme | Nicht-native Verantwortung ist dokumentiert. |
| Backup- und Supportnotiz | Verfügbare Account-Backups, Exportarchiv, Medienarchiv, technische Kontakte | Quelldaten können wiederhergestellt werden. |
| Änderungsprotokoll | Neue/geänderte Products, Customers, Orders, URLs, Apps und Einstellungen | Spätere Quelländerungen können abgeglichen werden. |
Repräsentative Testdatensätze für die Migration auswählen
| Beispielgruppe | Einzubeziehen | Zweck der Vorbereitung |
|---|---|---|
| Products | Einfaches Product, Kombinationsvariante, unabhängige Option, benutzerdefinierte Auswahl, Datei-/Texteingabe, lokalisiertes Product, Bestandsausnahme | Unterschiedliche Katalogmodelle sichtbar machen. |
| Customers | Registriert, Gast, Customer-Level-Mitglied, Konto mit individuelles Feld, gelöschte/inaktive Ausnahme, Customer mit externer ID | Unterschiede in Identität und Segmentierung abdecken. |
| Orders | Verschiedene Stores, Optionsmodelle, Zahlungs-/Fulfillment-Zustände, Erstattung, Retoure/Umtausch, Rabatt/Punkte, externe Referenz | Historischen Betriebskontext erhalten. |
| Auffindbarkeit und Content | Lokalisierte Category, eingeschränkte Category, Product-Layoutplatzierung, Theme-Seite, Prioritäts-URL | Storefront- und Routenbeziehungen vorbereiten. |
| Integrationen | Product, Customer oder Order, das/die von App, API, Webhook oder externem System berührt wird | Systemübergreifende Kennungen einbeziehen. |
Verfassen Sie für jedes Beispiel eine kurze Quellerwartung. Darin sollten Store, Sprache, Beziehung, relevante Felder, verknüpfte Dateien und Kennungen stehen, die den Datensatz repräsentativ machen.
Abschließendes Cafe24-Bereitschaft-Gate
| Abschlussprüfung | Freigabebedingung |
|---|---|
| Store-Scope | Standard-/lokalisierte Stores, Sprachen, Domains, Vererbung und regionale Verantwortliche sind dokumentiert. |
| Products | Optionsmodelle, Varianten, Codes, Bestand, Store-Scope, Content und externe IDs sind repräsentiert. |
| Auffindbarkeit | Categories, Layoutbereiche, Beschränkungen, Navigation, lokalisierte Routen und SEO-Inputs sind vorbereitet. |
| Customers | Registrierte, Gast-, Level-, Custom-Field-, gelöschte und externe-ID-Fälle sind verstanden. |
| Orders | Store, Sprache, Product-Auswahl, Status, Fulfillment, Summen, Erstattungen und externe Referenzen sind interpretierbar. |
| Content | Seiten, Themes, Medien, Lokalisierung, Metadaten und Routen sind dokumentiert. |
| Abhängigkeiten | Apps, APIs, Webhooks, Marketplaces und externe Systeme haben Verantwortliche und eine Zielbehandlung. |
| Inputs | Exporte, Filterkriterien, Assets, Backups, Prüfsummen, Kontakte und Änderungsprotokoll sind vorhanden. |
| Beispiele | Repräsentative Migrationsdatensätze decken gewöhnliche und komplexe Quellmuster ab. |
Fazit
Die Cafe24-Vorbereitung muss Store-, Sprach-, Product-Options-, Customer-Level-, Bestands- und Order-Kontext sichern, bevor Datensätze bewegt werden. Genau diese Beziehungen bestimmen, ob exportierte Daten außerhalb des Quellkontos weiterhin richtig interpretiert werden können.
Sind Zugriff, lokalisierter Scope, Quelldatennachweise, Integrationen, repräsentative Datensätze und Change Control vollständig, kann die Migrationskonfiguration auf dokumentiertem Cafe24-Verhalten statt auf einer flachen Datensatzanzahl aufbauen.
Häufige Fragen
Sollten Standard- und lokalisierte Cafe24-Stores separat vorbereitet werden?
Ja. Dokumentieren Sie, welche Informationen vom Standard-Store geerbt werden und welche Product-, Category-, Content-, Preis-, Sichtbarkeits- oder Routenwerte lokalisiert wurden.
Warum müssen die Cafe24-Optionsmodelle dokumentiert werden?
Kombinations-, unabhängige und benutzerdefinierte Auswahl kann unterschiedliches Product-, Bestands- und Order-Verhalten erzeugen. Eine generische Optionsliste erhält diese Unterschiede nicht.
Welche Bestandsfelder sind besonders wichtig?
Bereiten Sie Product- und Variantencodes, Trackingstatus, verfügbaren Bestand, Abzugsgrundlage, Mindestbestand, Anzeige-/Verkaufsstatus, Zusatzkosten und das System vor, das aktuelle Mengen führt.
Wie sollten Customer-Stufen vorbereitet werden?
Dokumentieren Sie Mitgliedschaft, Geschäftszweck, Rabatte, Zugriffsbeschränkungen, Vorteile, betroffene Stores und die Person bzw. das Team, das jede Stufe fachlich erklären kann.
Welche Orders sollten als Beispiele gewählt werden?
Wählen Sie unterschiedliche Stores und Sprachen, Optionsmodelle, Zahlungs-/Fulfillment-Zustände, Rabatte/Punkte, Erstattungen, Retouren/Umtausch, Gast- und registrierte Customers sowie externe Referenzen.
Wie sollten Änderungen der Quelle nach dem Export behandelt werden?
Führen Sie ein datiertes Protokoll für Products, Varianten, Bestand, Customers, Orders, URLs, Apps und regionale Einstellungen, damit Änderungen mit dem vorbereiteten Nachweisbestand abgeglichen werden können.