VTEX validation should prove that migrated records work across the platform domains that control commerce. A Product can exist while its SKU, specifications, trade-policy association, price, inventory, logistics, seller offer, or storefront index prevents purchase. A Customer or Master Data document can exist while the relationship, key, or consuming workflow is wrong. An Order can exist while its seller, line, payment, or fulfillment context cannot be reconciled.
Evidence should follow actual VTEX relationships: Category and Brand to Product, Product to SKU and specifications, SKU to price and availability, trade policy to catalog and commercial conditions, seller to offer and marketplace Order, Customer to Master Data or B2B records, and Order to OMS and logistics evidence.
Use Pass, Watch, and Block Across VTEX Domains
- Pass: representative and exception evidence proves the intended VTEX behavior.
- Watch: the result is usable, but a documented nonblocking correction, target configuration task, owner decision, or accepted difference remains.
- Block: the issue materially affects selling, pricing, seller ownership, inventory, logistics, Customers, historical Orders, content, SEO, integration continuity, compliance, or agreed migration scope.
| Evidence domain | VTEX proof | Typical Block condition |
|---|---|---|
| Catalog | Categories, Brands, Products, SKUs, specifications, images, and activation support buying. | A priority SKU cannot be selected or purchased correctly. |
| Commercial context | Trade policies, prices, promotions, and assortment produce the intended channel outcome. | A material channel receives the wrong Product or price. |
| Marketplace | Seller identity, offers, catalog mappings, and Order ownership remain coherent. | A seller’s Product or Order is attributed incorrectly. |
| Logistics | Inventory, warehouses, docks, shipping policies, and delivery context support availability. | Valid stock is unavailable or unavailable stock is sold. |
| Customers and Orders | Profiles, B2B records, Master Data, lines, totals, statuses, and references remain understandable. | A material historical Order or account relationship cannot be reconciled. |
| Custom scope | Apps, integrations, approved migration outputs, non-standard migration deliverables, and external IDs work through their owner. | A launch-critical workflow loses data or a stable key. |
The final report should name the account, trade policy, seller, SKU, warehouse, shipping policy, Master Data entity, and integration context reviewed. A general Catalog Pass should not conceal a blocked seller or sales channel.
VTEX decisions should preserve domain ownership. Catalog, Pricing, Promotions, Logistics, OMS, Marketplace, Master Data, Search, and storefront teams can reach different results for the same Product or Order, so the launch report should not compress them into one undifferentiated status.
Use Representative Testing to Prove Catalog and Channel Assumptions
Representative testing should include records that expose VTEX architecture:
- Products with several SKUs and variation-defining specifications;
- Categories with inherited Product and SKU specification groups;
- SKUs with images, identifiers, prices, inventory, and activation dependencies;
- Products available under different trade policies;
- marketplace Products, sellers, offers, and catalog mappings;
- Customers, B2B records, and Master Data documents with stable keys;
- Orders from direct and marketplace contexts;
- warehouses, docks, shipping policies, and delivery exceptions;
- priority storefront content, URLs, and search-sensitive Products;
- app-owned records and external identifiers.
Representative evidence should reveal whether source variants became VTEX SKUs, whether Product and SKU specifications retain the right meaning, and whether trade-policy and seller relationships point to the intended records. A repeatable structural error is a Block before broader migration execution.
The sample should include inactive, out-of-stock, incomplete, or exception records. Clean active SKUs alone cannot prove the activation and availability boundaries that often cause VTEX launch problems.
Validate Categories, Brands, Products, SKUs, and Specifications
VTEX Catalog uses Categories and Brands to organize Products, while SKUs represent the physical variations buyers purchase. Category-linked specification groups define Product and SKU fields.
| Catalog evidence | Pass | Watch | Block |
|---|---|---|---|
| Product–SKU relationship | Every intended SKU remains attached to the correct Product. | Minor display ordering remains. | SKUs are missing, duplicated, or attached to the wrong Product. |
| Specifications | Product and SKU values use the intended field, type, and vocabulary. | Low-value cleanup remains. | Variation selection, filtering, integration, or compliance meaning is wrong. |
| Images | Required SKU images display and support accurate selection. | Secondary ordering remains. | A priority SKU cannot be activated or identified correctly. |
| Brand and Category | Product assignment supports discovery and intended classification. | Merchandising refinement remains. | Priority Products are inaccessible or misclassified. |
| Identifiers | Product, SKU, reference, EAN, or external keys identify the correct unit. | Noncritical duplicate cleanup remains. | Pricing, inventory, seller, or integration data resolves to the wrong SKU. |
| Activation | Product and SKU meet the intended availability prerequisites. | Controlled publication work remains. | A priority SKU cannot be offered in the intended channel. |
Validate through the Admin, storefront or search result, Product detail, cart, Order line, and external systems. A Catalog record should not pass merely because its Product and SKU IDs exist.
Specification evidence should distinguish descriptive Product properties from SKU-selection values. A value can look correct in the Admin yet fail if it belongs to the wrong field, field group, Category inheritance path, or SKU.
Include SKUs whose activation depends on complete images, specifications, and commercial data. This exposes Catalog records that exist technically but cannot participate correctly in Product selection or storefront availability.
Validate Trade Policies, Prices, Promotions, and Assortment
Trade policies can connect catalog availability, prices, promotions, inventory, logistics, payment, and different sales channels. Validate in the actual sales-channel context.
| Commercial evidence | Required proof |
|---|---|
| Trade-policy association | The intended Products and SKUs are available only in the correct channel context. |
| Price | The exact SKU, seller, trade policy, quantity, and currency produce the intended price. |
| Promotion | Conditions and exclusions produce the expected commercial result. |
| Assortment restriction | Products excluded from a channel remain unavailable there. |
| Inventory context | Availability follows the warehouse and logistics relationships used by the trade policy. |
| Payment or checkout context | Current target configuration exposes the intended methods separately from historical Order evidence. |
A numeric price in the Pricing module is not sufficient evidence. Test the buyer-facing result with the intended seller, trade policy, and quantity. Use Block for material pricing or assortment errors; use Watchfor documented noncritical configuration or presentation work.
Historical discounts on Orders remain transaction snapshots. They do not prove that current Promotions or trade-policy conditions are configured correctly.
When several trade policies share part of the same catalog, compare both included and excluded SKUs. Positive evidence proves availability; negative evidence proves that restricted assortment and commercial conditions do not leak into another channel.
Validate Sellers, Offers, Marketplace Mappings, and Order Ownership
VTEX marketplace operations separate canonical Catalog identity from seller-specific offers. A seller can provide price, inventory, fulfillment, and commercial ownership for an item represented in the marketplace Catalog.
Review:
- seller identity and status;
- seller SKU or offer mapping to the intended Product and SKU;
- trade-policy and assortment context;
- seller price and inventory;
- fulfillment responsibility;
- marketplace Category or Product mapping keys;
- Order origin, seller attribution, commission or settlement references where included;
- external marketplace and connector identifiers.
Use Block when an offer points to the wrong SKU, a seller loses ownership, a marketplace Order is attributed incorrectly, or settlement and fulfillment cannot identify the responsible seller. Use Watch for controlled connector configuration when the migrated Catalog relationship and identifiers are complete.
Marketplace evidence should not be averaged with direct-store evidence. A Product can pass the first-party storefront and block a marketplace because its seller offer, trade policy, inventory, or mapping is wrong.
Validate Inventory, Warehouses, Docks, Shipping Policies, and OMS Context
VTEX logistics can connect inventory to warehouses, loading docks, shipping policies, carriers, trade policies, and delivery options. Validate the relationships that determine availability and promise.
| Logistics evidence | Validation focus |
|---|---|
| Inventory | Quantity belongs to the correct SKU and warehouse. |
| Warehouse | The warehouse has the intended stock and dock relationship. |
| Loading dock | The dock connects the intended warehouses, carriers, and trade policies. |
| Shipping policy | Rules, rates, service levels, and active state support the intended destination context. |
| SKU availability | The buyer sees the expected availability and delivery option for the trade policy and seller. |
| Order fulfillment | Historical Orders retain seller, delivery, status, and external references. |
| External authority | ERP, WMS, or carrier systems identify the correct SKU, warehouse, and Order. |
A correct inventory total can still fail when stock is assigned to the wrong warehouse or disconnected from the relevant dock and shipping policy. Mark priority availability failures as Block.
Migrated Orders do not configure live logistics. Current warehouses, docks, shipping policies, carriers, pickup points, SLA behavior, and OMS operations require separate target approval.
Test at least one delivery destination and SKU combination for each material logistics path. This reveals broken warehouse–dock–shipping-policy relationships that inventory totals and Admin status alone cannot show.
Validate Customers, B2B Relationships, Master Data, and Historical Orders
Customer-related data may span profile identity, addresses, B2B organizations, roles, cost centers, consent, CRM IDs, and Master Data documents. Validate the entity and key, not only displayed fields.
| Customer evidence | Required proof |
|---|---|
| Profile identity | Email, document, phone, or external key identifies the intended person. |
| Address | Current profile address and historical Order address remain distinct where appropriate. |
| B2B entity | Organization, user, role, cost center, catalog, or approval relationship remains attached correctly. |
| Master Data document | Entity, document ID, schema, fields, relationships, and consumer are correct. |
| External identifier | CRM, ERP, loyalty, marketplace, or support systems can locate the same Customer or organization. |
| Historical Order | Customer, seller, SKU lines, prices, promotions, payments, shipping, statuses, and external IDs remain understandable. |
Use Block when identity merging is unsafe, a B2B relationship is broken, a Master Data reference points to the wrong entity, or a material Order cannot be reconciled.
Historical Orders do not prove current Checkout, Payments, Promotions, Logistics, OMS, notifications, invoices, refunds, or Customer-segmentation workflows. These require separate operational approval.
Master Data evidence should include relationship fields and referenced documents, not only the document body. A correct profile value can still fail when an organization, cost center, app, or workflow points to a stale identifier.
Validate Storefront, Search, URLs, and Content Continuity
VTEX storefront evidence can include search indexing, Product availability, Categories, Brands, filters, content pages, navigation, SEO routes, and app-managed presentation. Validate from the buyer path rather than from Catalog presence alone.
Representative evidence should include:
- priority Product and SKU searches;
- Category and Brand discovery;
- filters driven by specifications;
- Product-detail selection and availability;
- priority source URLs and intended destinations;
- metadata, media, and internal links;
- policy, service, and campaign content;
- locale or domain differences where used;
- headless or app-managed content references.
Use Block for widespread priority indexing failure, broken SKU selection, missing required content, or high-value URL loss. Use Watch for controlled presentation, indexing, or metadata work when the underlying records and owner are complete.
Catalog, Search, and storefront implementation are related but distinct. A Product can exist in Catalog and still be absent from search or unavailable in the intended trade policy.
Validate Apps, Integrations, Supported Adjustments, and Tailored Migration handling Outputs
VTEX Stores often connect Catalog, Pricing, Logistics, OMS, Master Data, sellers, search, storefront apps, ERP/PIM/WMS, CRM, marketplaces, tax, payment, and analytics systems. Validate custom data through its actual domain and consumer.
For each critical value, document:
- VTEX domain and owning entity;
- app or external system;
- Product, SKU, seller, Customer, Master Data, or Order identifier;
- expected direction of synchronization;
- representative successful and exception evidence;
- owner of remaining deployment or configuration.
Validate agreed supported and tailored outputs against documented scope. A transformed specification, seller mapping, Master Data document, external ID, or custom relationship should be tested through the API, app, Admin module, storefront, or external system that consumes it.
Use Block when the value is orphaned, incompatible, or untraceable in a launch-critical workflow. Use Watch when remaining app or integration deployment sits outside migration scope and the VTEX domain, data contract, stable key, and responsible owner are complete.
Distinguish Representative Testing From Broader Migration Execution Evidence
Representative testing proves selected structural assumptions. Broader migration execution must prove full Catalog, channel, seller, logistics, Customer, Order, content, and integration scope.
Broader migration evidence should include:
- every major Product and SKU pattern;
- complete specification fields and values;
- trade-policy assortment and pricing coverage;
- all seller offers and marketplace mappings in scope;
- inventory, warehouses, docks, and relevant logistics references;
- Customers, B2B records, Master Data documents, and historical Orders;
- storefront, search, priority URLs, and content;
- all supported and tailored outputs;
- app and external-ID exceptions;
- changes introduced after representative migration test.
Reopen a Representative test Pass when broader migration execution reveals inconsistent SKU specifications, missing images, activation gaps, wrong trade-policy associations, seller mapping failures, warehouse mismatches, orphaned Master Data documents, duplicate Customers, or unreconciled Orders.
Segment exceptions by trade policy, seller, Category, Product family, specification group, warehouse, Customer/B2B entity, and source period. Aggregate counts can hide a complete failure in one channel or seller.
Revalidate After Later Migration Actions
| Later action | VTEX revalidation scope |
|---|---|
| continue under the accepted configuration | Validate newly eligible records and confirm that prior Catalog, trade-policy, seller, logistics, Customer, Order, content, and integration assumptions remain valid. |
| continue under revised configuration | Revalidate every relationship affected by changed filters, mappings, data type selection, or configuration, including prior approvals. |
| produce a distinct new migration result | Treat the output as a distinct migrated result and repeat the full VTEX validation and launch decision. |
Preserve prior and new decisions together. If Product or SKU identity, trade-policy assignment, seller mapping, or Customer matching changes, previously approved Orders, logistics references, and integrations may also require review.
VTEX revalidation should follow domain references. A changed SKU mapping can affect price, inventory, seller offers, logistics, Search, and Order evidence; a changed Customer key can affect Master Data, B2B, and historical Order associations.
Build the VTEX Launch Decision
Launch approval requires:
- no unresolved Block affecting Catalog, pricing, sellers, inventory, logistics, Customers, historical Orders, storefront discovery, SEO, compliance, or integrations;
- completed representative migration test and broader migration evidence;
- proof of agreed supported and tailored outputs;
- separate approval for live VTEX Pricing, Promotions, Checkout, Payments, Logistics, OMS, seller operations, Search, and app deployment;
- revalidation after applicable later migration actions;
- named owners and closure dates for Watch items.
Keep separate statuses for Catalog readiness, channel/pricing readiness, marketplace readiness, logistics readiness, historical-data readiness, storefront/search readiness, and integration readiness. A passing direct storefront should not conceal a blocked seller or logistics relationship.
Conclusion
VTEX validation should prove that Catalog, SKUs, specifications, trade policies, sellers, logistics, Customers, Master Data, Orders, content, and integrations work together in the intended sales-channel context.
Representative testing establishes structural confidence, broader migration execution proves completeness and exceptions, and later migration actions require focused or complete revalidation. Launch approval should follow documented Pass, Watch, and Block evidence.
Common Questions
Why must VTEX Products and SKUs be validated separately?
Products hold generic catalog identity, while SKUs represent the physical or selectable units buyers purchase. Specifications, images, prices, inventory, and seller offers can depend on the SKU.
How should trade-policy evidence be tested?
Use the intended sales channel, seller, SKU, quantity, currency, price, promotion, inventory, logistics, and payment context together rather than checking one Admin record.
Can a direct-store Pass approve marketplace readiness?
No. Seller identity, offers, mappings, trade policies, inventory, fulfillment responsibility, and marketplace Order ownership require separate evidence.
Do migrated Orders prove live VTEX Logistics and OMS are ready?
No. Historical Orders prove transaction readability. Current warehouses, docks, shipping policies, carriers, Payments, OMS, and fulfillment require separate target approval.
How should Master Data records be approved?
Confirm the entity, document ID, schema, field values, relationships, external keys, and application or workflow that consumes the document.
What requires revalidation after a later VTEX migration action?
Revalidate every new or changed VTEX record and every trade-policy, seller, offer, logistics, Master Data, storefront, or integration assumption affected by the action. produce a distinct new migration resultrequires a separate full evidence baseline.