After a representative migration test or a broader run into VTEX, validation must connect the agreed data result with the buying and operational outcomes the destination needs. Approve evidence in the actual account, relevant workspace, trade policy, seller, warehouse and consuming-application context, because a correct record in one context can remain unusable in another.
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.
Identify which Catalog, commercial, Logistics, Customer, Master Data, Order and content outputs are in the accepted scope. Native domain capability and API access do not establish delivered coverage. Keep agreed migrated data, separate implementation and current operational setup attached to their owners and 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. |
| Project-specific scope | Apps, integrations, documented migrated outputs, separately implemented 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 Watch for 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.
Record the account, channel or trade-policy identifier, seller and buyer context used for each test. A search result or cart in a default channel cannot approve another channel’s price or assortment. Include an excluded SKU and an unauthorized buyer where restrictions apply, and reopen any dependent offer, warehouse or integration evidence when the identity or policy changes.
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 nonblocking connector configuration when the migrated Catalog relationship and identifiers are complete; a required marketplace workflow that cannot operate remains Block for launch.
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 | Version, entity, document ID, applicable schema or field contract, field values, 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.
Record the Master Data version and exact entity used by the consumer. Version 1 commonly identifies Customer and address entities as CL and AD; version 2 uses named entities and API-managed schemas or indexes where configured. Confirm the applicable contract rather than require a v2 JSON schema for every v1 record. Test both direct document retrieval and the query or relationship actually used by the consuming app.
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 Separately Implemented 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 documented migrated and separately implemented 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 only for nonblocking remaining app or integration work when the VTEX domain, data contract, stable key and responsible owner are complete. Deployment outside migration scope still requires Block for launch if the required day-one workflow cannot operate.
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 migrated and separately implemented 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 migration situation | VTEX revalidation scope |
|---|---|
| Later activity using the same configuration | Validate newly eligible records and confirm that prior Catalog, trade-policy, seller, logistics, Customer, Order, content, and integration assumptions remain valid. |
| Later activity after configuration changes | Revalidate every relationship affected by changed filters, mappings, data type selection, or configuration, including prior approvals. |
| A distinct fresh 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.
Name the records and rules the later run actually touches, including earlier records that may be updated or processed again. Continuing with an unchanged configuration does not establish a newly-added-only source window. Compare the combined earlier and later VTEX result, preserve accepted target-side changes where required, and reopen SKU prices and stock, seller offers, trade-policy restrictions, Master Data references, Search and historical Order consumers that depend on a changed record. Do not inherit a prior Pass merely because the run completed.
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 documented migrated and separately implemented 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 version, entity, document ID, applicable schema or field contract, values, relationships, external keys and consuming application. Test the actual query or referenced-document path as well as direct retrieval. A correctly stored document cannot pass if the required organization, address, cost center or workflow still resolves to a stale or missing record.
What requires revalidation after a later VTEX migration action?
Revalidate new or changed records and earlier records touched again, together with affected trade policies, sellers, offers, Logistics, Master Data, storefront and integration relationships. Compare the combined result and accepted target-side changes. Unchanged configuration does not establish a newly-added-only window. A distinct fresh migration result requires its own full evidence baseline.
Can direct retrieval approve a VTEX Master Data document that an app cannot find?
No. Direct retrieval by ID and an indexed field query prove different access paths. Confirm the app’s version, entity, field and index context, then test its real query. Documents created before an index was configured may need an owner-managed update before they appear through that index. Missing required query or relationship evidence is Block for the affected workflow.