Se il progetto seleziona VTEX come piattaforma di destinazione, la preparazione deve trasformare il modello e-commerce enterprise corrente in un insieme di informazioni e prove con responsabilità chiare prima di avviare qualsiasi esecuzione della migrazione. Catalog, Pricing, Promotions, Trade Policies, Inventory, Logistics, Checkout, Payments, OMS, Master Data, seller, relazioni marketplace e contenuti storefront sono collegati, ma governati separatamente.
Per ogni area dati importante, occorre registrare azione, responsabile, prova disponibile e condizione che consente di considerarla pronta. Questo evita di scambiare un export Products per un Catalog VTEX completo oppure lo storico Orders per la configurazione corrente di Logistics e Checkout.
Definire il modello operativo VTEX e la responsabilità dei domini
Preparare una mappa sintetica che indichi quali domini VTEX e sistemi esterni possiedono ciascuna relazione commerciale.
| Area di preparazione | Decisione da registrare | Responsabile | Prova di preparazione |
|---|---|---|---|
| Catalog | Categories, Brands, Products, SKUs, specifications, attachments, kit e assembly options | Responsabile Catalog | Mappa delle relazioni Catalog |
| Contesto commerciale | Prezzi, Promotions, Trade Policies, seller, offerte e assortimento per canale | Responsabile commerciale | Matrice SKU/canale/prezzo/responsabilità |
| Customer e B2B | Profili Customers, indirizzi, organizzazioni, ruoli, cost center ed entità Master Data | Responsabile Customer/B2B | Diagramma identità ed entità |
| Orders e operations | Checkout, Payments, OMS, Logistics, inventario, warehouses, docks, carrier e seller | Responsabile operations | Mappa domini Order e Logistics |
| Storefront | CMS, search, navigazione, route, contenuti e responsabilità del frontend headless | Responsabile esperienza digitale | Mappa responsabilità storefront |
| Sistemi esterni | ERP, PIM, WMS, CRM, marketplace, tax, accounting e middleware | Responsabile tecnico | Registro dipendenze e sistemi autorevoli |
La mappa deve indicare dove ogni valore viene gestito come fonte autorevole e quale identificativo lo collega agli altri domini.
Preparare accessi, export, backup e prove della sorgente
Raccogliere:
- accesso amministratore alla sorgente e gli accessi amministrativi VTEX necessari;
- export datati di Products, SKUs, Categories, Brands, prezzi, promotions, Customers, Orders e contenuti;
- archivi di database, media o applicazioni quando disponibili;
- gruppi di specifications, Product specifications, SKU specifications e valori controllati;
- report relativi a Trade Policy, seller, canali, warehouse, dock, carrier e inventario;
- esempi di entità Customers, B2B e Master Data;
- identificativi di cataloghi marketplace e seller;
- inventari CMS, search, navigazione, URL, metadata e redirect;
- inventari di app, API, middleware, integrazioni e sistemi esterni;
- screenshot o report che spieghino funzioni importanti della sorgente.
| Prova | Perché serve | Condizione di preparazione |
|---|---|---|
| Dizionario Catalog | Spiega il significato di Product/SKU/specification | Ogni campo prioritario ha un responsabile e un valore rappresentativo |
| Matrice canali e seller | Protegge il perimetro di Trade Policy e marketplace | Ogni relazione seller e canale è documentata |
| Inventario Master Data | Identifica entità personalizzate fuori dai normali record Customer | Ogni entità importante ha schema, chiave e responsabile |
| Registro integrazioni | Protegge la continuità tra sistemi esterni | Ogni identificativo durevole è collegato alla corretta entità VTEX o esterna |
| Inventario route/contenuti | Separa implementazione storefront dai dati Catalog | Route e contenuti prioritari hanno responsabili di destinazione |
Un export API mancante o una trasformazione middleware non documentata deve restare visibile come elemento di preparazione irrisolto.
Preparare Categories, Products, SKUs e specifications
Selezionare record rappresentativi che espongano la gerarchia VTEX: Category, Brand, Product, SKU, gruppo specification, Product specification e SKU specification.
Includere:
- Products semplici con un solo SKU;
- Products con più SKUs;
- Products in cui i valori SKU definiscono taglia, colore, modello, voltaggio, regione o confezione;
- gruppi di specifications specifici per Category e campi ereditati;
- Products con Brands, media, contenuti correlati o identificativi PIM esterni;
- attachments, services, kit, bundle o comportamento assembly-option;
- Products forniti da più seller o canali.
| Comportamento sorgente | Decisione di preparazione VTEX | Prova richiesta |
|---|---|---|
| Il valore distingue l’unità vendibile | Definire SKU specification e relazione SKU | IDs Product/SKU, valori, immagini, stock e chiavi esterne |
| Il valore descrive il Product generico | Definire Product specification | Category, gruppo specification, tipo di campo e valori |
| Il Customer fornisce informazioni | Definire attachment o altro responsabile applicativo | Definizione input ed esempio storico Order |
| Il Product comprende componenti o elementi opzionali | Definire kit, assembly option, service o responsabile esterno | Elenco componenti, quantità, prezzo, inventario e comportamento Order |
| Il Catalog è alimentato da PIM | Conservare identificativi PIM e VTEX | Sistema autorevole e chiave di sincronizzazione |
Prima della mappatura finale, normalizzare nomi di specifications duplicati, valori incoerenti, SKUs orfani, assegnazioni Category mancanti e Products obsoleti. Il Catalog è pronto quando ogni famiglia Product importante dispone di un piano per Category, Brand, Product, SKU, specification e ID esterno.
Preparare Trade Policies, Pricing, seller e contesto commerciale
Le Trade Policies possono collegare Catalog, pricing, Promotions, inventario, Logistics, impostazioni di pagamento e canali di vendita. Seller e offerte marketplace aggiungono un ulteriore livello di responsabilità.
| Record commerciale | Azione di preparazione | Prova di preparazione |
|---|---|---|
| Trade Policy | Definire canale di vendita, disponibilità Catalog, regole commerciali e operations collegate | Matrice Trade Policy |
| Prezzo | Identificare SKU, valuta, price table, contesto Customer o canale e sistema autorevole | Esempi rappresentativi di prezzi SKU |
| Promotion | Registrare condizioni, perimetro, date e Products o Customers interessati | Inventario delle promotions prioritarie |
| Seller | Definire identità seller, Products, offerte, responsabilità di evasione e IDs esterni | Matrice responsabilità seller |
| Offerta marketplace | Separare identità Catalog canonica da prezzo, stock ed evasione specifici del seller | Esempio mappatura Product/SKU/seller |
| Assortimento B2B | Definire relazioni tra organizzazione, Trade Policy, Catalog, prezzo e accesso | Scenario buyer B2B rappresentativo |
Non trattare prezzi specifici per canale o record seller della sorgente come normali campi Product. La condizione di preparazione è che ogni SKU prioritario abbia un responsabile del prezzo, un perimetro Trade Policy, una relazione seller e un’autorità sull’inventario dichiarati.
Preparare Customers, record B2B e Master Data
I dati collegati ai Customers possono comprendere profili ordinari, indirizzi, organizzazioni, ruoli buyer, cost center, contesto di approvazione, moduli personalizzati, consensi, loyalty, CRM IDs e documenti Master Data.
Preparare:
- Customers registrati, guest, indirizzi multipli, identità duplicate e IDs esterni;
- organizzazioni B2B, utenti, ruoli, cost center e contesto commerciale;
- entità Customers e di processo personalizzate conservate fuori dai profili standard;
- schemi, campi, chiavi, riferimenti e applicazioni che utilizzano le entità Master Data;
- decisioni su consenso, privacy e retention;
- identificativi CRM, ERP, loyalty, marketplace e supporto.
| Record sorgente | Responsabile | Prova richiesta | Condizione di preparazione |
|---|---|---|---|
| Identità Customer | Customer operations | Esempi di duplicati e guest | Regole di identità e merge documentate |
| Organizzazione B2B | Responsabile B2B | Matrice organizzazione/utente/ruolo/cost center | Le relazioni aziendali hanno un responsabile target definito |
| Documento Master Data | Responsabile del processo aziendale | Schema entità ed esempio di riferimento | Chiave, relazione parent e applicazione o processo che continuerà a utilizzarlo sono noti |
| Consenso o campo sensibile | Responsabile legale/dati | Elenco campi approvato | Finalità richiesta e base di retention documentate |
| Chiave esterna | Responsabile integrazione | Esempio lookup CRM/ERP/marketplace | La chiave è associata al corretto livello di entità |
Master Data non dovrebbe diventare un contenitore generico per campi sorgente indefiniti. Ogni documento personalizzato deve avere un’entità aziendale nominata, una chiave, una relazione e un responsabile futuro.
Preparare Orders storici e riferimenti operativi
Selezionare Orders che espongano identità Customer, seller, Trade Policy, righe SKU, prezzi, Promotions, imposte, riferimenti pagamento, dati di spedizione, evasione, stato e IDs esterni.
Includere:
- Orders ordinari, cancellati, rimborsati e parzialmente evasi;
- Orders per ogni seller, Trade Policy, valuta e canale di vendita importante;
- Orders marketplace;
- Orders con più spedizioni o carrier;
- Orders contenenti kit, attachments, services o dati personalizzati;
- Orders collegati a ERP, accounting, WMS, marketplace o sistemi di supporto.
| Area storica | Prova | Condizione di preparazione |
|---|---|---|
| Righe Product/SKU | Pacchetto Orders rappresentativo | SKU acquistato, seller, quantità, prezzo e dati personalizzati sono spiegati |
| Contesto pagamento | Esempi di metodo, transazione e stato | Riferimenti storici e confini dei dati sensibili sono documentati |
| Contesto Logistics | Esempi di metodo shipping, SLA, carrier, warehouse, dock, tracking ed evasione | La relazione storica è comprensibile senza configurare Logistics live |
| Rettifiche | Promotions, tax, rimborsi, cancellazioni e modifiche manuali | I totali storici possono essere spiegati |
| Tracciabilità esterna | IDs ERP, marketplace o accounting | Le chiavi di riconciliazione sono conservate al corretto livello Order |
Gli Orders storici sono prova dell’e-commerce passato. La configurazione corrente di Checkout, Payments, OMS, Logistics, carrier e warehouse resta separata dai record Order migrati.
Preparare inventario, Logistics, contenuti storefront e URL
La preparazione dell’inventario deve identificare quale sistema possiede quantità e disponibilità, quali warehouse o seller forniscono ciascuno SKU e come vengono rappresentati Trade Policy e contesto Logistics rilevanti.
Per lo storefront raccogliere:
- contenuti Product e Category;
- CMS Pages, landing pages, Blog Posts, guide e contenuti di campagna;
- esempi di search, faccette, navigazione e filtri;
- URL prioritari di Product, Category, Brand, campagne e contenuti;
- metadata, relazioni canonical e redirect;
- responsabilità del frontend headless o CMS;
- inventari media e link interni.
| Area | Domanda di preparazione | Prova di preparazione |
|---|---|---|
| Inventario | Quale sistema, warehouse, seller o feed possiede la quantità di ciascuno SKU? | Matrice SKU/sistema autorevole |
| Logistics | Quale relazione warehouse, dock, carrier, SLA, pickup o evasione è rilevante? | Mappa Logistics rappresentativa |
| Search e faccette | Quali specifications e Categories supportano la scoperta dei Products? | Esempi controllati di campi e filtri |
| Contenuti | Quale CMS VTEX, CMS esterno o repository frontend possiede il record? | Inventario responsabilità contenuti |
| URL | Quale route e redirect preservano ciascun percorso prioritario della sorgente? | Registro URL sorgente/destinazione |
L’area è pronta quando record Catalog, inventario, Logistics, contenuti e route hanno responsabili distinti invece di essere trattati come un unico export storefront.
Inventariare app, API e sistemi esterni
Creare un registro delle dipendenze per ogni app, API, flusso middleware, integrazione personalizzata, webhook e piattaforma esterna che crea o modifica record Catalog, Customer, Order, prezzo, seller, inventario, Logistics o contenuto.
Per ogni dipendenza registrare:
- finalità aziendale;
- dominio VTEX e record interessati;
- sistema esterno autorevole;
- IDs e chiavi di riferimento;
- disponibilità API o export;
- responsabili aziendali e tecnici;
- decisione su continuità, sostituzione o dismissione nel target;
- dati necessari prima di poter configurare il processo di destinazione.
Le dipendenze prioritarie includono ERP, PIM, WMS, OMS, CRM, accounting, tax, antifrode, search, marketplace, loyalty, subscription, personalizzazione, analytics e sistemi contenuto.
Il registro è pronto quando ogni valore importante ha un unico responsabile autorevole e una chiave durevole. Un campo middleware privo delle entità sorgente e destinazione collegate costituisce prova incompleta.
Selezionare campioni rappresentativi per il test di migrazione
| Campione | Finalità della preparazione |
|---|---|
| Product con più SKUs | Esporre relazioni Product/SKU/specification/media |
| Category con specifications ereditate | Esporre gerarchia Catalog e responsabilità dei campi |
| SKU usato in più Trade Policies | Esporre contesto di pricing, canale, inventario e Logistics |
| Product marketplace e offerta seller | Esporre Catalog canonico rispetto alla responsabilità seller |
| Customer o organizzazione B2B | Esporre identità, ruolo, cost center e contesto commerciale |
| Documento Master Data | Esporre entità personalizzata, chiave, riferimento e responsabile |
| Order storico complesso | Esporre seller, SKU, promotion, pagamento, evasione e IDs esterni |
| Contenuto o route headless | Esporre responsabilità frontend, CMS, SEO e redirect |
Per ogni campione registrare ID sorgente, URL sorgente quando rilevante, motivazione aziendale, dominio VTEX previsto, identificativi esterni, esclusioni note e revisore responsabile.
Completare la verifica di preparazione VTEX
| Domanda | Prova richiesta | Condizione di preparazione |
|---|---|---|
| Accessi e archivi sorgente sono recuperabili? | Registro accessi ed export/backup datati | I record necessari possono essere esaminati indipendentemente dallo Store sorgente live |
| La responsabilità dei domini è documentata? | Mappa domini VTEX e sistemi esterni | Ogni famiglia principale di record ha un responsabile |
| Le strutture Catalog e SKU sono preparate? | Matrice Product/SKU/specification | Ogni pattern Product importante ha una rappresentazione VTEX definita |
| Trade Policies, seller e prezzi sono assegnati? | Matrice responsabilità commerciali | Casi rappresentativi per canali e seller sono completi |
| Entità Customers e Master Data sono definite? | Diagrammi identità ed entità | Chiavi, relazioni e applicazioni che utilizzano i dati sono documentate |
| Orders e riferimenti operativi sono spiegati? | Pacchetto Orders storici | Le transazioni passate restano comprensibili |
| App e sistemi esterni sono inventariati? | Registro dipendenze | Ogni dipendenza critica ha un responsabile futuro |
| I campioni rappresentativi sono selezionati? | Registro campioni | La complessità Catalog, commerciale, Customer, Order e storefront è coperta |
| Gli elementi irrisolti sono controllati? | Registro decisioni | Ogni punto aperto ha un responsabile e una scadenza |
La preparazione è completa quando nessuna decisione critica su Catalog, SKU, Trade Policy, seller, Customer, Master Data, Order, inventario, route o integrazioni dipende da presupposti non documentati.
Conclusione
La preparazione a una migrazione verso VTEX deve produrre un insieme di prove enterprise con responsabilità di dominio esplicite. Categories, Products, SKUs, specifications, Trade Policies, seller, prezzi, Customers, Master Data, Orders, Logistics, contenuti e integrazioni devono avere ciascuno un responsabile dichiarato e record rappresentativi.
Se queste decisioni vengono preparate prima del test rappresentativo di migrazione, il campione può riflettere l’architettura VTEX desiderata anziché considerare una raccolta di record importati come un’operazione e-commerce completa.
Domande frequenti
Quale documento di preparazione VTEX dovrebbe essere creato per primo?
Iniziare dalla mappa delle responsabilità per Catalog, contesto commerciale, Customers, Orders, operations, storefront e sistemi esterni. Questa mappa determina quali prove e responsabili sono necessari.
Perché Products e SKUs devono essere preparati separatamente?
Il Product rappresenta la definizione commerciale generale, mentre ogni SKU rappresenta una variante vendibile. Specifications, immagini, inventario, prezzi, offerte seller e righe Orders possono dipendere dalla relazione SKU.
Che cosa va preparato per le Trade Policies?
Documentare canale di vendita, disponibilità SKU, contesto di prezzo, Promotions, inventario, Logistics, relazioni pagamento, seller e sistemi esterni associati a ciascuna Trade Policy prioritaria.
Come deve essere preparato Master Data?
Definire ogni entità, schema, chiave durevole, relazioni parent, applicazioni che utilizzano i dati, requisiti privacy e responsabile di destinazione. Master Data non deve essere trattato come contenitore generico per campi indefiniti.
Come vanno preparati gli Orders storici per VTEX?
Fornire Orders rappresentativi con righe SKU, seller, prezzi, Promotions, tax, riferimenti pagamento, contesto shipping, evasione, stati e IDs esterni. Mantenere queste prove separate dalla configurazione operativa corrente.
Quando la preparazione VTEX può considerarsi completa?
Quando responsabilità dei domini, strutture Catalog, relazioni commerciali, entità Customers e Master Data, Orders, contenuti, route, integrazioni, campioni e decisioni irrisolte sono tutti documentati con responsabili accountable.