VTEX preparation should convert an enterprise commerce model into a domain-owned evidence package before any migration run begins. Catalog, Pricing, Promotions, Trade Policies, Inventory, Logistics, Checkout, Payments, OMS, Master Data, sellers, marketplace relationships, and storefront content are connected but separately governed areas.
For every important data area, record the action, owner, evidence, and ready condition. This prevents a Product export from being mistaken for a complete VTEX Catalog, or historical Orders from being mistaken for current logistics and checkout configuration.
Define the VTEX Operating and Domain Ownership Model
Prepare a concise map showing which VTEX domains and external systems own each commercial relationship.
| Preparation area | Decision to record | Owner | Ready evidence |
|---|---|---|---|
| Catalog | Categories, Brands, Products, SKUs, specifications, attachments, kits, and assembly options | Catalog owner | Catalog relationship map |
| Commercial context | Prices, Promotions, Trade Policies, sellers, offers, and channel assortment | Commercial owner | SKU/channel/price ownership matrix |
| Customer and B2B | Customer profiles, addresses, organizations, roles, cost centers, and Master Data entities | Customer/B2B owner | Identity and entity diagram |
| Orders and operations | Checkout, Payments, OMS, Logistics, inventory, warehouses, docks, carriers, and sellers | Operations owner | Order-domain and logistics map |
| Storefront | CMS, search, navigation, routes, content, and headless frontend ownership | Digital experience owner | Storefront ownership map |
| External systems | ERP, PIM, WMS, CRM, marketplace, tax, accounting, and middleware | Technical owner | Dependency and system-of-record register |
The map should state where a value is mastered and which identifier connects it to other domains.
Prepare Access, Exports, Backups, and Source Evidence
Collect:
- source administrator access and required VTEX administrative access;
- dated Product, SKU, Category, Brand, price, promotion, Customer, Order, and content exports;
- database, media, or application archives where available;
- specification groups, Product specifications, SKU specifications, and controlled values;
- Trade Policy, seller, channel, warehouse, dock, carrier, and inventory reports;
- Customer, B2B, and Master Data entity examples;
- marketplace catalog and seller identifiers;
- CMS, search, navigation, URL, metadata, and redirect inventories;
- app, API, middleware, integration, and external-system inventories;
- screenshots or reports explaining important source behavior.
| Evidence item | Why it is needed | Ready condition |
|---|---|---|
| Catalog dictionary | Explains Product/SKU/specification meaning | Every priority field has an owner and representative value |
| Channel and seller matrix | Protects Trade Policy and marketplace scope | Each seller and channel relationship is documented |
| Master Data inventory | Identifies custom entities outside ordinary Customer records | Every important entity has a schema, key, and owner |
| Integration register | Protects external-system continuity | Every durable identifier is linked to the correct VTEX or external entity |
| Route/content inventory | Separates storefront implementation from Catalog data | Priority routes and content have destination owners |
A missing API export or undocumented middleware transformation should remain visible as an unresolved preparation item.
Prepare Categories, Products, SKUs, and Specifications
Select representative records that expose the VTEX hierarchy: Category, Brand, Product, SKU, specification group, Product specification, and SKU specification.
Include:
- simple Products with one SKU;
- Products with several SKUs;
- Products whose SKU values define size, color, model, voltage, region, or package;
- Category-specific specification groups and inherited fields;
- Products with Brands, media, related content, or external PIM identifiers;
- attachments, services, kits, bundles, or assembly-option behavior;
- Products supplied by several sellers or channels.
| Source behavior | VTEX preparation decision | Required evidence |
|---|---|---|
| Value distinguishes the sellable unit | Define SKU specification and SKU relationship | Product/SKU IDs, values, images, stock, and external keys |
| Value describes the generic Product | Define Product specification | Category, specification group, field type, and values |
| Customer supplies information | Define attachment or another application owner | Input definition and historical Order example |
| Product includes components or optional items | Define kit, assembly option, service, or external owner | Component list, quantity, price, inventory, and Order behavior |
| Catalog is supplied by PIM | Preserve PIM and VTEX identifiers | System-of-record and synchronization key |
Normalize duplicate specification names, inconsistent values, orphan SKUs, missing Category assignments, and obsolete Products before final mapping. The Catalog is ready when every major Product family has a Category, Brand, Product, SKU, specification, and external-ID plan.
Prepare Trade Policies, Pricing, Sellers, and Commercial Context
Trade Policies can connect Catalog, pricing, Promotions, inventory, logistics, payment settings, and sales channels. Sellers and marketplace offers introduce another ownership layer.
| Commercial record | Preparation action | Ready evidence |
|---|---|---|
| Trade Policy | Define the sales channel, Catalog availability, commercial rules, and related operations | Trade Policy matrix |
| Price | Identify SKU, currency, price table, Customer or channel context, and system of record | Representative SKU price examples |
| Promotion | Record conditions, scope, dates, and affected Products or Customers | Priority promotion inventory |
| Seller | Define seller identity, Products, offers, fulfillment responsibility, and external IDs | Seller ownership matrix |
| Marketplace offer | Separate canonical Catalog identity from seller-specific price, stock, and fulfillment | Product/SKU/seller mapping example |
| B2B assortment | Define organization, Trade Policy, Catalog, price, and access relationships | Representative B2B buyer scenario |
Do not treat source channel prices or seller records as ordinary Product fields. The ready condition is that every priority SKU has a declared price owner, Trade Policy scope, seller relationship, and inventory authority.
Prepare Customers, B2B Records, and Master Data
Customer-related data can include ordinary profiles, addresses, organizations, buyer roles, cost centers, approval context, custom forms, consent, loyalty, CRM IDs, and Master Data documents.
Prepare:
- registered Customers, guests, multiple addresses, duplicate identities, and external IDs;
- B2B organizations, users, roles, cost centers, and commercial context;
- custom Customer and workflow entities stored outside standard profiles;
- Master Data entity schemas, fields, keys, references, and consumers;
- consent, privacy, and retention decisions;
- CRM, ERP, loyalty, marketplace, and support identifiers.
| Source record | Owner | Required evidence | Ready condition |
|---|---|---|---|
| Customer identity | Customer operations | Duplicate and guest examples | Identity and merge rules are documented |
| B2B organization | B2B owner | Organization/user/role/cost-center matrix | Company relationships have a defined target owner |
| Master Data document | Business process owner | Entity schema and reference example | Key, parent relationship, and continuing consumer are known |
| Consent or sensitive field | Legal/data owner | Approved field list | Required purpose and retention basis are documented |
| External key | Integration owner | CRM/ERP/marketplace lookup example | The key is attached to the correct entity level |
Master Data should not become a dumping ground for undefined source fields. Each custom document needs a named business entity, key, relationship, and future owner.
Prepare Historical Orders and Operational References
Select Orders that expose Customer identity, seller, Trade Policy, SKU lines, prices, Promotions, taxes, payment references, shipping data, fulfillment, status, and external IDs.
Include:
- ordinary, canceled, refunded, and partially fulfilled Orders;
- Orders from each important seller, Trade Policy, currency, and sales channel;
- marketplace Orders;
- Orders with multiple shipments or carriers;
- Orders containing kits, attachments, services, or custom data;
- Orders connected to ERP, accounting, WMS, marketplace, or support systems.
| Historical area | Evidence | Ready condition |
|---|---|---|
| Product/SKU lines | Representative Order packet | Purchased SKU, seller, quantity, price, and custom data are explained |
| Payment context | Method, transaction, and status examples | Historical references and sensitive-data boundaries are documented |
| Logistics context | Shipping method, SLA, carrier, warehouse, dock, tracking, and fulfillment examples | The historical relationship is understandable without configuring live logistics |
| Adjustments | Promotions, taxes, refunds, cancellations, and manual changes | Historical totals can be explained |
| External lineage | ERP, marketplace, or accounting IDs | Reconciliation keys are retained at the correct Order level |
Historical Orders are evidence of past commerce. Current Checkout, Payments, OMS, Logistics, carrier, and warehouse configuration remains separate from the migrated Order records.
Prepare Inventory, Logistics, Storefront Content, and URLs
Inventory preparation should identify which system owns quantity and availability, which warehouses or sellers supply each SKU, and how the relevant Trade Policy and logistics context are represented.
For storefront preparation, collect:
- Product and Category content;
- CMS Pages, landing pages, Blog Posts, guides, and campaign content;
- search, facets, navigation, and filter examples;
- priority Product, Category, Brand, campaign, and content URLs;
- metadata, canonical relationships, and redirects;
- headless frontend or CMS ownership;
- media and internal-link inventories.
| Area | Preparation question | Ready evidence |
|---|---|---|
| Inventory | Which system, warehouse, seller, or feed owns each SKU quantity? | SKU/system-of-record matrix |
| Logistics | Which warehouse, dock, carrier, SLA, pickup, or fulfillment relationship matters? | Representative logistics map |
| Search and facets | Which specifications and Categories support discovery? | Controlled field and filter examples |
| Content | Which VTEX CMS, external CMS, or frontend repository owns the record? | Content ownership inventory |
| URLs | Which route and redirect preserve each priority source path? | Source/destination URL ledger |
The area is ready when Catalog records, inventory, logistics, content, and routes have distinct owners rather than being treated as one storefront export.
Inventory Apps, APIs, and External Systems
Create a dependency register for every app, API, middleware flow, custom integration, webhook, and external platform that creates or modifies Catalog, Customer, Order, price, seller, inventory, logistics, or content records.
For each dependency, record:
- business purpose;
- VTEX domain and records affected;
- external system of record;
- IDs and reference keys;
- API or export availability;
- business and technical owners;
- continuing destination, replacement, or retirement decision;
- data required before the target workflow can be configured.
Priority dependencies include ERP, PIM, WMS, OMS, CRM, accounting, tax, fraud, search, marketplace, loyalty, subscription, personalization, analytics, and content systems.
The register is ready when each important value has one authoritative owner and a durable key. A middleware field without its source and destination entities is incomplete evidence.
Select Representative Migration Test Samples
| Sample | Preparation purpose |
|---|---|
| Product with several SKUs | Expose Product/SKU/specification/media relationships |
| Category with inherited specifications | Expose Catalog hierarchy and field ownership |
| SKU used in several Trade Policies | Expose pricing, channel, inventory, and logistics context |
| Marketplace Product and seller offer | Expose canonical Catalog versus seller ownership |
| B2B Customer or organization | Expose identity, role, cost-center, and commercial context |
| Master Data document | Expose custom entity, key, reference, and owner |
| Complex historical Order | Expose seller, SKU, promotion, payment, fulfillment, and external IDs |
| Headless content or route | Expose frontend, CMS, SEO, and redirect ownership |
For every sample, record the source ID, source URL where relevant, business reason, intended VTEX domain, external identifiers, known exclusions, and responsible reviewer.
Complete the VTEX Readiness Gate
| Readiness question | Required evidence | Ready condition |
|---|---|---|
| Are access and source archives recoverable? | Access record and dated exports/backups | Required records can be inspected independently of the live Source Store |
| Is domain ownership documented? | VTEX domain and external-system map | Every major record family has an owner |
| Are Catalog and SKU structures prepared? | Product/SKU/specification matrix | Every major Product pattern has a defined VTEX representation |
| Are Trade Policies, sellers, and prices assigned? | Commercial ownership matrix | Representative channel and seller cases are complete |
| Are Customer and Master Data entities defined? | Identity and entity diagrams | Keys, relationships, and consumers are documented |
| Are Orders and operational references explained? | Historical Order packet | Past transactions remain understandable |
| Are apps and external systems inventoried? | Dependency register | Every critical dependency has a continuing owner |
| Are representative migration samples selected? | Sample ledger | Catalog, commercial, Customer, Order, and storefront complexity is covered |
| Are unresolved items controlled? | Decision log | Every open item has an owner and due date |
The preparation gate is complete when no critical Catalog, SKU, Trade Policy, seller, Customer, Master Data, Order, inventory, route, or integration decision depends on undocumented assumptions.
Conclusion
VTEX preparation should produce a domain-owned enterprise evidence package. Categories, Products, SKUs, specifications, Trade Policies, sellers, prices, Customers, Master Data, Orders, logistics, content, and integrations must each have a declared owner and representative records.
When those decisions are prepared before the representative migration test, the sample set can reflect the intended VTEX architecture instead of treating a collection of imported records as a complete commerce operation.
Common Questions
Which VTEX preparation record should be created first?
Start with the domain-ownership map for Catalog, commercial context, Customers, Orders, operations, storefront, and external systems. It determines which evidence and owners are required.
Why must Products and SKUs be prepared separately?
The Product represents the generic commercial definition, while each SKU represents a sellable variation. Specifications, images, inventory, prices, seller offers, and Order lines can depend on the SKU relationship.
What should be prepared for Trade Policies?
Document the sales channel, SKU availability, price context, Promotions, inventory, logistics, payment relationships, sellers, and external systems associated with each priority Trade Policy.
How should Master Data be prepared?
Define each entity, schema, durable key, parent relationships, consumers, privacy requirements, and target owner. Do not treat Master Data as a generic location for undefined fields.
How should historical Orders be prepared for VTEX?
Provide representative Orders with SKU lines, sellers, prices, Promotions, taxes, payment references, shipping context, fulfillment, statuses, and external IDs. Keep that evidence separate from current operational configuration.
When is VTEX preparation complete?
It is complete when domain ownership, Catalog structures, commercial relationships, Customer and Master Data entities, Orders, content, routes, integrations, samples, and unresolved decisions are all documented with accountable owners.