Die Vorbereitung einer AmeriCommerce-Migration sollte den Quellshop verständlich machen, bevor die Migrationskonfiguration endgültig festgelegt wird. Eine Installation kann mehrere Storefronts, Einschränkungen durch aktive Kataloge, Customer Types, Varianten, Product Groups, Kits, erweiterte Preisregeln, benutzerdefinierte Felder, Inhalte und externe Systeme miteinander verbinden. Ein Datenexport kann zeigen, welche Datensätze vorhanden sind. Er erklärt jedoch nicht, welchem Storefront ein Datensatz zugeordnet ist, welche Käuferregel seine Nutzung verändert oder welcher Identifier für ein anderes System weiterhin verfügbar bleiben muss.
Ziel der Vorbereitung ist es, diese Beziehungen in kontrollierte Quelldokumentation zu überführen. Für jeden wesentlichen Bereich sollten die auszuführende Maßnahme, die verantwortliche Person oder Funktion, der erforderliche Nachweis und die Bedingung für die Einsatzbereitschaft festgehalten werden. Dadurch bleibt der Ausgangszustand eindeutig dokumentiert, bevor die Migrationskonfiguration beginnt.
Zugriff sicherstellen und die Betriebsgrenzen von AmeriCommerce definieren
Dokumentieren Sie zunächst das genaue AmeriCommerce-Konto und jeden Store, der zum Migrationsumfang gehört. Erfassen Sie administrativen Zugriff, Store-IDs, aktive Domains, Währungen, Sprachen, steuerlichen Kontext, die Zuständigkeit für das aktuelle Theme sowie die Verantwortlichen für Katalog, Customers, Orders, Marketing und Integrationen. Wenn mehrere Stores Daten gemeinsam nutzen oder unterschiedliche aktive Kataloge verwenden, muss aus der Vorbereitung hervorgehen, welche Einstellungen und Datensätze kontoweit gelten und welche Store-spezifisch sind.
AmeriCommerce-Exporte können nach Store gefiltert und auf ausgewählte Spalten begrenzt werden. Speichern Sie die verwendeten Kriterien für jeden Export, damit sich eine spätere Datei einem bestimmten Store, Datum und Feldsatz zuordnen lässt. Gehen Sie nicht davon aus, dass ein zusammengeführter Export die Store-Zuordnung automatisch bewahrt.
| Maßnahme | Verantwortlich | Nachweis | Bereit, wenn |
|---|---|---|---|
| Alle Stores und Domains im Umfang auflisten | Commerce-Administrator | Store-Liste, IDs, Domains, Status, Geschäftszweck | Jeder einbezogene Store hat eine benannte Rolle und einen Verantwortlichen. |
| Unterstützten Quellzugriff bestätigen | Zugriffsverantwortlicher | Dokumentierter Admin-Zugriff, Exportberechtigungen, technischer Ansprechpartner | Erforderliche Datensätze können aus dem richtigen Konto erfasst werden. |
| Gemeinsame und Store-spezifische Funktionsweisen dokumentieren | Plattformverantwortlicher | Store-Vergleich für Kataloge, Preise, Inhalte und Einstellungen | Gemeinsame Daten lassen sich von Store-spezifischen Daten unterscheiden. |
| Exportkriterien festschreiben | Datenverantwortlicher | Exportname, Store-Filter, Datum, ausgewählte Spalten, Datei-Hash | Jede Quelldatei kann reproduziert und erklärt werden. |
| Änderungsprotokoll für die Quelle beginnen | Projektverantwortlicher | Datiertes Protokoll zu Änderungen an Katalog, Customers, Orders, URLs und Integrationen | Änderungen nach der Beweiserfassung werden nicht übersehen. |
Products, Varianten, Groups, Kits und Preisbeziehungen vorbereiten
AmeriCommerce-Products können Varianten, variantenbezogenen Bestand, Product Groups, Kits, erweiterte Preise, Mengenregeln, Customer-Type-Preise und benutzerdefinierte Felder verwenden. Diese Strukturen dürfen bei der Vorbereitung nicht auf eine einzige Product-Zeile reduziert werden. Das Team muss unterscheiden, welche Datensätze verkaufbare Auswahlmöglichkeiten darstellen, welche der gruppierten Darstellung dienen und welche von einer Preis- oder Bestandsbeziehung abhängen.
Erstellen Sie ein Product-Inventar mit Product-ID, Artikelnummer oder SKU, Status, Store-Sichtbarkeit, Zuordnung zum aktiven Katalog, Categories, Hersteller, Basispreis, Steuerklasse, Menge, Gewicht, Bildern, Inhalten, Varianten, Product-Group-Beziehungen, Kit-Komponenten, Preisregeln und externen Identifiern. Wählen Sie Beispiele aus jedem wesentlich unterschiedlichen Product-Muster aus.
| Quellmuster | Vorbereitungsmaßnahme | Nachweis | Bereit, wenn |
|---|---|---|---|
| Product-Varianten | Variant Groups, Werte, Anzeigereihenfolge, Pflichtstatus, Preiseffekte und Product-Zuordnung erfassen | Variantenexport und repräsentative Product-Seiten | Auswahlvokabular und Product-Zuordnung sind vollständig. |
| Variantenbestand | Kombinationsebene mit SKU, Menge, Preis, Bild, Gewicht und Status erfassen, sofern verwendet | Kombinationsmatrix und Bestandsstichprobe | Eigenständig verwaltete verkaufbare Kombinationen sind sichtbar. |
| Product Groups | Parent-/Child-Products, Gruppentyp, Verkaufbarkeit, Preise, Bestand und Versandlogik erfassen | Export der Gruppenbeziehungen und Screenshots | Gruppierung wird nicht mit einer einfachen Variante verwechselt. |
| Kits oder zusammengestellte Angebote | Komponenten-Products, Mengen, Preislogik, Bestandsannahmen und Hinweise zur Auftragsabwicklung erfassen | Kit-Liste und Komponentenbeispiele | Bedeutung der Komponenten und operative Zuständigkeit sind dokumentiert. |
| Erweiterte Preise oder Customer-Type-Preise | Käufergruppe, Mengenschwelle, Datumsgrenzen, Formel oder Betrag und betroffene Products erfassen | Matrix der Preisregeln | Bedingte Preise sind ausdrücklich dokumentiert und werden nicht aus Bezeichnungen abgeleitet. |
| Benutzerdefinierte Product-Felder | Jedes Feld als beschreibend, operativ, integrationsbezogen oder veraltet klassifizieren | Feldverzeichnis mit Beispielwerten | Geschäftskritische Felder haben eine festgelegte Behandlung und einen Verantwortlichen. |
Fassen Sie ähnlich benannte Optionen oder Preisregeln nicht nur zur Vereinfachung der Quelle zusammen. Zwei Bezeichnungen können gleich wirken und sich dennoch nach Store, Customer Type, Bestandszuständigkeit oder Nutzung durch externe Systeme unterscheiden.
Storefronts, aktive Kataloge, Categories und Auffindbarkeit dokumentieren
AmeriCommerce kann den sichtbaren Katalog je Store über Active-Catalog-Einstellungen einschränken. Customer Types können außerdem die Product-Sichtbarkeit, Inhalte, Weiterleitungen, Rabatte und Versandlogik beeinflussen. Für die Vorbereitung reicht deshalb ein Category-Baum allein nicht aus. Erforderlich ist eine Sichtbarkeitsübersicht, die zeigt, welche Käufer in welchem Store welche Products finden können.
Bereiten Sie die Category-Hierarchie mit IDs, Parent-Beziehungen, Status, Store-Zuordnung, Active-Catalog-Status, Product-Zuordnungen, Inhalten, Bildern, Sortierreihenfolge und wichtigen URLs vor. Dokumentieren Sie Navigationsmenüs, Landingpages, Herstellerpfade, attributbasierte Suche und interne Links getrennt von den zugrunde liegenden Category-Datensätzen.
| Bereich der Auffindbarkeit | Verantwortlich | Nachweis | Bereit, wenn |
|---|---|---|---|
| Aktiver Katalog je Store | Plattformadministrator | Store-spezifische Active-Catalog-Screenshots oder Export | Die sichtbare Category-Grenze jedes Stores ist dokumentiert. |
| Category-Hierarchie | Katalogverantwortlicher | Parent-Child-Export und Liste der zu übernehmenden Categories | Jede beizubehaltende Category hat einen bekannten Parent und Zweck. |
| Product-Platzierung | Merchandising-Verantwortlicher | Nachweise zur Product-to-Category- und Store-Zuordnung | Gemeinsame Platzierungen und Store-Einschränkungen sind sichtbar. |
| Sichtbarkeit nach Customer Type | B2B- oder Account-Verantwortlicher | Beispiele eingeschränkter Products und Categories | Zugriffsregeln für Käufer sind mit tatsächlichen Datensätzen verknüpft. |
| Menüs und Landingpages | Storefront-Verantwortlicher | Navigationsübersicht, Screenshots und verknüpfte Routen | Darstellungswege sind von der Katalogstruktur getrennt dokumentiert. |
| Priorisierte URLs | SEO-Verantwortlicher | Liste wichtiger Product-, Category-, Inhalts- und Kampagnenrouten | Für hochwertige Routen ist eine Behandlung festgelegt. |
Customers, Customer Types, Konten und Adressen vorbereiten
AmeriCommerce-Customer-Types können Preise, Rabatte, Login-Weiterleitungen, Rewards, benutzerdefinierte Inhalte, Versandmethoden und ausgeblendete Products beeinflussen. Ein Customer Type sollte deshalb als Beziehung zu Geschäftsregeln vorbereitet werden und nicht nur als Gruppenname. Dokumentieren Sie, welche aktiven Customers jedem Typ angehören und was der jeweilige Typ verändert.
Bereiten Sie Customers mit IDs, Namen, E-Mail-Adressen, Login-Status, Rechnungs- und Lieferadressen, Firmendaten, Customer Type, Steuerstatus, Newsletter- oder Kommunikationsstatus, benutzerdefinierten Feldern, Sales- oder Account-Zuständigkeit und externen Identifiern vor. Identifizieren Sie doppelte E-Mail-Adressen, gemeinsam genutzte Firmenadressen, inaktive Konten und Datensätze, deren Customer Type nicht mehr der aktuellen geschäftlichen Nutzung entspricht.
| Customer-Bereich | Vorbereitungsmaßnahme | Nachweis | Bereit, wenn |
|---|---|---|---|
| Identität | Doppelte und gemeinsam genutzte E-Mail-Muster auflösen oder dokumentieren | Register für Customer-Ausnahmen | Identitätsausnahmen haben einen Verantwortlichen und eine festgelegte Behandlung. |
| Customer Types | Mitgliedschaften sowie alle betroffenen Preis-, Sichtbarkeits-, Weiterleitungs-, Versand- oder Inhaltsregeln erfassen | Customer-Type-Regelmatrix | Für jeden Typ ist seine geschäftliche Bedeutung dokumentiert. |
| Adressen | Wiederverwendbare Customer-Adressen von den zum Bestellzeitpunkt gespeicherten Adresskopien trennen | Beispiele für Customer- und Order-Adressen | Aktuelle Kontodaten werden nicht mit Transaktionshistorie vermischt. |
| Steuer- und Befreiungskontext | Status, Verantwortlichen für Nachweise und betroffene Customers erfassen | Stichprobenliste zum Steuerstatus | Sonderbehandlungen bei Steuern werden nicht auf ein Label reduziert. |
| Benutzerdefinierte Felder und externe IDs | Systemverantwortung und nachgelagerte Nutzung identifizieren | Feldverzeichnis und Integrationsreferenzen | Operative Identifier bleiben rückverfolgbar. |
Orders, Status, Summen und historischen Kontext vorbereiten
Die Order-Vorbereitung sollte die Nachweise bewahren, die Kundenservice, Finanzwesen, Auftragsabwicklung und Account-Teams benötigen. Wählen Sie Orders aus jedem Store aus und schließen Sie Beispiele mit Varianten, Product Groups oder Kits, Customer-Type-Preisen, Rabatten, Steuerabweichungen, geteilten oder ungewöhnlichen Versandfällen, Rückerstattungen, Stornierungen, manuellen Anpassungen, Notizen und externen Referenzen ein.
Speichern Sie die Exportkriterien für Orders und nehmen Sie die Felder auf, die zur Interpretation von Positionen, Adressen, Status, Zahlungs- und Versandbezeichnungen, Steuern, Rabatten, Gebühren und Summen erforderlich sind. Historische Bezeichnungen sind als Quellkontext zu dokumentieren. Sie sind keine Anweisung dafür, wie Zahlungen oder Versand in der Zielplattform live eingerichtet werden sollen.
| Order-Bereich | Maßnahme | Nachweis | Bereit, wenn |
|---|---|---|---|
| Store-Zuordnung | Store-Identifier in die Order-Nachweise aufnehmen | Store-übergreifende Liste von Order-Stichproben | Jede Stichprobe kann dem richtigen Store zugeordnet werden. |
| Statushistorie | Bezeichnungen, Reihenfolge, interne Bedeutung und Kundensichtbarkeit erfassen | Statusverzeichnis und repräsentative Orders | Historische Zustände lassen sich konsistent interpretieren. |
| Positionsdetails | Ausgewählte Varianten, Kit- oder Group-Kontext, Menge, SKU und Preis aufnehmen | Beispiele von Order-Positionen | Die gekaufte Konfiguration bleibt nachvollziehbar. |
| Summen und Anpassungen | Steuer-, Versand-, Rabatt-, Gebühren-, Gutschrift-, Erstattungs- und manuelle Positionen identifizieren | Inventar der Summenbestandteile | Wesentliche Anpassungen haben eine bekannte Quellbedeutung. |
| Externe Referenzen | ERP-, Buchhaltungs-, CRM-, Fulfillment- oder Marketplace-Identifier erfassen | Integrationsrelevante Orders | Nachgelagerte Lookup-Anforderungen sind dokumentiert. |
Bearbeiten Sie historische Orders nicht nur, um sie zu vereinheitlichen. Dokumentieren Sie Auffälligkeiten separat, wenn sie zur Erklärung der ursprünglichen Transaktion beitragen.
Inhalte, Integrationen, Automatisierung und benutzerdefinierte Daten inventarisieren
Bereiten Sie Inhalte und Abhängigkeiten als getrennte Inventare vor. Die Inhaltsdokumentation sollte Seiten, Blog- oder Lerninhalte, Formulare, Bilder, Downloads, Metadaten, Canonical-Anforderungen, interne Links und Weiterleitungen umfassen. Die Dokumentation von Abhängigkeiten sollte ERP, Buchhaltung, CRM, Steuern, Versand, Bestand, Auftragsabwicklung, Marketplaces, Analytics, E-Mail und Product-Information-Systeme einschließen.
Erfassen Sie für jede Integration oder automatisierte Verarbeitung den Systemverantwortlichen, die Richtung des Datenflusses, Zeitplan oder Trigger, verwendete Identifier, gelesene oder geschriebene Felder und das erwartete Verhalten während des Migrationszeitraums. Benutzerdefinierte Felder und Skripte sollten nach ihrem Geschäftszweck klassifiziert werden, statt sie ohne Interpretation zu sammeln.
| Abhängigkeit | Verantwortlich | Nachweis | Bereit, wenn |
|---|---|---|---|
| ERP oder Buchhaltung | Finanz- oder Systemverantwortlicher | Identifier für Artikel, Customers, Orders, Rechnungen und Steuern | Erforderliche Lookup-Schlüssel sind bekannt. |
| Bestand oder Auftragsabwicklung | Operations-Verantwortlicher | Lagercodes, Lieferanten-IDs, Bestandsautorität, Versandreferenzen | Zuständigkeit für Bestand und Auftragsabwicklung ist eindeutig. |
| CRM oder Sales-Prozess | Sales-Systemverantwortlicher | Firmen-, Kontakt-, Account-Manager- und Vertragsfelder | Account-Beziehungen sind dokumentiert. |
| Marketing und Analytics | Marketing-Verantwortlicher | Segmente, Kampagnenrouten, Tracking-Referenzen, Consent-Felder | Für Marketingdaten besteht eine eindeutige Einschlussentscheidung. |
| Benutzerdefinierte Quelllogik | Entwickler oder Agentur | Skripte, benutzerdefinierte Felder, verborgene Tabellen, geplante Jobs, manuelle Abläufe | Nicht standardmäßige Funktionsweisen haben einen benannten Verantwortlichen und eine festgelegte Behandlung. |
Exporte, Medien, Backups und Änderungskontrolle vorbereiten
Erstellen Sie ein datiertes Nachweisarchiv statt einer losen Dateisammlung. Speichern Sie Product-, Customer-, Order-, Category-, Inhalts-, Preis-, Custom-Field- und Integrationsexporte gemeinsam mit Mediendateien, Screenshots, Exportkriterien und erläuternden Notizen. Bewahren Sie Originaldateien unverändert auf und führen Sie Bereinigungen oder Analysen nur in Arbeitskopien durch.
| Nachweispaket | Erforderliche Inhalte | Bereit, wenn |
|---|---|---|
| Datenexporte | Quelldateien, Exportkriterien, Store-Filter, Datum, Feldzuordnung, Prüfsumme | Dateien sind vollständig und eindeutig zuordenbar. |
| Medienarchiv | Product-, Category-, Inhalts-, Dokument- und Download-Dateien | Originaldateien können den Quelldatensätzen zugeordnet werden. |
| Konfigurationsnachweise | Screenshots oder Berichte zu Store, aktivem Katalog, Customer Type, Preisen, Status und Steuern | Regeln, die in normalen Exporten nicht enthalten sind, sind dokumentiert. |
| Backup- und Recovery-Hinweis | Verfügbare Plattform-Backups, heruntergeladene Exporte, Medienarchiv, Account-Ansprechpartner | Quelldokumentation kann bei Rückfragen wiederhergestellt werden. |
| Änderungsprotokoll | Neue oder geänderte Products, Customers, Orders, URLs, Regeln und Integrationen nach der Erfassung | Spätere Änderungen an der Quelle können abgeglichen werden. |
Repräsentative Datensätze für den Migrationstest auswählen
Wählen Sie repräsentative Migrationsdatensätze bewusst aus. Die Stichprobe sollte sowohl gewöhnliche Datensätze als auch jene Strukturen enthalten, die am ehesten einen Umfangs- oder Mappingfehler sichtbar machen. Bei AmeriCommerce sind das normalerweise Datensätze aus unterschiedlichen Stores, aktiven Katalogen, Customer Types, Product-Mustern und Integrationskontexten.
| Stichprobengruppe | Einbeziehen | Zweck der Vorbereitung |
|---|---|---|
| Products | Einfaches Product, Varianten-Product, Product mit Variantenbestand, Product Group, Kit, eingeschränktes Product, Product mit erweiterten Preisen | Unterschiedliche Katalog- und Preisbeziehungen sichtbar machen. |
| Customers | Standardkäufer, besonderer Customer Type, steuerbefreites Konto, Firmen- oder Managed-Account, Ausnahme mit doppelter E-Mail | Unterschiede bei Identität und Käuferregeln abbilden. |
| Orders | Unterschiedliche Stores, Status, Rabatte, Steuerfälle, Erstattungen, gruppierte oder Kit-Positionen, externe Referenzen | Historischen Betriebskontext bewahren. |
| Inhalte und URLs | Priorisierte Product-, Category-, Seiten-, Kampagnen- und Redirect-Routen | Entscheidungen zu Routen und Inhalten vorbereiten. |
| Integrationen | Product-, Customer- und Order-Datensätze mit externen IDs | Bestätigen, dass erforderliche Quelldokumentation enthalten ist. |
Formulieren Sie für jede Stichprobe kurz, welche Beziehungen, Felder, verknüpften Dateien und Identifier sie repräsentativ machen.
AmeriCommerce-Bereitschaft abschließend prüfen
Die Vorbereitung ist abgeschlossen, wenn die Quelldokumentation die Fragen beantworten kann, die den Migrationsumfang steuern. Das Team sollte jeden Store identifizieren, Active-Catalog- und Customer-Type-Regeln erklären, Product-Strukturen unterscheiden, historische Orders interpretieren, Medien und Inhalte auffinden und für jede wesentliche Integration einen Verantwortlichen benennen können.
| Abschlussprüfung | Bereit, wenn |
|---|---|
| Store-Umfang | Jeder einbezogene Store und die Grenze gemeinsam genutzter Daten sind dokumentiert. |
| Katalog | Product-Strukturen, Preisregeln, Sichtbarkeit und Categories sind durch Nachweise abgebildet. |
| Customers | Customer Types, Identitätsausnahmen, Adressen, Steuerkontext und externe IDs sind verstanden. |
| Orders | Store-Zuordnung, Status, Positionen, Summen und externe Referenzen sind interpretierbar. |
| Inhalte und URLs | Priorisierte Seiten, Medien, Metadaten und Routenentscheidungen sind dokumentiert. |
| Abhängigkeiten | Integrationen, Automatisierung und benutzerdefinierte Daten haben Verantwortliche und festgelegte Behandlungen. |
| Eingaben | Exporte, Medien, Kriterien, Prüfsummen, Backups und Änderungsprotokoll sind verfügbar. |
| Stichproben | Repräsentative Migrationsdatensätze decken gewöhnliche und komplexe Quellmuster ab. |
Fazit
Eine gute AmeriCommerce-Vorbereitung macht sichtbar, wie Stores, aktive Kataloge, Customer Types, Product-Strukturen, Preise, Orders, Inhalte und externe Systeme zusammenwirken. Das stärkste Vorbereitungspaket ist nicht der umfangreichste Export. Entscheidend ist die Nachweissammlung, die Zuständigkeit und Bedeutung über diese Beziehungen hinweg bewahrt.
Wenn Zugriff, Exporte, Geschäftsregeln, repräsentative Stichproben und Änderungskontrolle vollständig sind, kann die Migrationskonfiguration auf dokumentierter Quellwahrheit statt auf Annahmen aufbauen.
Häufige Fragen
Sollten AmeriCommerce-Exporte aus allen Stores zusammengeführt werden?
Nur, wenn die Store-Zuordnung eindeutig bleibt. Bewahren Sie Store-Filter, Exportkriterien und Store-Identifier gemeinsam mit jeder Datei auf, damit gemeinsame und Store-spezifische Datensätze weiterhin unterscheidbar sind.
Warum müssen Customer Types getrennt von Customers dokumentiert werden?
Customer Types können Preise, Rabatte, Inhalte, Weiterleitungen, Versand und Product-Sichtbarkeit beeinflussen. Die Mitgliedschaft allein erklärt nicht die Regel, die durch den Typ gesteuert wird.
Welche Products sollten bei der Vorbereitung priorisiert werden?
Nehmen Sie einfache Products, Varianten, Products mit Variantenbestand, Product Groups, Kits, eingeschränkte Products, Fälle mit erweiterten Preisen und Datensätze mit externen Identifiern auf.
Sollten alte oder inaktive Products vor der Migration gelöscht werden?
Nicht automatisch. Klassifizieren Sie sie als einbeziehen, ausschließen, archivieren oder geschäftlich prüfen. Eine vorherige Löschung kann Nachweise entfernen, die zum Verständnis historischer Orders oder Integrationen benötigt werden.
Was sollte bei historischen Orders erhalten bleiben?
Bewahren Sie Store-Zuordnung, Positionskonfiguration, Status, Adressen, Summen, Rabatte, Steuern, Zahlungs- und Versandbezeichnungen, Notizen sowie externe Referenzen auf, die von operativen Teams benötigt werden.
Wie sollten Änderungen an der Quelle behandelt werden, nachdem Exporte erstellt wurden?
Führen Sie ein datiertes Änderungsprotokoll und benennen Sie für jeden geänderten Bereich einen Verantwortlichen. Das Protokoll sollte Katalog-, Customer-, Order-, URL-, Preis- und Integrationsänderungen abdecken, die den vorbereiteten Nachweisbestand verändern können.