Wenn VTEX als mögliche Zielplattform gewählt wird, hängt der passende Migrationsansatz davon ab, wie viel des Commerce-Betriebs über die gewöhnliche Datensatzübertragung hinaus interpretiert, transformiert, konfiguriert oder validiert werden muss. VTEX kann anspruchsvolle Catalog-Strukturen, Storefront-Implementierungen, Marketplace-Betrieb, B2B-Szenarien, Master Data, Integrationen und externe Services unterstützen. Gerade diese Stärke macht es notwendig, unterstützte Datenmigration klar von Zielimplementierung und benutzerdefinierter Geschäftslogik zu trennen.
Auch eine kleine VTEX-Migration kann eine sorgfältige Wahl des Servicepfads verlangen, wenn Quelldaten von Custom Fields, externen Identifikatoren, Marketplace-Beziehungen oder Headless-Storefront-Annahmen abhängen. Eine große Migration kann dagegen mit einem leichteren Ansatz auskommen, wenn die Daten unterstützt werden, die Zielstruktur klar ist und der Händler das Ergebnis zuverlässig validieren kann. Maßgeblich sind Nachweise, nicht der Ruf der Plattform oder die Anzahl der Datensätze.
Innerhalb der Next-Cart Migrationsservices sollten die VTEX-Nachweise zwischen unterstützten Datensätzen, Ausführungsaufwand, klar begrenzten Add-ons, Marketplace- oder Master-Data-Anforderungen und Implementierungsarbeit außerhalb des Migrationsumfangs unterscheiden.
Was der Migrationsansatz für VTEX bedeutet
Ein VTEX-Migrationsansatz ist eine Entscheidung über Umfang, Verantwortung, Supportniveau, Konfiguration und Validierungsaufwand. Er sollte erklären, welche Datensätze voraussichtlich migriert werden, welche Funktionsweisen in VTEX konfiguriert werden müssen, welche unterstützten Datensätze oder Felder eine Datenkategorie-Bedingung, eine Werte-Expression oder ein anderes Ziel benötigen, welche Anforderungen Custom Service erfordern und welche Launch-Aufgaben dem Implementierungsteam des Händlers gehören.
Vier Arbeitsebenen sollten getrennt werden:
| Arbeitsebene | VTEX-Beispiel | Auswirkung auf den Servicepfad |
|---|---|---|
| Unterstützte migrierte Datensätze | Products, SKUs, Categories, Brands, Customers, Orders, Bilder, CMS Pages, Blog Posts und unterstützte zugehörige Felder | Je nach Ausführungs- und Validierungsbedarf kann Standard Service oder Managed Service passen. |
| Unterstützte Migrationsanpassungen | Datenkategorie-spezifische Datensatzbedingungen, expressionsbasierte Änderungen von Feldwerten oder kompatible alternative Zielpositionen für unterstützte Quellfelder | Kann Data Filter, Advanced Data Mapping oder Data Transformation erfordern. |
| Custom- oder nicht unterstützte Migrationsanforderungen | Master-Data-Entitäten, app-eigene Werte, Marketplace-spezifischer Kontext, externe IDs, spezielle Transformation oder Interpretation einer individuellen Plattform | Erfordert Prüfung im Rahmen von Custom Service. |
| VTEX-seitige Implementierung | Storefront, Apps, Integrationen, Live Checkout, Payments, Logistics, Search, Promotions, Seller Setup und operative Konfiguration | Wird außerhalb der gewöhnlichen Datensatzmigration vorbereitet und validiert. |
Diese Trennung schützt vor zwei typischen Fehlern: einem zu leichten Ansatz, nur weil die Datentypen vertraut klingen, und dem vorschnellen Einsatz von Custom Service für Arbeit, die tatsächlich eine unterstützte Migrationsanpassung oder VTEX-seitige Implementierung ist.
Wann Standard Service ausreichen kann
Standard Service kann geeignet sein, wenn die Quelldaten innerhalb des unterstützten Migrationsverhaltens liegen, die VTEX-Zielstruktur vorhersehbar ist und der Händler Setup, Prüfung und Freigabe selbst verantworten kann. Besonders gut passt dieser Weg, wenn Products und SKUs gewöhnliche Strukturen haben, Categories und Brands klar definiert sind, Customer-Datensätze standardmäßig aufgebaut sind, Order History vor allem als lesbare Referenz benötigt wird und nur wenig benutzerdefinierte Plattformlogik existiert.
Standard Service sollte nicht nach dem Volumen beurteilt werden. Ein großer unterstützter Catalog kann geeignet sein, wenn die Product-SKU-Beziehung sauber ist und repräsentative Samples zuverlässig geprüft werden können. Ein kleinerer Store kann ungeeignet sein, wenn zentrale Datensätze von Custom Quellfelder, Master Data, Marketplace Ownership oder der Interpretation externer Systeme abhängen.
| Signal für Standard-Service-Bereitschaft | VTEX-spezifischer Grund |
|---|---|
| Products und SKUs besitzen klare Quellstrukturen. | Das VTEX-Catalog-Mapping kann ohne spezielle Transformation geprüft werden. |
| Specifications, Categories und Brands sind stabil und unterstützt. | Discovery- und Merchandising-Werte lassen sich anhand gewöhnlicher Samples validieren. |
| Customers und Orders sind überwiegend Standarddatensätze. | Historischer Kontext kann ohne benutzerdefinierten Account-Neuaufbau nutzbar bleiben. |
| Pricing und Promotions benötigen keine besondere Transformation. | Kommerzielles Setup kann über unterstützte Migration oder VTEX-Konfiguration behandelt werden. |
| Marketplace-, B2B- und Master-Data-Erwartungen sind begrenzt oder ausgeschlossen. | Die Migration hängt weniger wahrscheinlich von nicht unterstützten oder benutzerdefinierten Daten ab. |
| Der Händler kann das Ergebnis validieren. | Kundengeführte Prüfung bleibt praktikabel. |
Standard Service wird riskant, wenn der Händler nicht beschreiben kann, wie ein bestandener VTEX-Sample aussehen soll. Sind Erfolgskriterien unklar, betrifft das nicht nur die Ausführung; der Umfang selbst muss geschärft werden.
Wann Managed Service die sicherere Wahl sein kann
Managed Service kann sinnvoller sein, wenn die Migration innerhalb der unterstützten Fähigkeiten bleibt, das Projekt aber stärkere Unterstützung bei Ausführung, Sequenzierung und Koordination benötigt. Die Daten müssen keine individuelle Transformation erfordern; dennoch kann dem Händler Zeit oder Erfahrung fehlen, um Migrationsaktionen, Sample Reviews, Issue Coordination und Launch Timing selbstständig zu steuern.
Für VTEX ist Managed Service häufig relevant, wenn der Catalog groß ist, Product-/SKU-Prüfung zeitkritisch wird, mehrere Stakeholder unterschiedliche Ebenen freigeben müssen oder die Launch-Planung Migration und VTEX-Implementierungsarbeit miteinander koordinieren muss. Managed Service unterstützt den Migrationsprozess, erweitert aber nicht die Grenze unterstützter Anforderungen.
| Passender Managed-Service-Fall | VTEX-Szenario |
|---|---|
| Unterstützte Daten mit hohem Prüfaufwand | Großer Catalog, viele SKUs, viele Bilder oder umfangreiche historische Orders |
| Mehrere Business Owner müssen Samples freigeben | Catalog-, Pricing-, Operations-, Support-, SEO-, Storefront- und Integrationsteams müssen jeweils prüfen. |
| Enges Launch-Fenster | Migration muss mit Zielsetup und Änderungen im Quellshop abgestimmt werden. |
| Händler benötigt Ausführungsunterstützung | Next-Cart-geführte Ausführung ist hilfreich, während der Händler die finale Verifizierung verantwortet. |
| Standardumfang ist klar, operativer Druck aber hoch | Das Projekt benötigt Koordination statt individueller Migrationslogik. |
Managed Service sollte für Ausführung und Koordination gewählt werden. Custom Service bleibt zu prüfen, wenn nicht unterstützte Datensätze, externe Identifikatoren, Master-Data-Interpretation, spezielle Transformation oder Anpassungen der Migrationslogik benötigt werden.
Wann Add-ons das richtige Werkzeug sind
Add-ons sind geeignet, wenn eine Anforderung unterstützt, klar begrenzt und spezifisch ist. Data Filter kann getrennte Bedingungen auf geeignete VTEX-Catalog- oder Commerce-Entitäten anwenden. Data Transformation kann über eine Expression einen definierten Feldwert erzeugen. Advanced Data Mapping kann ein unterstütztes Quellfeld in ein anderes VTEX-Zielfeld schreiben. Eine nicht unterstützte oder benutzerdefinierte Anforderung gehört weiterhin in die Custom-Service-Prüfung.
Eine starke Add-on-Anforderung wird als konkretes Abnahmekriterium formuliert. Beispielsweise kann der Händler Products ausschließen wollen, die eine definierte Quellfeldbedingung erfüllen, einen unterstützten Wert durch eine Expression verändern oder ein Quellfeld in ein anderes VTEX-Feld abbilden. Schwach wäre eine Anforderung wie "die VTEX-Struktur soll unserem benutzerdefinierten Quellworkflow entsprechen"; dies kann tatsächlich Custom Service oder Zielimplementierung erfordern.
| Add-on-Bedarf | VTEX-Beispiel | Grenzprüfung |
|---|---|---|
| Data Filter | Unterstützte Product-, Customer-, Blog-Post- oder Order-Feldbedingungen anwenden, sodass nur passende Datensätze migrieren. | Filtering darf keine Datensätze entfernen, die für Reporting, Service oder SEO-Kontinuität benötigt werden. |
| Data Transformation | Expressions nutzen, um unterstützte für VTEX bestimmte Feldwerte während der Migration zu transformieren. | Expression und Ergebnis müssen innerhalb der unterstützten Fähigkeit bleiben. |
| Advanced Data Mapping | Unterstützte Quellfelder in andere VTEX-Product-, SKU-, Customer-, Order- oder Content-Felder abbilden. | Mapping darf kein nicht unterstütztes VTEX-Verhalten erzeugen. |
| Bedarf an Tailored Add-on oder Custom Add-on | Die Funktion eines Standard Add-on benötigt projektspezifische Anpassung oder eine individuelle Add-on-Funktion wird benötigt. | Diese Arbeit wird über Custom Service geprüft und angeboten, nicht als Standard Add-on behandelt. |
Add-ons funktionieren am besten, wenn Quell- und Zielbedeutung eindeutig sind. Sie sind ungeeignet als Ersatz für die Entscheidung, ob eine Anforderung tatsächlich benutzerdefiniert ist.
Wann Custom Service geprüft werden sollte
Custom Service sollte geprüft werden, wenn der Erfolg der VTEX-Migration von Daten, Verhalten oder Interpretation außerhalb der unterstützten Standardfähigkeit abhängt. Auslöser ist nicht die Unternehmensgröße, sondern der Bedarf an individueller Migrationslogik, spezieller Transformation, nicht unterstützten Datensätzen, Behandlung einer individuellen Plattform, Master-Data-Interpretation, externen Identifikatoren, app-eigenen Werten, Marketplace-spezifischer Rekonstruktion oder integrationssensitiver Datenbehandlung.
Custom Service kann auch bei wenigen sichtbaren Datensätzen relevant sein. Ein kleiner Product-Bestand kann individuelle Behandlung benötigen, wenn jedes Product von externer PIM-Anreicherung, nicht standardmäßigen Specifications, Seller Offers, Custom Pricing Logic oder quellspezifischem Bundle-Verhalten abhängt. Ein größeres Projekt kann dagegen ohne Custom Service auskommen, wenn die Datensätze unterstützt sind und operative Funktionsweisen über Zielimplementierung abgedeckt werden.
| Auslöser für Custom Service | Warum er den Ansatz verändert |
|---|---|
| Master-Data-Entitäten müssen migriert werden | Custom Entities können sich anders verhalten als gewöhnliche Customer-, Product- oder Order-Felder. |
| Externe Identifikatoren müssen nutzbar bleiben | Kontinuität zu ERP, PIM, WMS, OMS, CRM, Marketplace oder Accounting kann von exakter Erhaltung abhängen. |
| Marketplace- oder Seller-Kontext muss rekonstruiert werden | Seller-, Offer-, Provisions-, Fulfilment- oder Received-SKU-Bedeutung kann individuelle Interpretation benötigen. |
| Product-/SKU-Logik benötigt Transformation | Bundles, Kits, Assemblies, Personalisierung, Attachments oder Service-Logik können sich nicht sauber abbilden lassen. |
| Storefront-sensitive Daten müssen umgeformt werden | URLs, CMS Content, Search-/Facet-Verhalten, Routing oder Metadata können spezielle Behandlung benötigen. |
| Quellplattform ist individuell oder stark modifiziert | Die Quellstruktur selbst kann individuelle Extraktion und Interpretation erfordern. |
Custom Service sollte anhand konkreter Beispiele abgegrenzt werden. Der Händler sollte repräsentative Datensätze, erwartete Ergebnisse und den geschäftlichen Grund für den Erhalt des benutzerdefinierten Werts bereitstellen. Ohne Beispiele wird die Planung abstrakt und schwer validierbar.
Demo Migration als Nachweis-Gate für den Servicepfad
Demo Migration sollte vor Full Migration prüfen, ob der gewählte Ansatz ausreicht. Für VTEX muss die Stichprobe jene Datenbeziehungen herausfordern, die den Launch am stärksten beeinflussen: Products und SKUs, Specifications, Preise, Promotions, Customers, Orders, Marketplace-Kontext, Master Data, Integrationen und Storefront-sensitive Datensätze.
| Demo-Migration-Sample | Was damit entschieden werden soll |
|---|---|
| Einfaches Product und SKU | Ob die grundlegende Catalog-Migration sauber funktioniert. |
| Multi-SKU Product | Ob Quellvarianten zu nutzbaren VTEX SKUs werden. |
| Product mit vielen Specifications | Ob Discovery-, Search-, Filter- und Merchandising-Werte strukturiert bleiben. |
| Beispiel einer kommerziellen Regel | Ob Preis-, Promotion- oder Kanalkontext korrekt migriert, konfiguriert oder ausgeschlossen wird. |
| Customer mit geschäftlichem Kontext | Ob Customer- und Account-Bedeutung nutzbar bleibt. |
| Operative Order | Ob historischer Order-Kontext für Service und Finance lesbar bleibt. |
| Master-Data- oder integrationsgeführter Wert | Ob die Anforderung unterstützt, ausgeschlossen oder als Custom Scope behandelt werden muss. |
| Storefront-sensitiver Datensatz | Ob Content-, URL-, Search- und SEO-Annahmen separate Implementierung oder Custom Handling benötigen. |
Wenn repräsentative Datensätze nach Demo Migration ihre nutzbare Bedeutung behalten, kann der gewählte Ansatz passend sein. Zeigt die Stichprobe wiederkehrende strukturelle Lücken, fehlende externe Referenzen, Marketplace-Mehrdeutigkeit, Verlust von Custom Fields oder Storefront-sensitive Abweichungen, sollte der Ansatz vor Full Migration angepasst werden.
Entity Points und VTEX-Umfangsplanung
Entity Points unterstützen die Umfangsplanung, ersetzen aber keine Komplexitätsprüfung. Product-, Customer-, Order- und Blog-Post-Datensätze können Entity Points verbrauchen, wenn sie erstmals migriert werden. Neue geeignete Datensätze können ebenfalls Entity Points verbrauchen, wenn spätere Migrationsaktivität sie erstmals in den Umfang aufnimmt.
Datensätze, die innerhalb der gekauften Migration bereits gezählt wurden, verbrauchen nicht erneut Entity Points, nur weil der Händler die Migration fortsetzt oder auf demselben Migrationspfad eine weitere Migrationsaktion ausführt. Für VTEX-Projekte ist das besonders wichtig, wenn während des Launch-Fensters nach dem ersten Migrationslauf neue Products, Customers, Orders oder Blog Posts entstehen.
Entity Points messen VTEX-Komplexität nicht allein. Eine Migration mit überschaubarem Datensatzvolumen kann Custom Service benötigen, wenn Master Data, externe Identifikatoren, Seller-Kontext oder besondere Product-/SKU-Transformation relevant sind. Eine größere Migration kann zu Standard Service oder Managed Service passen, wenn die Datensätze unterstützt und gut prüfbar sind.
Optionen für spätere Migrationen für VTEX
Bei VTEX kann während der Zielvorbereitung weitere Migrationsaktivität nötig sein, weil Catalog-, Seller-, Offer-, Master-Data-, Order- und Integrationsarbeit weiterläuft. Die gewählte Aktion richtet sich danach, ob die akzeptierte Konfiguration weiterhin gültig ist, unterstützte Migrationsregeln geändert werden müssen oder das Zielergebnis eine neue Basis benötigt.
| Additional Migration Option | Wann sie für VTEX passt | Was erneut validiert werden muss |
|---|---|---|
| Continue the Migration with the Last Used Configuration | Die akzeptierten Filter, Mappings und unterstützte Datenkonfiguration bleiben korrekt; hauptsächlich sollen neue geeignete Datensätze oder spätere Quelländerungen verarbeitet werden. | Neue Products und SKUs, geänderte Specifications, Customers, Orders, Blog Posts, URLs sowie ein Regression Sample früher migrierter Datensätze. |
| Continue the Migration with a New Configuration | Demo Migration oder Zielprüfung zeigt, dass Filtering, Mapping, Content Scope, Specification Handling, Seller Context oder unterstützte Datenkonfiguration geändert werden muss. | Jede betroffene Product-/SKU-Familie, Category-/Specification-Beziehung, Seller- oder Offer-Stichprobe, Customer- und Order-Datensatz, Content Item, URL und jedes durch die neue Konfiguration beeinflusste Field. |
| Perform a New Migration | Das bisherige Zielergebnis ist keine geeignete Arbeitsbasis mehr, die VTEX-Umgebung wurde zurückgesetzt oder Umfang und Annahmen haben sich wesentlich verändert. | Gesamter akzeptierter Umfang, Ersetzungsverhalten, Sauberkeit der Zielumgebung, Catalog-Aktivierungsanforderungen, Seller-Kontext, historische Datensätze, URLs und integrationssensitive Outputs. |
Geeignete Datensätze, die auf demselben Migrationspfad bereits gezählt wurden, werden nicht erneut gezählt. Tatsächlich neue geeignete Products, Customers, Orders oder Blog Posts können dagegen beim ersten Migrieren Kapazität verbrauchen. Seller-, Trade-Policy-, Logistics-, Master-Data- und Marketplace-Komplexität muss separat beurteilt werden.
Die erneute Validierung muss zur gewählten Aktion passen. Eine Fortsetzung mit derselben Konfiguration konzentriert sich auf neue Datensätze plus Regression Samples. Eine Fortsetzung mit neuer Konfiguration muss zeigen, dass die geänderte Regel das beabsichtigte Ergebnis verbessert, ohne unbeeinflusste Datensätze zu beschädigen. Eine neue Migration benötigt breitere Nachweise, weil das Zielergebnis neu aufgebaut wird. VTEX-seitiges Pricing, Logistics, Checkout, Seller Onboarding, Storefront Implementation, Apps und Integrationen bleiben getrennte Verantwortungsbereiche, sofern sie nicht ausdrücklich im vereinbarten Umfang enthalten sind.
Entscheidungsmatrix für den VTEX-Servicepfad
VTEX-Projekte verbinden häufig gewöhnliche Commerce-Datensätze mit Enterprise-Strukturen, die an anderer Stelle konfiguriert oder geführt werden. Die Entscheidung sollte pro Anforderung getroffen werden und nicht durch ein einziges Label für das ganze Projekt.
| VTEX-Anforderung | Standard Service | Managed Service | Add-ons | Custom Service |
|---|---|---|---|---|
| Saubere Products, SKUs, Categories, Brands, Customers und Orders | Geeignet, wenn unterstützt und kundengeführte Prüfung realistisch ist | Nützlich bei hohem Koordinationsaufwand für Ausführung und Freigabe | Nur für begrenztes Filtering, Mapping oder unterstützte Konfiguration | Normalerweise nicht erforderlich |
| Category-gebundene Specifications und Product-/SKU-Bedeutung | Geeignet, wenn Quellbeziehungen explizit und kompatibel sind | Nützlich, wenn mehrere Catalog Owner Samples freigeben müssen | Kann unterstützte Field-Ziele oder Umfang präzisieren | Erforderlich, wenn spezielle Transformation oder nicht unterstützte Strukturen das Ergebnis bestimmen |
| Marketplace Sellers, Offers oder externer Seller-Kontext | Nur geeignet, wenn ausgeschlossen oder im vereinbarten Pfad vollständig unterstützt | Hilft bei Koordination, erzeugt aber keine nicht unterstützte Seller-Logik | Kein Ersatz für Marketplace-Rekonstruktion | Passend, wenn Seller-, Offer-, Provisions- oder Ownership-Kontext individuelle Behandlung benötigt |
| Master Data oder app-eigene Entitäten | Üblicherweise außerhalb des Standardumfangs, sofern nicht ausdrücklich unterstützt | Verändert keine Fähigkeitsgrenzen | Nicht ausreichend für nicht unterstützte Datentypen | Passend, wenn Entitäten und Beziehungen individuelle Prüfung benötigen |
| ERP-, PIM-, OMS-, WMS-, CRM- oder Marketplace-Identifikatoren | Geeignet, wenn unterstützte Fields ausreichen und nur als Referenz dienen | Nützlich, wenn mehrere System Owner validieren müssen | Kann unterstützte Identifikatoren mappen | Erforderlich, wenn Identifikatoren Custom Workflows steuern oder besondere Transformation benötigen |
| Storefront, Checkout, Pricing, Promotions, Logistics und Search | Zielimplementierung statt gewöhnlicher Datensatzmigration | Koordination kann Verantwortungsgrenzen klären | Auf unterstützten Migration Output begrenzt | Custom Service implementiert die VTEX-Umgebung nicht automatisch, sofern dies nicht vereinbart ist |
Diese Matrix verhindert zwei gegensätzliche Fehler: jede Enterprise-Funktion automatisch zu Custom Service hochzustufen oder Enterprise-Strukturen allein deshalb als kompatibel anzusehen, weil die zugrunde liegenden Product- und Order-Datensätze unterstützt werden. Der richtige Pfad schützt das erwartete Geschäftsergebnis und hält die VTEX-Implementierungsverantwortung sichtbar.
Signale dafür, dass der gewählte Ansatz zu leicht ist
Ein VTEX-Migrationsansatz ist zu leicht, wenn er Enterprise-Struktur wie gewöhnliche Datensatzübertragung behandelt. Warnsignale erscheinen oft erst bei der Sample-Prüfung und nicht in der ersten Umfangsschätzung.
| Warnsignal | Wahrscheinliche Reaktion |
|---|---|
| Product-/SKU-Beziehungen sind unklar. | Catalog Scope stärken oder Custom Service prüfen. |
| Für Search oder Filters benötigte Specifications fehlen oder wurden abgeflacht. | Advanced Data Mapping prüfen, wenn unterstützte Quellfelder ein anderes VTEX-Ziel benötigen; Custom Service nutzen, wenn die Quellbedeutung individuelle Interpretation verlangt. |
| Pricing-, Promotion- oder Kanalwerte erhalten die geschäftliche Bedeutung nicht. | Migrierte Daten von VTEX-Konfiguration und Custom Logic trennen. |
| Marketplace- oder Seller-Kontext wird erwartet, ist aber nicht dargestellt. | Marketplace Scope, Zieleinrichtung oder Custom Service prüfen. |
| Master Data oder externe IDs sind geschäftskritisch. | Custom Service prüfen, sofern kein eindeutig unterstützter Mapping-Pfad vorhanden ist. |
| Storefront-sensitive Daten werden nur anhand der Product-Anzahl freigegeben. | URL-, Content-, Search-, Navigation- und SEO-Validierung ergänzen. |
| Der Händler kann keine Review Owner benennen. | Managed Service kann bei der Ausführung helfen; Umfang und Abnahmekriterien müssen trotzdem definiert sein. |
Diese Signale sollten vor Full Migration geklärt werden. Ein zu schwacher Ansatz verwandelt Vorbereitungslücken gewöhnlich in Launch-Defekte.
Fazit
Der richtige VTEX-Migrationsansatz ist der leichteste Servicepfad, der das angestrebte Betriebsergebnis zuverlässig schützt. Standard Service kann zu unterstützten, gut prüfbaren Datensätzen passen. Managed Service ist sinnvoll, wenn Ausführungs- und Koordinationsaufwand hoch sind. Add-ons unterstützen klar begrenztes Filtering von Datensätzen, Transformation von Feldwerten und Field Remapping innerhalb unterstützter Fähigkeiten. Custom Service ist erforderlich, wenn benutzerdefinierte Daten, nicht unterstützte Datensätze, externe Identifikatoren, Master Data, Marketplace-Interpretation, spezielle Transformation, Behandlung einer individuellen Plattform oder Anpassung der Migrationslogik benötigt werden.
Demo Migration sollte vor Full Migration bestätigen, dass der Ansatz belastbar genug ist. Zeigen repräsentative Samples strukturelle Lücken, unklare Ownership, Abhängigkeit von externen Systemen, Marketplace-Mehrdeutigkeit oder Verlust Storefront-sensitiver Bedeutung, sollte der Servicepfad vor der vollständigen VTEX-Migration angepasst werden.
Häufige Fragen
Reicht Standard Service für eine VTEX-Migration aus?
Standard Service kann ausreichen, wenn unterstützte Datensätze sauber sind, Products und SKUs vorhersehbar aufgebaut sind, Customer- und Order-Daten Standardstrukturen folgen und der Händler das Ergebnis verantwortungsvoll validieren kann. Marketplace, Master Data, externe Identifikatoren oder spezielle Logik sollten geprüft werden, bevor Standard Service als ausreichend gilt.
Wann sollte für VTEX Managed Service gewählt werden?
Managed Service ist sinnvoll, wenn die Daten innerhalb der unterstützten Fähigkeiten bleiben, der Händler aber Next-Cart-geführte Ausführung, stärkere Koordination, disziplinierte Sample-Prüfung oder Unterstützung bei der Abstimmung mit dem Launch benötigt.
Wie unterscheiden sich Add-ons und Custom Service bei VTEX?
Add-ons behandeln unterstützte Anforderungen an Record Filtering, Transformation von Feldwerten oder Field Remapping. Custom Service deckt nicht unterstützte Datensätze, app-eigene Werte, Master-Data-Entitäten, externe Identifikatoren, spezielle Transformation, Behandlung einer individuellen Plattform oder Anpassungen der Migrationslogik ab.
Was sollte Demo Migration beweisen, bevor der VTEX-Ansatz freigegeben wird?
Demo Migration sollte zeigen, dass repräsentative Products, SKUs, Specifications, Preise, Customers, Orders, Marketplace-Werte, Master-Data-Beispiele, Integrationsreferenzen und Storefront-sensitive Datensätze mit nutzbarer Bedeutung im Ziel ankommen oder dem richtigen Behandlungsweg zugeordnet sind.
Wie ist der Startpreis von Custom Service zu verstehen?
Der angezeigte Betrag für Custom Service beginnt beim Preis von Standard Service für den gewählten Entity Points Plan. Er ist ein Ausgangswert und kein fester Endpreis. Der endgültige Gesamtpreis hängt von der vereinbarten Individualisierung, gegebenenfalls gekauften Add-ons, Expert Handle sofern enthalten und weiteren vereinbarten scope-spezifischen Kosten ab.