VTEX is a cloud commerce platform designed around enterprise operations, extensibility, multiple business models, and connected commerce services. Its architecture spans Catalog, Pricing, Promotions, Checkout, Orders, Logistics, Payments, Search, Master Data, marketplace capabilities, B2B functions, storefront development, and application infrastructure. A VTEX implementation may operate as a direct-to-consumer store, a multi-brand environment, a marketplace, a seller connected to external marketplaces, a B2B channel, or a combination of these models.
That breadth makes VTEX materially different from platforms where commerce is concentrated in one catalog database and one storefront. Product availability may depend on SKU activation, inventory, price, trade policy, seller relationship, logistics, and storefront configuration. A Product can exist in the Catalog but remain unavailable because one of those connected layers is incomplete. A marketplace offer can appear under a Product while being owned by another seller. A headless storefront can present VTEX commerce data without sharing the same implementation layer as the administration environment.
Migration into VTEX is therefore not only a transfer of Products, Customers, and Orders. It is a reconstruction of commercial relationships across modular services. The target account must express which items exist, which SKUs are sellable, who supplies them, where inventory is held, which prices apply, which channels can sell them, how checkout resolves fulfilment, and which storefront or application consumes the resulting data.
VTEX as a Cloud Commerce Architecture
VTEX provides a managed cloud platform rather than a self-hosted application package. Core services, platform infrastructure, and commerce APIs operate within the VTEX environment, while merchants and implementation partners configure business rules, integrate external systems, build storefronts, and extend capabilities through supported application and API models.
The platform is intentionally modular. Catalog records do not independently determine the customer experience. Pricing, promotions, inventory, logistics, sellers, trade policies, checkout, search, and storefront rendering contribute separate parts of the final result. This modularity supports enterprise scale and multiple operating models, but it also creates a higher dependency on accurate relationships among services.
| VTEX layer | Primary purpose | Migration significance |
|---|---|---|
| Catalog | Categories, brands, Products, SKUs, specifications, images, attachments, services, kits, and collections | Source catalog concepts must be translated into VTEX’s Product-SKU hierarchy and category-linked specification model. |
| Pricing and Promotions | Commercial values and promotional rules | A Product record does not determine all sell prices or promotional outcomes. |
| Logistics | Inventory, docks, warehouses, shipping policies, and fulfilment | SKU availability depends on operational configuration outside the Product record. |
| Sellers and Marketplace | Offer ownership and marketplace relationships | The merchant may own the Catalog while another seller owns price, inventory, and fulfilment. |
| Checkout and Orders | Transaction orchestration and historical order management | Live purchase behavior depends on current configuration and integrations, not only migrated Order history. |
| Storefront and applications | Customer-facing experience and extensions | Commerce data can be presented through different storefront architectures and custom applications. |
VTEX’s platform overview documentation emphasizes cloud infrastructure, security, data privacy, composability, extensibility, store architecture, and developer experience. These concerns are not peripheral. They define how the target environment is governed and which teams own the different layers of a migration project.
Catalog Architecture: Categories, Products, and SKUs
The VTEX Catalog begins with Categories and brands, then defines Products and SKUs. A Product is the general commercial definition of an item, while an SKU is the specific purchasable variation that carries stock and is selected by the buyer. Each Product belongs to a Category and a brand, and every Product must have at least one SKU.
Specifications are also structurally significant. VTEX associates specification groups with Categories, and those groups can be inherited by lower Category levels. Product specifications describe Product-level characteristics, while SKU specifications distinguish purchasable variations. This means source attributes cannot be mapped safely without determining whether they classify the Product, define an SKU, support filtering, or serve only as descriptive content.
| Source concept | Possible VTEX destination | Key interpretation question |
|---|---|---|
| Parent Product | Product | Does the source parent represent one general item or only a grouping container? |
| Variant | SKU | Does each source variant correspond to a separately purchasable and stocked unit? |
| Attribute | Product or SKU specification | Does the value describe the overall Product or distinguish a purchasable SKU? |
| Option or personalization | Attachment, assembly option, service, or SKU structure | Does the selection change inventory identity, price, quantity, or buyer-provided information? |
| Bundle | Kit or assembly-related structure | Are components fixed, optional, inventory-managed, or priced separately? |
| Collection | Collection or storefront merchandising structure | Is the grouping taxonomic, promotional, seasonal, or presentation-only? |
VTEX requires more than creating Product and SKU records. Categories, brands, specification groups, specifications, images, SKU activation, price, inventory, and sales-channel availability work together before an item becomes sellable. This requirement explains why a simple record-count comparison can overstate migration completeness. The meaningful unit is an active commercial relationship, not an isolated Product row.
Attachments, assembly options, services, and kits extend the Product model. Attachments can collect optional information associated with an SKU. Assembly options support more complex combinations, quantities, additional items, costs, and inventory relationships. Services can represent paid additions such as gift packaging or warranties. Kits group SKUs for sale together. Each structure has a different operational meaning and should not be flattened into one generic options field.
Trade Policies, Accounts, and Channel Context
VTEX uses trade policies to define commercial context across channels. A trade policy can influence Product availability and other selling conditions for a specific channel or operation. Enterprise accounts may also contain multiple stores, brands, countries, business units, or storefronts whose catalogs overlap but do not behave identically.
This channel-aware model is important during migration because source stores often encode market or channel differences in less explicit ways. A source platform may use separate websites, price lists, Customer groups, warehouses, subdomains, or custom fields to represent what VTEX expresses through trade policies and account configuration. The target design must determine whether those source distinctions should remain separate, be consolidated, or become channel-specific configuration.
A Product that is active in one trade policy may not be intended for another. Prices, logistics, sellers, promotions, and checkout behavior can also vary by commercial context. Migrating one global Product record without preserving those distinctions can produce overexposure, missing assortment, or incorrect commercial behavior.
Sellers, Marketplaces, and Offer Ownership
VTEX supports both marketplace and seller operating models. A VTEX account can act as a marketplace that receives offers from external sellers, or as a seller whose catalog and offers are distributed to external marketplaces. Catalog integration therefore may involve more than Product ownership.
In a marketplace context, the marketplace can own the shared Product presentation while sellers own offers, including price, inventory, fulfilment conditions, and seller-specific identifiers. Product and Category mappings may connect different catalog taxonomies across marketplace relationships. The same Product can have multiple seller offers, each with its own commercial availability.
| Marketplace element | Operational meaning | Migration significance |
|---|---|---|
| Product | Shared catalog identity and merchandising information | Duplicate source listings may need consolidation around one target Product identity. |
| SKU | Purchasable Product variation | Seller offers must point to the correct SKU rather than creating unrelated items. |
| Seller | Organization responsible for an offer | Seller identity, permissions, and operational ownership are not ordinary Customer data. |
| Offer | Seller-specific price, inventory, and fulfilment context | Offer records cannot be reduced to Product prices alone. |
| Mapping | Relationship between external and VTEX Categories or Products | Taxonomy and identifier translation must remain governed. |
| Order flow | Marketplace-seller transaction orchestration | Historical Orders and active marketplace routing are separate layers. |
This operating model distinguishes VTEX sharply from a single-merchant platform. A migration that ignores seller and offer relationships may preserve visible Products while losing the ownership structure that makes the marketplace function.
Pricing, Inventory, Logistics, and Sellability
VTEX separates core Catalog identity from the services that make an SKU commercially available. Prices are managed through pricing structures. Inventory is associated with logistics and fulfilment locations. Shipping policies, docks, warehouses, carriers, and delivery conditions influence whether checkout can resolve a viable fulfilment option. Promotions can alter commercial outcomes independently of base price.
The result is a layered definition of sellability. An SKU may exist and contain images and specifications but remain unavailable because it has no valid price, no inventory, no applicable trade policy, no seller offer, or no fulfilment route. Conversely, the same SKU may be sellable under different prices or logistics conditions across channels.
Source platforms often compress these layers into fewer fields. A Product table may contain both stock and price. A warehouse extension may hold location detail. A shipping module may calculate delivery independently. VTEX requires those concepts to be placed in the services that own them. Migration must therefore preserve the relationship between item identity and commercial execution.
Customers, Master Data, Checkout, and Orders
Customer identity in VTEX can involve account records, addresses, profiles, organizational information, consent, custom fields, and data stored through Master Data or connected customer systems. B2B implementations may add organizations, cost centers, roles, permissions, price contexts, and approval-related behavior. These structures are not equivalent to a flat list of registered users.
Checkout orchestrates the active purchase process across items, sellers, prices, inventory, logistics, payments, promotions, and Customer context. Orders record the result of completed transactions and support operational processing. Historical Orders can retain valuable Customer-service and reporting context, but they do not establish live checkout behavior in the target account.
The difference matters because a migration may correctly transfer Customer names, addresses, and Order totals while leaving organizational permissions, custom profile data, payment configuration, logistics, marketplace routing, or checkout integrations incomplete. VTEX’s modularity makes those boundaries explicit.
Storefront Models, VTEX IO, and Composability
VTEX supports different storefront and application approaches. VTEX IO provides a cloud-based development and application environment, while Store Framework and other storefront options can consume VTEX commerce services. Headless implementations may use custom frontends that interact with platform APIs and services.
A storefront is therefore not simply a theme attached to migrated Products. It is an implementation layer that determines navigation, Product presentation, search, content, account experience, analytics, and checkout integration. Source themes, templates, widgets, and scripts do not become VTEX storefront components automatically.
Composability and extensibility allow teams to add applications and integrations without modifying a self-hosted core codebase. That capability increases architectural flexibility but also distributes ownership among platform configuration, applications, external systems, and frontend code. A migration overview must recognize that storefront readiness and data readiness are related but distinct.
Integrations and Enterprise System Ownership
VTEX commonly operates alongside ERP, PIM, OMS, WMS, CRM, marketplace, tax, payment, search, and analytics systems. Official Catalog guidance explicitly describes back-office integration flows for creating and updating Catalog data. In many implementations, VTEX is not the sole system of record for Products, prices, inventory, Customers, or Orders.
This creates one of the platform’s defining migration questions: which system will own each record after launch? A migrated value may be overwritten by an ERP feed. Inventory imported during migration may become irrelevant once WMS synchronization begins. Product descriptions may be managed in a PIM, while marketplace offers come from seller connectors. Customer data may be enriched or governed in a CRM.
| Data area | Possible authoritative system | Required relationship in VTEX |
|---|---|---|
| Product content | PIM, ERP, or VTEX Catalog | Stable Product, SKU, Category, brand, and specification identifiers |
| Price | ERP, pricing platform, or VTEX Pricing | Correct price records by commercial context |
| Inventory | WMS, ERP, seller, or VTEX Logistics | Valid SKU-location quantities and synchronization ownership |
| Customer | CRM, Master Data, or account services | Consistent identity and address relationships |
| Order | VTEX Orders, OMS, ERP, or marketplace flow | Reliable identifiers, statuses, and downstream processing |
| Seller offer | Seller system or marketplace connector | Correct Product-SKU mapping, price, stock, and fulfilment context |
The platform’s API-first and extensible nature supports these integrations, but it does not eliminate data-governance decisions. Migration must establish stable identifiers and ownership before automated flows begin updating the target environment.
VTEX in the Wider Platform Landscape
VTEX is positioned closer to composable and enterprise commerce platforms than to entry-level hosted store builders. It provides a managed cloud foundation while exposing specialized services, APIs, marketplace relationships, storefront development options, and enterprise operational controls.
Compared with simpler SaaS platforms, VTEX separates more of the commerce lifecycle into independently governed services. Compared with self-hosted open-source platforms, it reduces direct infrastructure and core-code ownership while emphasizing configuration, APIs, applications, and connected systems. Compared with a fully custom composable stack, it supplies an integrated commerce platform rather than requiring every service to be selected and assembled independently.
Its migration significance follows from that position. VTEX can represent complex catalogs, channels, sellers, marketplaces, B2B structures, and integrations, but the target architecture must be intentional. Products and Orders are only part of the operating model; commercial context, service relationships, and system ownership determine whether the platform is usable.
Conclusion
VTEX is a modular cloud commerce platform whose core identity extends across Catalog, SKUs, specifications, pricing, promotions, inventory, logistics, trade policies, sellers, marketplaces, checkout, Orders, Master Data, storefronts, applications, and integrations. The platform supports complex enterprise operating models precisely because these concerns are represented as connected but distinct layers.
The central migration orientation is to rebuild those relationships deliberately. Products must be translated into VTEX’s Product-SKU hierarchy. Specifications must carry the correct Product or SKU meaning. Sellability must connect price, inventory, seller, logistics, and channel context. Customer and Order records must remain distinct from live checkout and B2B behavior. Storefronts and enterprise integrations must use stable identifiers and clear system ownership. That architecture defines the foundation for every later article in the VTEX hub.
Common Questions
What is the difference between a Product and an SKU in VTEX?
A Product is the general definition of an item, while an SKU is the specific purchasable variation that carries stock and is selected by the buyer. Every VTEX Product must have at least one SKU.
Why are specifications important in VTEX?
Specifications describe Product or SKU characteristics and are organized through Category-linked groups. They can support variation, filtering, classification, and storefront presentation, so source attributes must be mapped according to their actual purpose.
What does a trade policy represent?
A trade policy establishes commercial context for a channel or operation. It can influence Product availability and other selling conditions, allowing the same account to support different markets or channels.
How does VTEX handle marketplace sellers?
VTEX can connect seller offers to shared Products and SKUs. Sellers may own price, inventory, and fulfilment context, while the marketplace governs catalog presentation and transaction orchestration.
Does migrating Products make them immediately sellable in VTEX?
Not necessarily. An SKU may also need valid specifications, images, activation, price, inventory, seller context, trade-policy availability, and logistics before it can be purchased.
Is a VTEX storefront part of the migrated data?
A storefront is a separate implementation layer. Product and content records can support the experience, but source themes and frontend code must be implemented through the chosen VTEX storefront architecture.