Bei einer AmeriCommerce-Migration hängt viel davon ab, wie viel geschäftliche Bedeutung hinter jedem sichtbaren Datensatz steckt. Product-, Customer-, Order- und Content-Daten können in einem Export vertraut aussehen. Ob der migrierte Shop jedoch weiterhin nutzbar ist, entscheidet häufig erst das Zusammenspiel zwischen Käufern, Storefronts, Katalogen, Preisregeln und operativen Systemen.
Die zentrale Prüfung lautet daher nicht, ob Datensätze nach AmeriCommerce übertragen werden können. Entscheidend ist, ob jeder Datensatz nach der Migration die richtige kommerzielle Rolle behält: wer kaufen darf, was sichtbar ist, welcher Preis gilt, welche Storefront das Erlebnis verantwortet und welcher externe Prozess weiterhin von dem Datensatz abhängt.
Warum die Datenbedeutung in AmeriCommerce gesondert geprüft werden muss
AmeriCommerce sollte als Commerce-Ziel mit vielen Beziehungsstrukturen betrachtet werden. Eine reine Bestandsaufnahme der Datensätze kann den tatsächlichen Übertragungsaufwand unterschätzen, weil dieselbe Datenkategorie je nach Storefront, Käufertyp, Katalogstruktur und Integrationshistorie unterschiedliche Aufgaben erfüllt.
Ein Product kann mehr als eine SKU sein. Es kann bestimmten Storefronts zugeordnet sein, an kundenspezifischer Preisbildung teilnehmen, Optionen oder Kits verwenden, SEO-Wert besitzen und mit externen Inventar- oder Auftragsabwicklungsregeln verbunden sein. Ein Customer kann mehr als ein Login sein. Der Datensatz kann eine Käuferbeziehung, eine Einkaufsregel, eine Steuer- oder Zahlungsbedingung oder einen Ablauf zur Betreuung eines Geschäftskontos repräsentieren.
| Datenbereich | Zu prüfende Bedeutung bei der Migration | Warum dies für die AmeriCommerce-Planung wichtig ist |
|---|---|---|
| Products und SKUs | Kommerzielle Verfügbarkeit, Optionsverhalten, Bundle- oder Kit-Bedeutung, Sichtbarkeitsregeln | Products verbinden häufig Katalogstruktur, Preise und Storefront-Zugriff. |
| Customers und Konten | Käuferidentität, Customer Type, Unternehmensbeziehung, steuerliche oder zahlungsbezogene Erwartungen | Customer-Datensätze können Zugriff, Preise und Order-Verhalten beeinflussen. |
| Orders | Transaktionshistorie, Käuferkontext, Status der Auftragsabwicklung, Nutzen für den Service | Importierte Bestellhistorie muss für Service, Reporting und Kontoprüfung brauchbar bleiben. |
| Storefronts und Microstores | Store-Zuständigkeit, Zielgruppensegmentierung, URL-Struktur, Kataloggrenzen | Multi-Store-Annahmen können bestimmen, wie Datensätze gruppiert oder getrennt werden müssen. |
| Regeln und Integrationen | Preise, Rabatte, Versand, Steuern, ERP-, CRM- und Auftragsabwicklungsabhängigkeiten | Regeln können Konfiguration, Zuordnung, Ausschluss oder eine gesonderte Zielprüfung erfordern. |
Das Zielmodell sollte deshalb anhand von Datensatzverantwortung und Beziehungen definiert werden, nicht nur anhand der Datenmenge.
Unterschiede bei Product-, Katalog- und SKU-Strukturen
AmeriCommerce trennt das sichtbare Product von mehreren Beziehungen, die den Artikel tatsächlich verkaufbar machen können. Der Katalog kann Product-Varianten, Product Groups, Kits, verknüpfte Products, Attribute, Preismatrizen, Bilder, Inventareinstellungen und Storefront-Zuordnungen verwenden. Eine Quellplattform kann denselben kommerziellen Artikel als Parent mit Varianten, mehrere unabhängige SKUs, Bundle, konfigurierbares Product oder individuelle Product-Struktur darstellen. Diese Formen sollten nicht auf eine einzige undifferenzierte Product-Zeile reduziert werden.
Die erste Zuständigkeitsentscheidung betrifft die verkaufbare Ebene. Erzeugt Größe oder Farbe eine eigene SKU mit eigenem Preis, Bestand, Bild, Gewicht oder externer Kennung, gehört der Wert zur Variantenbeziehung. Beschreibt ein Wert dagegen nur Material, Kompatibilität oder technische Spezifikation, gehört er zu Informationsattributen oder Content. Product Groups und Kits benötigen eine eigene Entscheidung, weil sie ein sichtbares Angebot mit Komponenten-Products oder inventarführenden Datensätzen verbinden können.
| Quellmuster im Katalog | Beziehungsfrage in AmeriCommerce | Bedeutung, die erhalten bleiben muss |
|---|---|---|
| Parent Product mit untergeordneten SKUs | Welcher Quelldatensatz wird sichtbares Product und welche Datensätze werden Varianten? | SKU, Inventar, Preis, Bild, Gewicht und Identität im externen System auf der verkaufbaren Ebene |
| Getrennte Products, die als eine Familie genutzt werden | Sollen sie unabhängig bleiben oder zu einer Product Group bzw. Variantenfamilie werden? | URLs, Reviews, Bestand, Reporting-Historie und Merchandising-Identität |
| Kit oder Bundle | Ist der Quelldatensatz ein kommerzielles Paket, eine Inventarbaugruppe oder nur eine visuelle Gruppierung? | Komponentenbeziehungen, Identität in der Auftragsabwicklung, Preisbehandlung und historische Order Lines |
| Gemeinsam verwendetes Optionsset | Ist die Option wiederverwendbare Konfiguration oder Product-spezifische Käuferangabe? | Bezeichnungen, zulässige Werte sowie Auswirkungen auf Preis und Inventar |
| Product-Spezifikation | Ist der Wert auswählbar oder rein informativ? | Suche, Filterung, Vergleich und Storefront-Beschreibung ohne künstliche Varianten |
AmeriCommerce unterstützt außerdem Inventar auf Variantenebene und Product-Preisstrukturen. Deshalb reichen Summen auf Parent-Ebene nicht aus, wenn der Quellbetrieb einzelne Kombinationen getrennt verwaltet. Das Ziel sollte Kennungen auf derselben Ebene erhalten, die Lager, ERP, Marketplace und historische Orders verwenden. Werden diese Beziehungen abgeflacht, können sichtbare Product-Namen erhalten bleiben, während Bestandsverantwortung, Nachverfolgbarkeit in der Auftragsabwicklung oder Käuferauswahl beschädigt werden.
Beziehungen zwischen Categories, Storefronts und Microstores
AmeriCommerce kann Commerce über Categories, mehrere Storefronts und Microstores organisieren. Diese Konzepte hängen zusammen, sind aber nicht austauschbar. Categories ordnen Products und können Navigation sowie Merchandising unterstützen. Eine Storefront kann eine eigene Domain, Darstellung, Preisumgebung und Katalogzuordnung haben. Ein Microstore kann innerhalb eines größeren Commerce-Betriebs den Katalog oder die Zielgruppe einschränken.
Dasselbe Product kann daher mehrere Platzierungsebenen besitzen: seine kommerzielle Identität, Category-Mitgliedschaften, die Storefronts, in denen es verfügbar ist, und eine Microstore- oder eingeschränkte Katalogbeziehung für eine bestimmte Käufergruppe. Eine Quellplattform, die diese Bedeutungen über Websites, Channels, Kataloge, Collections, Customer Groups oder Berechtigungen abbildet, benötigt eine ausdrückliche Zuordnung der Zuständigkeiten.
| Quellstruktur | Zielbedeutung in AmeriCommerce | Konsequenz für die Übertragung |
|---|---|---|
| Zentrale Kataloghierarchie | Parent-Child-Beziehungen zwischen Categories | Dauerhafte Such- und Merchandising-Struktur erhalten, ohne veraltete interne Ordner zu importieren. |
| Marken-, Regions- oder Zielgruppen-Storefront | Storefront-Zuständigkeit und Product-Verfügbarkeit | Domain-, Zielgruppen-, Preis- und Reporting-Grenzen getrennt halten, sofern sie weiterhin kommerziell relevant sind. |
| Eingeschränktes B2B-Sortiment | Microstore, Katalogbeschränkung, Customer Type oder andere Zugriffsbeziehung | Product-Verfügbarkeit von gewöhnlicher Category-Platzierung trennen. |
| Dynamische Kampagnen-Collection | Regelbasiertes Merchandising oder kuratierte Category-Beziehung | Eine temporäre Kampagnengruppe nicht ohne geschäftlichen Grund in eine permanente Kataloghierarchie umwandeln. |
| Gemeinsam genutztes Product über mehrere Stores | Eine Product-Identität mit Storefront-spezifischen Beziehungen oder getrennte Datensätze, wenn der Betrieb Trennung verlangt | Externe IDs und das Zuständigkeitsmodell erhalten, das verbundene Systeme verwenden. |
Eine Multi-Store-Quelle sollte nicht allein deshalb konsolidiert werden, weil Product-Datensätze ähnlich aussehen. Wenn Storefronts unterschiedliche Domains, Preise, Zielgruppen, Inhalte, Regeln zur Auftragsabwicklung oder Reporting-Bedeutung besitzen, gehören diese Grenzen zum Datenmodell. Umgekehrt sollten doppelte Storefront-Daten ohne eigenen Geschäftszweck nicht als künstliche Trennung konserviert werden.
Unterschiede bei Customers, Konten und Käuferbeziehungen
Customer-Daten in AmeriCommerce können mehr als einen einzelnen Käufer repräsentieren. Zu den Plattformstrukturen gehören Customer Types, Unternehmenszuordnungen, Beziehungsbäume, gemeinsam genutzte Kreditlimits auf Unternehmensebene sowie Mitarbeiter-Users und User Groups. Diese Datensätze erfüllen unterschiedliche Zwecke und sollten nicht in einem generischen Kontokonzept zusammengeführt werden.
Ein Customer-Datensatz besitzt Käuferidentität, Kontaktdaten, Adressen und Transaktionsbeziehungen. Ein Customer Type kann Preisbildung oder Zugriff beeinflussen. Eine Unternehmensbeziehung kann mehrere Kontakte mit einer kommerziellen Organisation verbinden. Gemeinsamer Kredit kann auf Unternehmensebene liegen und nicht bei einer einzelnen Person. Administrative Users und User Groups steuern Backoffice-Zugriff und müssen getrennt von Käuferdatensätzen bleiben.
| Quellbeziehung | Zuständigkeit in AmeriCommerce | Zu erhaltende Bedeutung |
|---|---|---|
| Individuelles Retail-Konto | Customer | Login- und Kontaktidentität, Adressen, Order-Historie und Kommunikationskontext |
| Großhandels- oder Wiederverkäuferklasse | Customer Type oder entsprechende Käuferklassifikation | Preis-, Zugriffs-, Steuer- oder Einkaufsbehandlung, die an die Klasse gebunden ist |
| Organisation mit mehreren Kontakten | Unternehmenszuordnung und Customer-Beziehungsbaum | Unternehmensidentität, Kontaktrollen, gemeinsamer kommerzieller Kontext und historische Nachverfolgbarkeit |
| Gemeinsamer Kredit oder Kontosaldo | Unternehmens- oder Finanzbeziehung | Organisation, die die Verbindlichkeit trägt, und Customers, die sie nutzen dürfen |
| Zuweisung eines Vertriebsmitarbeiters | Customer-, Order-, CRM- oder Reporting-Beziehung | Kontozuständigkeit und Reporting-Kontext, ohne die Mitarbeiterbeziehung in ein Käuferfeld umzuwandeln |
| Administrator- oder Integrationskonto | User und User Group | Backoffice-Berechtigung oder API-Zugriff, nicht Customer-Identität |
E-Mail, Name, Telefon und Adresse bilden nur die Oberfläche. Das Ziel muss außerdem die Ebene erhalten, auf der Preis, Kredit, steuerliche Behandlung, Zugriff und externe Kennungen verwaltet werden. Werden mehrere Unternehmenskontakte zu einem Customer zusammengeführt, kann die Zuordnung von Orders verloren gehen. Wird jeder Kontakt als eigenständige Organisation behandelt, können Unternehmensregeln und finanzieller Kontext dupliziert werden.
Preise, Rabatte, Rewards und regelbasierte Daten
AmeriCommerce kann Basispreise von Products mit erweiterten Preismatrizen, nach Customer Type gestaffelten Preisen, Mengenstaffeln, Rabatten, Coupons, Geschenkgutscheinen, Rewards und Storefront-spezifischer Behandlung kombinieren. Diese Werte stehen in Beziehung zu Products und Customers, sind aber nicht sämtlich Product-Felder.
Das Zielmodell sollte dauerhafte Preiswerte von bedingten Regeln unterscheiden. Ein Basispreis gehört zum Product oder zur Variante. Eine Preisstufe kann von Menge und Customer Type abhängen. Ein Coupon besitzt Berechtigungs- und Nutzungsbeziehungen. Reward Points gehören zu einem Customer oder einem Programmkonto. Geschenkgutscheine und Store Credit tragen Saldo- oder Einlösungsbedeutung, die nicht aus einem Promotion-Label allein rekonstruiert werden kann.
| Preiselement | Zuständige Beziehung | Entscheidung für die Übertragung |
|---|---|---|
| Basis- und Sale-Preis | Product oder Variante | Preis auf der Ebene erhalten, auf der die verkaufbare SKU verwaltet wird. |
| Preismatrix oder Mengenstufe | Product/Variante plus Mengen- und Käuferbedingung | Bedingung zusammen mit dem Wert erhalten; ein Preis ohne Regel hat eine andere Bedeutung. |
| Customer-Type-Preis | Customer-Klassifikation plus Product-Preis | Käuferklassenbeziehung erhalten, statt Preise in unverbundene Customer-Felder zu kopieren. |
| Coupon oder Rabatt | Promotion-Datensatz mit Product-, Category-, Customer-, Datums- oder Nutzungsbedingungen | Aktive kommerzielle Regeln von abgelaufenen historischen Kampagnen trennen. |
| Geschenkgutschein oder Guthaben | Finanz- oder Einlösungsdatensatz | Code, Saldo, Zuständigkeit und historische Verwendung nur erhalten, wenn die Zielbeziehung definiert ist. |
| Reward Points | Customer-bezogenes Loyalty-Konto | Verdiente oder verfügbare Werte von der Regel trennen, die zukünftige Punkte vergibt. |
Historische Orders können den Preis-, Rabatt-, Steuer- und Guthabeneffekt bewahren, der zum Kaufzeitpunkt galt. Preisregeln für künftige Transaktionen bestimmen dagegen das spätere Verhalten. Diese Ebenen sollten getrennt bleiben. Werden alte Orders mit einer neuen Preismatrix neu berechnet, geht historische Genauigkeit verloren. Werden alte Kampagnen als aktive Regeln kopiert, können unbeabsichtigte Rabatte entstehen.
Orders, Zahlungen, Auftragsabwicklung und operative Historie
Die Bestellhistorie sollte nach der Migration weiterhin nutzbar sein. Bei der AmeriCommerce-Planung ist zu bestimmen, welche Order-Felder Kundenservice, Kontobetreuung, Reporting, Rückerstattungen, Prüfung der Auftragsabwicklung und Wiederholungsbestellungen unterstützen.
Ein Order-Datensatz kann sichtbare Positionen und zugleich verborgenen Betriebskontext enthalten. Details des Payment Gateways, Sendungsverfolgung, Steuerberechnung, angewandte Rabatte, Vertriebszuständigkeit, interne Notizen, Purchase-Order-Referenzen und Kennungen des Fulfillment-Systems können entscheiden, ob die Historie praktisch brauchbar bleibt.
| Order-Bestandteil | Warum er wichtig ist | Übliche Behandlung bei der Migration |
|---|---|---|
| Positionen und Summen | Unterstützt Kundenservice und Kaufhistorie | Wird üblicherweise migriert, wenn Quelldaten konsistent sind. |
| Verweise auf Zahlungsmethoden | Hilft bei der Interpretation eines Orders, stellt Transaktionen aber möglicherweise nicht wieder her | Beschreibende Historie erhalten, sofern sinnvoll. |
| Versand- und Auftragsabwicklungsdaten | Unterstützt Serviceprüfung und operative Nachverfolgbarkeit | Tracking- und Abwicklungsstatus zuordnen, sofern verfügbar. |
| Rabatt- und Steuerzeilen | Erklärt, wie Order-Summen entstanden sind | Werte erhalten, auch wenn die Regeln separat neu aufgebaut werden. |
| Interne Notizen oder benutzerdefinierte Felder | Können Vertrieb, Support oder ERP-Abgleich unterstützen | Nur aufnehmen, wenn der Geschäftszweck bestätigt ist. |
Historische Orders sind Transaktions-Snapshots und keine aktuellen Checkout-Objekte. Ihre Daten sollten mit dem richtigen Customer, Product oder der richtigen Variante, den korrekten Summen, Referenzen zur Auftragsabwicklung und externen Kennungen verbunden bleiben, ohne unter aktuellen Regeln neu berechnet zu werden.
Content-, URL-, SEO- und Storefront-Daten
Die Content-Migration zu AmeriCommerce kann CMS Pages, Landingpages, Blog-Inhalte, Navigationsbezeichnungen, Metadaten, Redirects und Storefront-spezifisches Routing umfassen. Händler sollten Content nicht von der Datenmigration trennen, wenn Inhalte Suchsichtbarkeit oder Käuferinformation unterstützen.
Die wichtigste Frage lautet, welche URLs und Content-Elemente weiterhin geschäftlichen Wert besitzen. Manche Seiten sollten migriert werden, weil sie ranken, Kaufentscheidungen unterstützen oder Kontoworkflows ermöglichen. Andere sollten umgeleitet, konsolidiert oder eingestellt werden.
| Content- oder Routentyp | Migrationsrisiko | Prüfschritt |
|---|---|---|
| Product-URLs | Suchrankings und Lesezeichen von Customers können von der Routenkontinuität abhängen. | Redirect-Regeln für geänderte Pfade erstellen. |
| Category-URLs | Navigation und SEO können an der Category-Struktur hängen. | Category-Hierarchie prüfen, bevor endgültige URLs akzeptiert werden. |
| CMS Pages | Richtlinien-, Support-, B2B-, Marken- oder Landing-Content kann Kaufentscheidungen unterstützen. | Entscheiden: migrieren, neu schreiben, umleiten oder einstellen. |
| Blog- oder Ressourcen-Content | Organischer Traffic kann von Artikel-URLs und Metadaten abhängen. | Wertvollen Content erhalten und geänderte Routen umleiten. |
| Multi-Store-Routen | Ähnliche Seiten können in verschiedenen Storefront-Kontexten existieren. | Bestätigen, welchem Store jede Route zugeordnet ist. |
Content- und URL-Datensätze sollten ihren dauerhaften Verantwortungsobjekten zugeordnet werden: Product, Category, Storefront, Microstore, CMS Page, Blog Post oder Redirect-Beziehung. Theme-Layout und aktuelle Navigation sind separate Darstellungsfragen.
Integrationen, benutzerdefinierte Felder und Daten externer Systeme
AmeriCommerce bietet REST API-, Webhook- und JavaScript-API-Funktionen. Diese Integrationsmöglichkeiten machen jedoch nicht jeden Datensatz einer Quell-Extension zu einem nativen AmeriCommerce-Datensatz. ERP-, CRM-, Fulfillment-, Buchhaltungs-, Marketplace-, Marketing-, Subscription- und Steuersysteme können Kennungen oder Beziehungen verwalten, die lediglich in Commerce-Feldern erscheinen.
Jeder benutzerdefinierte Wert sollte nach Zuständigkeit und Zweck klassifiziert werden. Eine sichtbare Spezifikation kann zum Product gehören. Ein Lagercode kann zu einer Variante oder einem Fulfillment-System gehören. Eine CRM-Unternehmens-ID kann zur Unternehmensbeziehung gehören. Eine Order-Referenz kann für den Finanzabgleich nötig sein. Webhook-Subscriptions und API-Zugangsdaten sind Konfiguration, während die über eine Integration ausgetauschten Kennungen Daten sind.
| Benutzerdefinierter oder externer Wert | Wahrscheinliche Zuständigkeit | Zielbeziehung |
|---|---|---|
| ERP-Product- oder Varianten-ID | ERP plus verkaufbarer Katalogdatensatz | An genau das Product oder die Variante binden, die das ERP erkennt. |
| CRM-Unternehmens-/Konto-ID | CRM plus Unternehmens- oder Customer-Beziehung | Organisations- oder Kontaktebene erhalten, die im Vertriebsprozess verwendet wird. |
| Fulfillment- oder Lagercode | Fulfillment-System plus Product, Variante, Sendung oder Order | Code bei dem Datensatz halten, den das Lager tatsächlich verarbeitet. |
| Marketplace-Listing-ID | Marketplace-Connector plus Product/Variante/Channel | Eine Channel-Listing-Kennung nicht als generisches Product-Attribut behandeln. |
| Von einer App erzeugtes Feld | Quell-Extension oder benutzerdefinierter Prozess | Parent-Datensatz, Geschäftszweck und Zielzuständigkeit vor der Übertragung definieren. |
| API-User, Webhook oder Zugangsdaten | Integrationskonfiguration | Sicher neu erstellen; nicht als gewöhnliche Customer-Daten veröffentlichen oder migrieren. |
Dieser Zuständigkeitsansatz trennt beschreibende Commerce-Daten von Steuerungsdaten. Beschreibende Werte können häufig bei Products, Customers oder Orders liegen. Steuerungsbeziehungen können in einem externen System verbleiben oder ein eigenes Zielfeld benötigen. Veraltete Integrationsreste sollten ausgeschlossen werden, statt sie als unerklärte Metadaten zu übernehmen.
Entscheidungen zur Übertragung von Beziehungen
Die Übertragung des AmeriCommerce-Datenmodells sollte mit einer Zuständigkeitskarte enden und nicht nur mit einer Liste von Datensätzen, die als „migriert“ markiert wurden. Die Karte benennt Zielobjekt, Parent-Child-Beziehung, Storefront- oder Käuferkontext und externe Kennung, die jedem Wert seine Bedeutung geben.
| Beziehungssignal | Erforderliche Zuständigkeitsentscheidung |
|---|---|
| Ein Product hat Varianten, Kits oder verknüpfte Komponenten | Sichtbaren Parent, verkaufbare SKU-Ebene, Komponentenbeziehung und Inventarzuständigkeit definieren. |
| Customer Types verändern Preis oder Zugriff | Customer-Klassifikation mit der Preis- oder Sichtbarkeitsbeziehung verbunden halten, die sie steuert. |
| Mehrere Storefronts oder Microstores teilen Products | Festlegen, welche Attribute global sind und welche zu Storefront, Domain, Zielgruppe oder eingeschränktem Katalog gehören. |
| Orders enthalten historische Statuswerte oder IDs externer Systeme | Historischen Snapshot und Abgleichschlüssel erhalten, ohne den alten Workflow als aktuelle Konfiguration zu behandeln. |
| Benutzerdefinierte Felder steuern ERP-, CRM- oder Fulfillment-Verhalten | Kennungen an genau den Datensatz binden, den das verbundene System erkennt. |
| Content und Routen unterscheiden sich nach Storefront | Zuständigkeit für Seite, URL, Menü und Storefront von der Product-Identität trennen. |
Dieses Modell macht Komplexität sichtbar, indem dauerhafte Datenbeziehungen von späteren operativen Arbeiten getrennt werden. Selbst ein kleiner Katalog kann ein dichtes Beziehungsnetz besitzen, wenn Käufertypen, Preismatrizen, Microstores, Unternehmenszuordnungen und Integrationen zusammenwirken. Umgekehrt kann ein großer Katalog mit konsistenter Product- und Customer-Zuständigkeit direkter übertragen werden. Die fertige Karte sollte außerdem dokumentieren, welche Kennungen über Storefronts und externe Systeme hinweg stabil bleiben müssen. Dadurch erhält ein gemeinsam genutztes Product, ein Customer oder ein Order nicht allein deshalb unterschiedliche Identitäten, weil derselbe Datensatz in mehreren kommerziellen Kontexten erscheint.
Fazit
Unterschiede im AmeriCommerce-Datenmodell sind relevant, weil viele Datensätze Beziehungsbedeutung tragen. Products stehen mit Storefronts, Käufern, Preisen, Content und operativen Abläufen in Verbindung. Customers können Zugriff, Rabatte, steuerliche Behandlung und Kontoabläufe steuern. Orders können weit mehr als reine Kaufhistorie unterstützen.
Eine kontrollierte Migration sollte diese Bedeutung klären, bevor Datensätze in großem Umfang übertragen werden. Werden Product-, Käufer-, Storefront-, Regel-, Content- und Integrationsbeziehungen gemeinsam betrachtet, ist es deutlich wahrscheinlicher, dass der migrierte Shop realen Geschäftsbetrieb unterstützt, statt nur exportierte Daten zu bewahren.
Häufige Fragen
Warum sind Unterschiede im AmeriCommerce-Datenmodell bei einer Migration wichtig?
Weil AmeriCommerce-Planung häufig von Beziehungen zwischen Products, Käufern, Storefronts, Preisen, Content und externen Systemen abhängt. Derselbe Datensatz kann je nach Customer Type, Store-Kontext oder Regelzuständigkeit unterschiedlich wirken.
Sollte jedes benutzerdefinierte Feld nach AmeriCommerce migriert werden?
Nein. Benutzerdefinierte Felder sollten nach ihrem Geschäftszweck klassifiziert werden. Felder für Reporting, Kundenservice, ERP-Synchronisierung, Preisbildung oder Auftragsabwicklung können wichtig sein. Veraltete, doppelte oder reine Darstellungsfelder rechtfertigen möglicherweise keine Migration.
Warum sollten Preisregeln getrennt von Product-Daten geprüft werden?
Preisregeln können von Customer Groups, Mengen, Product Groups, Zeiträumen, Coupons oder externen Systemen abhängen. Basispreise eines Products enthalten nicht die Customer-Type-, Mengen-, Product-Group-, Datums-, Coupon- oder Systembeziehungen, die bedingter Preisbildung ihre Bedeutung geben.
Wie sollten Multi-Store- oder Microstore-Daten behandelt werden?
Storefront-Grenzen verändern die Bedeutung von Products, Categories, Customers, CMS Pages und URLs, wenn der Quellshop Zielgruppen, Marken, Regionen oder Käufergruppen über getrennte Storefronts organisiert.
Was macht die Bestellhistorie nach der Migration nutzbar?
Sie bleibt nutzbar, wenn Customers, Positionen, Summen, Rabatte, Steuerwerte, Zahlungsreferenzen, Details zur Auftragsabwicklung und interner Kontext so erhalten bleiben, dass Support, Reporting und Kontoprüfung damit arbeiten können.
Kann die Zuständigkeit mehrerer Quell-Storefronts in einem einzigen AmeriCommerce-Katalog zusammengeführt werden?
Nur wenn die Quell-Storefronts keine unterschiedlichen Zielgruppen, Preise, Domains, Berechtigungen, Regeln zur Auftragsabwicklung oder Reporting-Bedeutung tragen. Sind solche Unterschiede relevant, sollten Storefront- und Microstore-Beziehungen als Zuständigkeitsgrenzen abgebildet und nicht in einem undifferenzierten Katalog zusammengeführt werden.