Wenn VTEX 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 VTEX als Zielplattform ausgewählt wird, sollte die Vorbereitung das Enterprise-Commerce-Modell bereits vor dem ersten Migrationslauf in ein nach Domänen verantwortetes Nachweispaket übersetzen. Catalog, Pricing, Promotions, Trade Policies, Inventory, Logistics, Checkout, Payments, OMS, Master Data, Sellers, Marketplace-Beziehungen und Storefront Content sind miteinander verbunden, werden aber getrennt gesteuert.
Für jeden wichtigen Datenbereich sollten Aktion, Owner, Nachweis und Freigabebedingung dokumentiert werden. So wird verhindert, dass ein Product-Export mit einem vollständigen VTEX Catalog oder historische Orders mit aktueller Logistics- und Checkout-Konfiguration verwechselt werden.
VTEX-Betriebsmodell und Domänenverantwortung definieren
Erstellen Sie eine kompakte Übersicht darüber, welche VTEX-Domänen und externen Systeme die jeweiligen kommerziellen Beziehungen verantworten.
| Vorbereitungsbereich | Zu dokumentierende Entscheidung | Owner | Ready-Nachweis |
|---|---|---|---|
| Catalog | Categories, Brands, Products, SKUs, Specifications, Attachments, Kits und Assembly Options | Catalog Owner | Übersicht der Catalog-Beziehungen |
| Kommerzieller Kontext | Preise, Promotions, Trade Policies, Sellers, Offers und Kanalsortiment | Commercial Owner | SKU-/Kanal-/Preis-Verantwortungsmatrix |
| Customer und B2B | Customer Profiles, Adressen, Organizations, Rollen, Cost Centers und Master-Data-Entitäten | Customer-/B2B-Owner | Identitäts- und Entitätsdiagramm |
| Orders und Operations | Checkout, Payments, OMS, Logistics, Inventory, Warehouses, Docks, Carrier und Sellers | Operations Owner | Order-Domain- und Logistics-Map |
| Storefront | CMS, Search, Navigation, Routes, Content und Headless-Frontend-Verantwortung | Digital Experience Owner | Storefront-Verantwortungsmatrix |
| Externe Systeme | ERP, PIM, WMS, CRM, Marketplace, Tax, Accounting und Middleware | Technical Owner | Abhängigkeits- und System-of-Record-Register |
Die Übersicht sollte angeben, wo ein Wert geführt wird und welcher Identifikator ihn mit anderen Domänen verbindet.
Zugriff, Exporte, Backups und Quellnachweise vorbereiten
Sammeln Sie:
- Administratorzugriff auf die Quelle und erforderliche administrative Zugriffe auf VTEX;
- datierte Exporte von Products, SKUs, Categories, Brands, Preisen, Promotions, Customers, Orders und Content;
- Datenbank-, Medien- oder Anwendungsarchive, soweit verfügbar;
- Specification Groups, Product Specifications, SKU Specifications und kontrollierte Werte;
- Reports zu Trade Policies, Sellers, Channels, Warehouses, Docks, Carriers und Inventory;
- Beispiele für Customer-, B2B- und Master-Data-Entitäten;
- Marketplace-Catalog- und Seller-Identifikatoren;
- Inventare für CMS, Search, Navigation, URLs, Metadaten und Redirects;
- App-, API-, Middleware-, Integrations- und externe Systeminventare;
- Screenshots oder Reports, die wichtiges Quellverhalten erklären.
| Nachweis | Warum er benötigt wird | Freigabebedingung |
|---|---|---|
| Catalog Dictionary | Erklärt Product-/SKU-/Specification-Bedeutung | Jedes priorisierte Field hat einen Owner und repräsentativen Wert. |
| Kanal- und Seller-Matrix | Schützt Trade-Policy- und Marketplace-Umfang | Jede relevante Seller- und Kanalbeziehung ist dokumentiert. |
| Master-Data-Inventar | Identifiziert Custom Entities außerhalb gewöhnlicher Customer-Datensätze | Jede wichtige Entität besitzt Schema, Schlüssel und Owner. |
| Integrationsregister | Schützt Kontinuität zu externen Systemen | Jeder dauerhafte Identifikator ist mit der richtigen VTEX- oder externen Entität verbunden. |
| Route-/Content-Inventar | Trennt Storefront-Implementierung von Catalog-Daten | Priorisierte Routes und Content haben definierte Ziel-Owner. |
Ein fehlender API-Export oder eine nicht dokumentierte Middleware-Transformation muss als offener Vorbereitungspunkt sichtbar bleiben.
Categories, Products, SKUs und Specifications vorbereiten
Wählen Sie repräsentative Datensätze, die die VTEX-Hierarchie offenlegen: Category, Brand, Product, SKU, Specification Group, Product Specification und SKU Specification.
Berücksichtigen Sie:
- einfache Products mit einem SKU;
- Products mit mehreren SKUs;
- Products, deren SKU-Werte Größe, Farbe, Modell, Spannung, Region oder Verpackung definieren;
- Category-spezifische Specification Groups und vererbte Fields;
- Products mit Brands, Medien, zugehörigem Content oder externen PIM-Identifikatoren;
- Attachments, Services, Kits, Bundles oder Assembly-Option-Verhalten;
- Products, die von mehreren Sellers oder Kanälen angeboten werden.
| Quellverhalten | Vorbereitungsentscheidung für VTEX | Erforderlicher Nachweis |
|---|---|---|
| Wert unterscheidet die verkaufbare Einheit | SKU Specification und SKU-Beziehung definieren | Product-/SKU-IDs, Werte, Bilder, Stock und externe Schlüssel |
| Wert beschreibt das allgemeine Product | Product Specification definieren | Category, Specification Group, Field Type und Werte |
| Customer liefert Information | Attachment oder anderen Application Owner festlegen | Eingabedefinition und historische Order als Beispiel |
| Product enthält Komponenten oder optionale Artikel | Kit, Assembly Option, Service oder externen Owner definieren | Komponentenliste, Menge, Preis, Inventory und Order-Verhalten |
| Catalog wird durch PIM bereitgestellt | PIM- und VTEX-Identifikatoren erhalten | System of Record und Synchronisierungsschlüssel |
Bereinigen Sie doppelte Specification-Namen, inkonsistente Werte, verwaiste SKUs, fehlende Category-Zuordnungen und obsolete Products vor dem finalen Mapping. Der Catalog ist vorbereitet, wenn jede wichtige Product-Familie einen Plan für Category, Brand, Product, SKU, Specifications und externe IDs besitzt.
Trade Policies, Pricing, Sellers und kommerziellen Kontext vorbereiten
Trade Policies können Catalog, Pricing, Promotions, Inventory, Logistics, Payment Settings und Vertriebskanäle verbinden. Sellers und Marketplace Offers fügen eine weitere Ownership-Ebene hinzu.
| Kommerzieller Datensatz | Vorbereitung | Ready-Nachweis |
|---|---|---|
| Trade Policy | Vertriebskanal, Catalog-Verfügbarkeit, kommerzielle Regeln und zugehörige Operations definieren | Trade-Policy-Matrix |
| Price | SKU, Währung, Price Table, Customer- oder Kanalkontext und System of Record identifizieren | Repräsentative SKU-Preisbeispiele |
| Promotion | Bedingungen, Umfang, Laufzeiten und betroffene Products oder Customers dokumentieren | Inventar priorisierter Promotions |
| Seller | Seller-Identität, Products, Offers, Fulfilment-Verantwortung und externe IDs definieren | Seller-Ownership-Matrix |
| Marketplace Offer | Kanonische Catalog-Identität von seller-spezifischem Preis, Stock und Fulfilment trennen | Product-/SKU-/Seller-Mapping-Beispiel |
| B2B-Sortiment | Organization, Trade Policy, Catalog, Preis und Zugriffsbeziehungen definieren | Repräsentatives B2B-Buyer-Szenario |
Kanalpreise oder Seller-Datensätze aus der Quelle dürfen nicht als gewöhnliche Product-Felder behandelt werden. Ready ist der Bereich, wenn jeder priorisierte SKU einen definierten Price Owner, Trade-Policy-Umfang, eine Seller-Beziehung und eine Inventory-Verantwortung besitzt.
Customers, B2B-Datensätze und Master Data vorbereiten
Customer-bezogene Daten können gewöhnliche Profile, Adressen, Organizations, Buyer Roles, Cost Centers, Approval Context, Custom Forms, Consent, Loyalty, CRM IDs und Master-Data-Dokumente enthalten.
Bereiten Sie vor:
- registrierte Customers, Guests, mehrere Adressen, doppelte Identitäten und externe IDs;
- B2B Organizations, Users, Rollen, Cost Centers und kommerziellen Kontext;
- Custom Customer- und Workflow-Entitäten außerhalb der Standardprofile;
- Master-Data-Entity-Schemas, Fields, Keys, References und Consumer;
- Entscheidungen zu Consent, Privacy und Retention;
- CRM-, ERP-, Loyalty-, Marketplace- und Support-Identifikatoren.
| Quellobjekt | Owner | Erforderlicher Nachweis | Freigabebedingung |
|---|---|---|---|
| Customer Identity | Customer Operations | Beispiele für Duplikate und Guests | Identitäts- und Merge-Regeln sind dokumentiert. |
| B2B Organization | B2B Owner | Organization-/User-/Role-/Cost-Center-Matrix | Unternehmensbeziehungen haben einen definierten Zielverantwortlicher. |
| Master-Data-Dokument | Business Process Owner | Entity Schema und Referenzbeispiel | Key, Parent Relationship und fortbestehender Consumer sind bekannt. |
| Consent oder sensibles Field | Legal/Data Owner | Freigegebene Field-Liste | Erforderlicher Zweck und Retention-Basis sind dokumentiert. |
| Externer Key | Integration Owner | CRM-/ERP-/Marketplace-Lookup-Beispiel | Der Key ist der richtigen Entitätsebene zugeordnet. |
Master Data darf nicht zum Sammelplatz für undefinierte Quellfelder werden. Jedes Custom Document benötigt eine benannte Business Entity, einen Key, Beziehungen und einen zukünftigen Owner.
Historische Orders und operative Referenzen vorbereiten
Wählen Sie Orders aus, die Customer-Identität, Seller, Trade Policy, SKU Lines, Preise, Promotions, Taxes, Payment References, Shipping-Daten, Fulfilment, Status und externe IDs sichtbar machen.
Berücksichtigen Sie:
- gewöhnliche, stornierte, erstattete und teilweise erfüllte Orders;
- Orders aus jedem wichtigen Seller-, Trade-Policy-, Währungs- und Vertriebskanalkontext;
- Marketplace Orders;
- Orders mit mehreren Sendungen oder Carriers;
- Orders mit Kits, Attachments, Services oder Custom Data;
- Orders, die mit ERP, Accounting, WMS, Marketplace oder Support-Systemen verbunden sind.
| Historischer Bereich | Nachweis | Freigabebedingung |
|---|---|---|
| Product-/SKU-Lines | Repräsentatives Order-Paket | Gekaufter SKU, Seller, Menge, Preis und Custom Data sind nachvollziehbar. |
| Payment Context | Beispiele für Methode, Transaktion und Status | Historische Referenzen und Grenzen sensibler Daten sind dokumentiert. |
| Logistics Context | Beispiele für Shipping Method, SLA, Carrier, Warehouse, Dock, Tracking und Fulfilment | Historische Beziehung ist verständlich, ohne Live Logistics zu konfigurieren. |
| Anpassungen | Promotions, Taxes, Refunds, Cancellations und manuelle Änderungen | Historische Totals können erklärt werden. |
| Externe Abstammung | ERP-, Marketplace- oder Accounting-IDs | Reconciliation Keys bleiben auf der korrekten Order-Ebene erhalten. |
Historische Orders sind Nachweise vergangener Commerce-Aktivität. Aktuelle Checkout-, Payments-, OMS-, Logistics-, Carrier- und Warehouse-Konfiguration bleibt von den migrierten Order-Datensätzen getrennt.
Inventory, Logistics, Storefront Content und URLs vorbereiten
Für Inventory muss feststehen, welches System Quantity und Availability führt, welche Warehouses oder Sellers die einzelnen SKUs beliefern und wie Trade Policy sowie Logistics-Kontext dargestellt werden.
Für die Storefront-Vorbereitung sammeln Sie:
- Product- und Category-Content;
- CMS Pages, Landing Pages, Blog Posts, Guides und Campaign Content;
- Beispiele für Search, Facets, Navigation und Filters;
- priorisierte Product-, Category-, Brand-, Campaign- und Content-URLs;
- Metadata, Canonical Relationships und Redirects;
- Ownership des Headless Frontend oder CMS;
- Inventare für Media und Internal Links.
| Bereich | Vorbereitungsfrage | Ready-Nachweis |
|---|---|---|
| Inventory | Welches System, Warehouse, welcher Seller oder Feed führt die Menge jedes SKU? | SKU-/System-of-Record-Matrix |
| Logistics | Welche Warehouse-, Dock-, Carrier-, SLA-, Pickup- oder Fulfilment-Beziehung ist relevant? | Repräsentative Logistics-Map |
| Search und Facets | Welche Specifications und Categories unterstützen Discovery? | Kontrollierte Field- und Filterbeispiele |
| Content | Welches VTEX CMS, externe CMS oder Frontend Repository besitzt den Datensatz? | Content-Ownership-Inventar |
| URLs | Welche Route und welcher Redirect erhalten den jeweiligen priorisierten Quellpfad? | Source-/Destination-URL-Ledger |
Der Bereich ist vorbereitet, wenn Catalog Records, Inventory, Logistics, Content und Routes getrennte Owner besitzen und nicht als ein einziger Storefront-Export behandelt werden.
Apps, APIs und externe Systeme inventarisieren
Erstellen Sie ein Abhängigkeitsregister für jede App, API, jeden Middleware Flow, jede Custom Integration, jeden Webhook und jede externe Plattform, die Catalog-, Customer-, Order-, Price-, Seller-, Inventory-, Logistics- oder Content-Datensätze erzeugt oder verändert.
Dokumentieren Sie für jede Abhängigkeit:
- geschäftlichen Zweck;
- betroffene VTEX-Domäne und Datensätze;
- externes System of Record;
- IDs und Reference Keys;
- API- oder Exportverfügbarkeit;
- Business- und Technical Owner;
- Fortführung, Ersatz oder Einstellung im Ziel;
- Daten, die vor der Konfiguration des Zielworkflows benötigt werden.
Priorisierte Abhängigkeiten sind ERP, PIM, WMS, OMS, CRM, Accounting, Tax, Fraud, Search, Marketplace, Loyalty, Subscription, Personalization, Analytics und Content-Systeme.
Das Register ist vollständig, wenn jeder wichtige Wert genau einen maßgeblichen Owner und einen dauerhaften Key besitzt. Ein Middleware-Feld ohne definierte Source- und Destination-Entity ist kein ausreichender Nachweis.
Repräsentative Migrationstests auswählen
| Beispiel | Zweck der Vorbereitung |
|---|---|
| Product mit mehreren SKUs | Product-/SKU-/Specification-/Media-Beziehungen offenlegen |
| Category mit vererbten Specifications | Catalog-Hierarchie und Field Ownership prüfen |
| SKU in mehreren Trade Policies | Pricing-, Kanal-, Inventory- und Logistics-Kontext prüfen |
| Marketplace Product und Seller Offer | Kanonischen Catalog von Seller Ownership unterscheiden |
| B2B Customer oder Organization | Identity, Role, Cost Center und kommerziellen Kontext prüfen |
| Master-Data-Dokument | Custom Entity, Key, Reference und Owner prüfen |
| Komplexe historische Order | Seller, SKU, Promotion, Payment, Fulfilment und externe IDs prüfen |
| Headless Content oder Route | Frontend-, CMS-, SEO- und Redirect-Ownership prüfen |
Für jedes Beispiel sollten Quell-ID, gegebenenfalls Quell-URL, geschäftlicher Grund, vorgesehene VTEX-Domäne, externe Identifikatoren, bekannte Ausschlüsse und verantwortlicher Reviewer dokumentiert werden.
VTEX-Bereitschaftsprüfung abschließen
| Prüffrage | Erforderlicher Nachweis | Freigabebedingung |
|---|---|---|
| Sind Zugriffe und Quellarchive wiederherstellbar? | Zugriffsprotokoll und datierte Exporte/Backups | Erforderliche Datensätze können unabhängig vom Live-Quellshop geprüft werden. |
| Ist Domänenverantwortung dokumentiert? | VTEX-Domain- und External-System-Map | Jede wichtige Record Family hat einen Owner. |
| Sind Catalog- und SKU-Strukturen vorbereitet? | Product-/SKU-/Specification-Matrix | Jedes wichtige Product-Muster hat eine definierte VTEX-Repräsentation. |
| Sind Trade Policies, Sellers und Preise zugeordnet? | Commercial-Ownership-Matrix | Repräsentative Kanal- und Seller-Fälle sind vollständig. |
| Sind Customer- und Master-Data-Entitäten definiert? | Identity- und Entity-Diagramme | Keys, Beziehungen und Consumer sind dokumentiert. |
| Sind Orders und operative Referenzen erklärt? | Historisches Order-Paket | Vergangene Transaktionen bleiben verständlich. |
| Sind Apps und externe Systeme inventarisiert? | Abhängigkeitsregister | Jede kritische Abhängigkeit hat einen fortbestehenden Owner. |
| Sind repräsentative Migrationstests ausgewählt? | Sample Ledger | Catalog-, kommerzielle, Customer-, Order- und Storefront-Komplexität ist abgedeckt. |
| Sind offene Punkte kontrolliert? | Decision Log | Jeder offene Punkt hat einen Owner und Fälligkeitstermin. |
Die Vorbereitung ist abgeschlossen, wenn keine kritische Catalog-, SKU-, Trade-Policy-, Seller-, Customer-, Master-Data-, Order-, Inventory-, Route- oder Integrationsentscheidung mehr auf einer undokumentierten Annahme beruht.
Fazit
Die Vorbereitung auf eine mögliche Migration zu VTEX sollte ein domänenbezogenes Enterprise-Nachweispaket erzeugen. Categories, Products, SKUs, Specifications, Trade Policies, Sellers, Preise, Customers, Master Data, Orders, Logistics, Content und Integrationen benötigen jeweils einen klaren Owner und repräsentative Datensätze.
Werden diese Entscheidungen vor dem repräsentativen Migrationstest getroffen, kann die Stichprobe die beabsichtigte VTEX-Architektur tatsächlich abbilden, statt eine Sammlung importierter Datensätze fälschlich mit einem vollständigen Commerce-Betrieb gleichzusetzen.
Häufige Fragen
Welcher VTEX-Vorbereitungsnachweis sollte zuerst erstellt werden?
Beginnen Sie mit der Domain-Ownership-Map für Catalog, kommerziellen Kontext, Customers, Orders, Operations, Storefront und externe Systeme. Sie bestimmt, welche weiteren Nachweise und Owner benötigt werden.
Warum müssen Products und SKUs getrennt vorbereitet werden?
Das Product repräsentiert die allgemeine kommerzielle Definition, jeder SKU eine verkaufbare Variante. Specifications, Bilder, Inventory, Preise, Seller Offers und Order Lines können von der SKU-Beziehung abhängen.
Was sollte für Trade Policies vorbereitet werden?
Dokumentieren Sie Vertriebskanal, SKU-Verfügbarkeit, Preiskontext, Promotions, Inventory, Logistics, Payment-Beziehungen, Sellers und externe Systeme für jede priorisierte Trade Policy.
Wie sollte Master Data vorbereitet werden?
Definieren Sie jede Entity, ihr Schema, den dauerhaften Key, Parent Relationships, Consumer, Privacy-Anforderungen und Zielverantwortlicher. Master Data darf nicht als generischer Speicherort für undefinierte Felder dienen.
Wie sollten historische Orders für VTEX vorbereitet werden?
Stellen Sie repräsentative Orders mit SKU Lines, Sellers, Preisen, Promotions, Taxes, Payment References, Shipping Context, Fulfilment, Statuswerten und externen IDs bereit. Halten Sie diese Nachweise von aktueller operativer Konfiguration getrennt.
Wann ist die VTEX-Vorbereitung abgeschlossen?
Wenn Domain Ownership, Catalog-Strukturen, kommerzielle Beziehungen, Customer- und Master-Data-Entitäten, Orders, Content, Routes, Integrationen, Samples und offene Entscheidungen vollständig dokumentiert und verantwortlichen Ownern zugeordnet sind.