Wer VTEX als mögliche Zielplattform bewertet, muss die Plattform als vernetztes Enterprise-Commerce-System verstehen und nicht als einen einzelnen Shop mit einer zentralen Katalogdatenbank. VTEX ist eine Cloud-Commerce-Plattform für komplexe Betriebsmodelle, Erweiterbarkeit und miteinander verbundene Commerce-Services. Die Architektur umfasst Catalog, Pricing, Promotions, Checkout, Orders, Logistics, Payments, Search, Master Data, Marketplace-Funktionen, B2B-Funktionen, Storefront-Entwicklung und Anwendungsinfrastruktur. Eine VTEX-Implementierung kann als Direct-to-Consumer-Shop, Multi-Brand-Umgebung, Marketplace, Seller für externe Marketplaces, B2B-Kanal oder als Kombination dieser Modelle betrieben werden.
Diese Breite unterscheidet VTEX deutlich von Plattformen, bei denen der Commerce-Betrieb weitgehend in einer Katalogdatenbank und einer Storefront zusammenläuft. Die Verfügbarkeit eines Produkts kann von der Aktivierung des SKU, Bestand, Preis, Trade Policy, Seller-Beziehung, Logistics und Storefront-Konfiguration abhängen. Ein Product kann im Catalog vorhanden und dennoch nicht kaufbar sein, weil eine dieser verbundenen Ebenen unvollständig ist. Ein Marketplace-Angebot kann unter einem Product erscheinen, obwohl ein anderer Seller dessen Preis, Bestand und Fulfilment verantwortet. Eine Headless-Storefront kann VTEX-Commerce-Daten darstellen, ohne dieselbe Implementierungsebene wie die Administrationsumgebung zu verwenden.
Eine Migration zu VTEX ist deshalb nicht nur die Übertragung von Products, Customers und Orders. Sie rekonstruiert geschäftliche Beziehungen über mehrere modulare Services hinweg. Das Zielkonto muss ausdrücken, welche Artikel existieren, welche SKUs verkaufbar sind, wer sie anbietet, wo Bestand liegt, welche Preise gelten, über welche Kanäle sie verkauft werden können, wie der Checkout die Auftragsabwicklung auflöst und welche Storefront oder Anwendung die resultierenden Daten verwendet.
VTEX als Cloud-Commerce-Architektur
VTEX stellt eine verwaltete Cloud-Plattform bereit und kein selbst gehostetes Anwendungspaket. Kernservices, Plattforminfrastruktur und Commerce-APIs laufen innerhalb der VTEX-Umgebung. Händler und Implementierungspartner konfigurieren Geschäftsregeln, binden externe Systeme an, entwickeln Storefronts und erweitern Funktionen über die unterstützten Anwendungs- und API-Modelle.
Die Plattform ist bewusst modular aufgebaut. Katalogdatensätze bestimmen das Kundenerlebnis nicht allein. Pricing, Promotions, Inventory, Logistics, Sellers, Trade Policies, Checkout, Search und Storefront-Rendering tragen jeweils einen eigenen Teil zum Endergebnis bei. Diese Modularität unterstützt Enterprise-Skalierung und unterschiedliche Betriebsmodelle, erhöht aber zugleich die Abhängigkeit von korrekt aufgebauten Beziehungen zwischen den Services.
| VTEX-Ebene | Hauptzweck | Bedeutung für die Migration |
|---|---|---|
| Catalog | Categories, Brands, Products, SKUs, Specifications, Bilder, Attachments, Services, Kits und Collections | Konzepte des Quellkatalogs müssen in die Product-SKU-Hierarchie und das an Categories gekoppelte Specification-Modell von VTEX übersetzt werden. |
| Pricing und Promotions | Kommerzielle Werte und Aktionsregeln | Ein Product-Datensatz bestimmt nicht alle Verkaufspreise oder Promotion-Ergebnisse. |
| Logistics | Bestand, Docks, Warehouses, Shipping Policies und Auftragsabwicklung | Die Verfügbarkeit eines SKU hängt von operativer Konfiguration außerhalb des Product-Datensatzes ab. |
| Sellers und Marketplace | Eigentümerschaft von Angeboten und Marketplace-Beziehungen | Der Händler kann den Catalog verwalten, während ein anderer Seller Preis, Bestand und Fulfilment verantwortet. |
| Checkout und Orders | Transaktionssteuerung und Verwaltung historischer Orders | Das aktuelle Kaufverhalten hängt von Zielkonfiguration und Integrationen ab, nicht nur von migrierter Order-Historie. |
| Storefront und Anwendungen | Kundenseitiges Erlebnis und Erweiterungen | Commerce-Daten können über unterschiedliche Storefront-Architekturen und benutzerdefinierte Anwendungen dargestellt werden. |
Die Plattformbeschreibung von VTEX stellt Cloud-Infrastruktur, Sicherheit, Datenschutz, Composability, Erweiterbarkeit, Store-Architektur und Developer Experience in den Mittelpunkt. Diese Aspekte sind für eine Migration nicht nebensächlich. Sie bestimmen, wie die Zielumgebung gesteuert wird und welche Teams die unterschiedlichen Ebenen des Projekts verantworten.
Katalogarchitektur: Categories, Products und SKUs
Der VTEX Catalog beginnt mit Categories und Brands und definiert darauf Products und SKUs. Ein Product beschreibt den allgemeinen kommerziellen Artikel, während ein SKU die konkret kaufbare Variante darstellt, für die Bestand geführt wird und die der Käufer auswählt. Jedes Product gehört zu einer Category und einer Brand, und jedes Product benötigt mindestens einen SKU.
Auch Specifications sind strukturell wichtig. VTEX ordnet Specification Groups Categories zu; diese Gruppen können an darunterliegende Category-Ebenen vererbt werden. Product Specifications beschreiben Eigenschaften auf Product-Ebene, SKU Specifications unterscheiden kaufbare Varianten. Quellattribute lassen sich daher erst dann sicher zuordnen, wenn geklärt ist, ob sie das gesamte Product klassifizieren, einen SKU definieren, Filterung unterstützen oder nur beschreibenden Inhalt liefern.
| Konzept im Quellshop | Mögliche VTEX-Zielstruktur | Zentrale Interpretationsfrage |
|---|---|---|
| Parent Product | Product | Beschreibt das Quellobjekt einen allgemeinen Artikel oder lediglich einen Gruppierungscontainer? |
| Variant | SKU | Entspricht jede Quellvariante einer separat kaufbaren und bestandsgeführten Einheit? |
| Attribute | Product oder SKU Specification | Beschreibt der Wert das gesamte Product oder unterscheidet er einen kaufbaren SKU? |
| Option oder Personalisierung | Attachment, Assembly Option, Service oder SKU-Struktur | Verändert die Auswahl Bestandsidentität, Preis, Menge oder vom Käufer bereitgestellte Informationen? |
| Bundle | Kit oder Assembly-bezogene Struktur | Sind Komponenten fest, optional, separat bestandsgeführt oder separat bepreist? |
| Collection | Collection oder Storefront-Merchandising-Struktur | Ist die Gruppierung taxonomisch, werblich, saisonal oder nur für die Darstellung bestimmt? |
In VTEX reicht es nicht, Product- und SKU-Datensätze anzulegen. Categories, Brands, Specification Groups, Specifications, Bilder, SKU-Aktivierung, Preis, Bestand und Verfügbarkeit im jeweiligen Vertriebskontext müssen zusammenspielen, bevor ein Artikel tatsächlich verkauft werden kann. Deshalb kann ein reiner Vergleich von Datensatzanzahlen den Migrationsfortschritt überschätzen. Die entscheidende Einheit ist die aktive kommerzielle Beziehung, nicht eine isolierte Product-Zeile.
Attachments, Assembly Options, Services und Kits erweitern das Product-Modell. Attachments können optionale Informationen zu einem SKU erfassen. Assembly Options unterstützen komplexere Zusammenstellungen, Mengen, zusätzliche Artikel, Kosten und Bestandsbeziehungen. Services können kostenpflichtige Ergänzungen wie Geschenkverpackung oder Garantie darstellen. Kits bündeln SKUs für den gemeinsamen Verkauf. Diese Strukturen haben jeweils eine andere operative Bedeutung und dürfen nicht in einem generischen Optionsfeld zusammengefasst werden.
Trade Policies, Accounts und Kanalkontext
VTEX nutzt Trade Policies, um den kommerziellen Kontext verschiedener Kanäle zu steuern. Eine Trade Policy kann die Product-Verfügbarkeit und weitere Verkaufsbedingungen für einen bestimmten Kanal oder Betriebskontext beeinflussen. Enterprise-Accounts können außerdem mehrere Stores, Brands, Länder, Geschäftseinheiten oder Storefronts enthalten, deren Kataloge sich überschneiden, ohne sich identisch zu verhalten.
Für die Migration ist dieses kanalbezogene Modell wichtig, weil Quellshops Markt- oder Kanalunterschiede oft weniger explizit abbilden. Eine Quellplattform kann getrennte Websites, Preislisten, Customer Groups, Warehouses, Subdomains oder Custom Fields nutzen, um Unterschiede darzustellen, die VTEX über Trade Policies und Account-Konfiguration ausdrückt. Das Zieldesign muss entscheiden, welche dieser Unterschiede erhalten, zusammengeführt oder als kanalspezifische Konfiguration neu abgebildet werden sollen.
Ein Product, das in einer Trade Policy aktiv ist, muss nicht für eine andere bestimmt sein. Auch Preise, Logistics, Sellers, Promotions und Checkout-Abläufe können je nach kommerziellem Kontext variieren. Wird nur ein globaler Product-Datensatz migriert, ohne diese Unterscheidungen zu erhalten, können Produkte zu breit sichtbar werden, Sortimente fehlen oder Verkaufsregeln falsch greifen.
Sellers, Marketplaces und Eigentümerschaft von Offers
VTEX unterstützt sowohl Marketplace- als auch Seller-Betriebsmodelle. Ein VTEX-Account kann als Marketplace Angebote externer Sellers aufnehmen oder selbst als Seller seinen Katalog und seine Offers an externe Marketplaces verteilen. Eine Katalogintegration kann daher deutlich mehr als Product-Eigentümerschaft umfassen.
In einem Marketplace-Modell kann der Marketplace die gemeinsame Product-Darstellung verantworten, während Sellers die Offers besitzen, einschließlich Preis, Bestand, Fulfilment-Bedingungen und seller-spezifischen Identifikatoren. Product- und Category-Mappings können unterschiedliche Katalogtaxonomien über Marketplace-Beziehungen hinweg verbinden. Dasselbe Product kann mehrere Seller Offers mit jeweils eigener kommerzieller Verfügbarkeit haben.
| Marketplace-Element | Operative Bedeutung | Bedeutung für die Migration |
|---|---|---|
| Product | Gemeinsame Katalogidentität und Merchandising-Informationen | Doppelte Quelllistings können um eine gemeinsame Product-Identität im Ziel konsolidiert werden müssen. |
| SKU | Kaufbare Product-Variante | Seller Offers müssen auf den richtigen SKU verweisen, statt unverbundene Artikel zu erzeugen. |
| Seller | Organisation, die ein Offer verantwortet | Seller-Identität, Berechtigungen und operative Eigentümerschaft sind keine gewöhnlichen Customer-Daten. |
| Offer | Seller-spezifischer Preis-, Bestands- und Fulfilment-Kontext | Offers dürfen nicht auf Product-Preise reduziert werden. |
| Mapping | Beziehung zwischen externen und VTEX-Categories oder Products | Taxonomie- und Identifikatorübersetzung muss kontrolliert bleiben. |
| Order Flow | Transaktionssteuerung zwischen Marketplace und Seller | Historische Orders und aktives Marketplace-Routing sind getrennte Ebenen. |
Dieses Betriebsmodell unterscheidet VTEX deutlich von einer Plattform für nur einen Händler. Eine Migration, die Seller- und Offer-Beziehungen ignoriert, kann sichtbare Products erhalten und gleichzeitig die Eigentumsstruktur verlieren, auf der der Marketplace-Betrieb beruht.
Pricing, Inventory, Logistics und Verkaufbarkeit
VTEX trennt die Kernidentität im Catalog von den Services, die einen SKU kommerziell verfügbar machen. Preise werden über Pricing-Strukturen verwaltet. Inventory ist mit Logistics und Fulfilment-Standorten verknüpft. Shipping Policies, Docks, Warehouses, Carrier und Lieferbedingungen bestimmen mit, ob der Checkout eine gültige Auftragsabwicklung ermitteln kann. Promotions können kommerzielle Ergebnisse unabhängig vom Basispreis verändern.
Verkaufbarkeit ist damit mehrschichtig. Ein SKU kann vorhanden sein und Bilder sowie Specifications besitzen, aber nicht verfügbar sein, weil kein gültiger Preis, kein Bestand, keine passende Trade Policy, kein Seller Offer oder kein Fulfilment-Pfad existiert. Umgekehrt kann derselbe SKU in verschiedenen Kanälen zu unterschiedlichen Preisen oder Logistics-Bedingungen verkauft werden.
Quellplattformen bündeln diese Ebenen häufig in weniger Feldern. Eine Product-Tabelle kann zugleich Preis und Bestand enthalten, ein Warehouse-Plugin Standortdetails speichern und ein Shipping-Modul Lieferbedingungen separat berechnen. In VTEX müssen diese Konzepte den Services zugeordnet werden, die sie verantworten. Die Migration muss deshalb die Beziehung zwischen Artikelidentität und kommerzieller Ausführung erhalten.
Customers, Master Data, Checkout und Orders
Customer-Identität kann in VTEX Account-Datensätze, Adressen, Profile, organisatorische Informationen, Einwilligungen, Custom Fields sowie Daten in Master Data oder angebundenen Kundensystemen umfassen. B2B-Implementierungen können Organizations, Cost Centers, Rollen, Berechtigungen, Preiskontexte und Freigabelogik ergänzen. Diese Strukturen entsprechen nicht einer flachen Liste registrierter Benutzer.
Checkout steuert den aktiven Kaufprozess über Artikel, Sellers, Preise, Inventory, Logistics, Payments, Promotions und Customer-Kontext hinweg. Orders dokumentieren abgeschlossene Transaktionen und unterstützen die operative Verarbeitung. Historische Orders können wertvollen Kontext für Kundenservice und Reporting bewahren, stellen aber nicht automatisch das Live-Checkout-Verhalten im Zielkonto her.
Dieser Unterschied ist wesentlich: Eine Migration kann Customer-Namen, Adressen und Order-Summen korrekt übertragen und dennoch organisatorische Berechtigungen, benutzerdefinierte Profildaten, Payment-Konfiguration, Logistics, Marketplace-Routing oder Checkout-Integrationen unvollständig lassen. Die modulare Architektur von VTEX macht diese Grenzen ausdrücklich sichtbar.
Storefront-Modelle, VTEX IO und Composability
VTEX unterstützt unterschiedliche Storefront- und Anwendungsansätze. VTEX IO stellt eine cloudbasierte Entwicklungs- und Anwendungsumgebung bereit; Store Framework und andere Storefront-Optionen können VTEX-Commerce-Services nutzen. Headless-Implementierungen können eigene Frontends einsetzen, die über APIs und Services mit der Plattform interagieren.
Eine Storefront ist deshalb nicht einfach ein Theme, das an migrierte Products angehängt wird. Sie ist eine Implementierungsebene für Navigation, Product-Darstellung, Search, Content, Account Experience, Analytics und Checkout-Integration. Themes, Templates, Widgets und Scripts aus dem Quellshop werden nicht automatisch zu VTEX-Storefront-Komponenten.
Composability und Erweiterbarkeit ermöglichen zusätzliche Anwendungen und Integrationen, ohne einen selbst gehosteten Kerncode verändern zu müssen. Diese Flexibilität verteilt jedoch die Verantwortung stärker auf Plattformkonfiguration, Anwendungen, externe Systeme und Frontend-Code. Datenbereitschaft und Storefront-Bereitschaft hängen zusammen, sind aber nicht dasselbe.
Integrationen und Eigentümerschaft in Enterprise-Systemen
VTEX arbeitet häufig neben ERP-, PIM-, OMS-, WMS-, CRM-, Marketplace-, Steuer-, Payment-, Search- und Analytics-Systemen. Die Catalog-Leitlinien beschreiben ausdrücklich Backoffice-Integrationsflüsse für das Erstellen und Aktualisieren von Katalogdaten. In vielen Implementierungen ist VTEX daher nicht das alleinige führende System für Products, Preise, Inventory, Customers oder Orders.
Damit entsteht eine zentrale Migrationsfrage: Welches System wird einen Datensatz nach dem Launch führen? Ein migrierter Wert kann später durch einen ERP-Feed überschrieben werden. Während der Migration importierter Bestand kann bedeutungslos werden, sobald die WMS-Synchronisierung startet. Product-Beschreibungen können in einem PIM gepflegt werden, während Marketplace Offers aus Seller-Connectors kommen. Customer-Daten können in einem CRM ergänzt oder gesteuert werden.
| Datenbereich | Mögliches führendes System | Erforderliche Beziehung in VTEX |
|---|---|---|
| Product Content | PIM, ERP oder VTEX Catalog | Stabile Product-, SKU-, Category-, Brand- und Specification-Identifikatoren |
| Preis | ERP, Pricing-Plattform oder VTEX Pricing | Korrekte Preisdatensätze je kommerziellem Kontext |
| Inventory | WMS, ERP, Seller oder VTEX Logistics | Gültige SKU-Standort-Mengen und eindeutig geregelte Synchronisierungsverantwortung |
| Customer | CRM, Master Data oder Account Services | Konsistente Identitäts- und Adressbeziehungen |
| Order | VTEX Orders, OMS, ERP oder Marketplace Flow | Verlässliche Identifikatoren, Statuswerte und nachgelagerte Verarbeitung |
| Seller Offer | Seller-System oder Marketplace-Connector | Korrektes Product-SKU-Mapping sowie Preis-, Bestands- und Fulfilment-Kontext |
Die API-orientierte und erweiterbare Architektur unterstützt solche Integrationen, ersetzt aber keine Data-Governance-Entscheidungen. Bevor automatisierte Datenflüsse die Zielumgebung aktualisieren, müssen stabile Identifikatoren und klare Eigentümerschaft feststehen.
VTEX im weiteren Plattformumfeld
VTEX liegt konzeptionell näher an Composable- und Enterprise-Commerce-Plattformen als an einfachen gehosteten Shop-Baukästen. Die Plattform bietet eine verwaltete Cloud-Basis und zugleich spezialisierte Services, APIs, Marketplace-Beziehungen, Storefront-Entwicklungsoptionen und Enterprise-Betriebssteuerung.
Im Vergleich zu einfacheren SaaS-Plattformen verteilt VTEX mehr Teile des Commerce-Lebenszyklus auf eigenständig gesteuerte Services. Gegenüber selbst gehosteten Open-Source-Plattformen reduziert VTEX die direkte Verantwortung für Infrastruktur und Kerncode und verlagert den Schwerpunkt auf Konfiguration, APIs, Anwendungen und verbundene Systeme. Gegenüber einem vollständig individuell zusammengesetzten Composable Stack stellt VTEX eine integrierte Commerce-Plattform bereit, statt jeden Service separat auswählen und verbinden zu müssen.
Daraus ergibt sich die Bedeutung für die Migration. VTEX kann komplexe Kataloge, Kanäle, Sellers, Marketplaces, B2B-Strukturen und Integrationen abbilden, doch die Zielarchitektur muss bewusst entworfen werden. Products und Orders bilden nur einen Teil des Betriebsmodells; kommerzieller Kontext, Service-Beziehungen und Systemverantwortung entscheiden darüber, ob die Plattform tatsächlich nutzbar ist.
Fazit
VTEX ist eine modulare Cloud-Commerce-Plattform, deren Kernidentität Catalog, SKUs, Specifications, Pricing, Promotions, Inventory, Logistics, Trade Policies, Sellers, Marketplaces, Checkout, Orders, Master Data, Storefronts, Anwendungen und Integrationen miteinander verbindet. Komplexe Enterprise-Betriebsmodelle werden gerade dadurch unterstützt, dass diese Bereiche verbunden, aber getrennt gesteuert werden.
Für eine mögliche Migration zu VTEX besteht die zentrale Aufgabe darin, diese Beziehungen bewusst neu aufzubauen. Products müssen in die Product-SKU-Hierarchie von VTEX übersetzt werden. Specifications müssen die richtige Product- oder SKU-Bedeutung behalten. Verkaufbarkeit muss Preis, Inventory, Seller, Logistics und Kanalkontext zusammenführen. Customer- und Order-Datensätze bleiben von Live-Checkout- und B2B-Verhalten zu unterscheiden. Storefronts und Enterprise-Integrationen benötigen stabile Identifikatoren und klare Systemverantwortung. Diese Architektur bildet die Grundlage für alle weiteren Artikel im VTEX-Hub.
Häufige Fragen
Was ist der Unterschied zwischen einem Product und einem SKU in VTEX?
Ein Product beschreibt den Artikel allgemein. Ein SKU ist die konkrete kaufbare Variante, für die Bestand geführt wird und die der Käufer auswählt. Jedes VTEX Product benötigt mindestens einen SKU.
Warum sind Specifications in VTEX wichtig?
Specifications beschreiben Eigenschaften eines Product oder SKU und sind über Groups mit Categories verbunden. Sie können Varianten, Filter, Klassifizierung und Storefront-Darstellung unterstützen. Quellattribute müssen deshalb nach ihrer tatsächlichen Funktion zugeordnet werden.
Was beschreibt eine Trade Policy?
Eine Trade Policy legt den kommerziellen Kontext für einen Kanal oder Betrieb fest. Sie kann Product-Verfügbarkeit und weitere Verkaufsbedingungen beeinflussen und ermöglicht damit unterschiedliche Märkte oder Kanäle innerhalb desselben Accounts.
Wie behandelt VTEX Marketplace-Sellers?
VTEX kann Seller Offers mit gemeinsamen Products und SKUs verbinden. Sellers können Preis, Bestand und Fulfilment-Kontext verantworten, während der Marketplace die Katalogdarstellung und Transaktionssteuerung übernimmt.
Sind Products nach der Migration zu VTEX sofort verkaufbar?
Nicht zwingend. Ein SKU kann zusätzlich gültige Specifications, Bilder, Aktivierung, Preis, Inventory, Seller-Kontext, Verfügbarkeit über die passende Trade Policy und Logistics benötigen, bevor er gekauft werden kann.
Ist eine VTEX-Storefront Bestandteil der migrierten Daten?
Eine Storefront ist eine separate Implementierungsebene. Product- und Content-Daten können das Erlebnis unterstützen, doch Themes und Frontend-Code aus dem Quellshop müssen innerhalb der gewählten VTEX-Storefront-Architektur neu umgesetzt werden.