Se BigCommerce viene scelto come piattaforma di destinazione, la preparazione deve definire come lo store di origine diventerà un catalogo BigCommerce gestibile prima dell’avvio di qualsiasi esecuzione di migrazione. Products, varianti, opzioni, modificatori, campi personalizzati, metafields, Categories, listini prezzi, gruppi Customer, canali, Customers, Orders, contenuti e integrazioni sono aree di responsabilità distinte. Una piattaforma di origine può averne combinate diverse all’interno di un unico Product o record di estensione.
Il pacchetto di preparazione dovrebbe indicare il responsabile previsto nella destinazione, fornire evidenze rappresentative, assegnare una persona responsabile e definire una condizione di preparazione completata. In questo modo il set di campioni rappresentativi per la migrazione diventa significativo e tracciabile fino alle evidenze dello store di origine.
Definire l’ambito operativo e di catalogo BigCommerce
Registra prima di tutto i confini operativi previsti in BigCommerce.
| Area | Decisione di preparazione | Evidenza |
|---|---|---|
| Identità del catalogo | Quali record di origine diventano Products e varianti | Mappa delle famiglie Product con ID di origine e responsabilità SKU |
| Scelte dell’acquirente | Quali valori sono varianti, modificatori, campi personalizzati o dati applicativi | Matrice rappresentativa delle opzioni |
| Organizzazione del catalogo | Quali Categories, brand, filtri e landing page di origine devono continuare | Schema di Category e scoperta |
| Contesto commerciale | Quali gruppi Customer, listini prezzi, prezzi per quantità, promozioni e valute sono rilevanti | Inventario delle relazioni di prezzo |
| Ambito dei canali | Quali Products, Categories, contenuti, valute e lingue appartengono a ciascun canale o vetrina | Matrice delle assegnazioni ai canali |
| Dati personalizzati | Quali record appartengono a campi personalizzati, metafields, app o sistemi esterni | Registro dei campi e delle dipendenze |
Documenta se lo “store” di origine rappresenta una sola vetrina, più vetrine regionali, un canale marketplace, un brand, una business unit o un catalogo specifico per Customer. Record Product simili possono richiedere un’unica identità BigCommerce condivisa con assegnazioni ai canali oppure identità separate quando la responsabilità commerciale differisce. Lo stesso confine deve essere applicato in modo coerente a Categories, contenuti, prezzi, valute e accesso Customer affinché il catalogo di destinazione non mescoli record appartenenti a contesti di vendita differenti.
Preparare accessi, esportazioni e definizioni della piattaforma di origine
Prepara gli accessi allo store di origine e a BigCommerce necessari per recuperare e interpretare i dati inclusi nell’ambito. Conserva copie datate affinché il team possa spiegare lo stato della piattaforma di origine anche se lo store live cambia.
Raccogli:
- accesso amministratore allo store di origine e a BigCommerce con permessi appropriati;
- esportazioni di Products, varianti, Categories, Customers, Orders, contenuti e redirect quando disponibili;
- media e documenti Product quando i link di origine possono scadere o richiedere autenticazione;
- evidenze di listini prezzi, gruppi Customer, prezzi per quantità, promozioni e valute;
- assegnazioni a canali o vetrine e liste dei contenuti localizzati;
- dizionari di campi personalizzati, metafields, app e identificatori esterni;
- report da ERP, PIM, WMS, CRM, marketplace o sistemi contabili che identifichino chiavi condivise;
- un registro delle modifiche della piattaforma di origine per i record che potrebbero cambiare prima della finestra di migrazione.
| Elemento di evidenza | Responsabile | Condizione di preparazione completata |
|---|---|---|
| Registro accessi | Amministratori dello store | Le aree necessarie nella piattaforma di origine e in BigCommerce sono accessibili |
| Archivio delle esportazioni | Responsabile dei dati | I file si aprono, contengono i record attesi e riportano la data di esportazione |
| Dizionario dei campi | Responsabile catalogo o tecnico | I campi importanti hanno scopo, tipo, entità padre e responsabile nella destinazione |
| Evidenze di prezzi | Responsabile commerciale | Contesti base, gruppo, listino, quantità e promozione sono distinti |
| Inventario dei canali | Responsabile di canale | Ogni canale ha ambito definito per Product, Category, contenuti, lingua e valuta |
Preparare Products, varianti, opzioni e modificatori
BigCommerce distingue le varianti vendibili dai modificatori scelti dal cliente e dai dati Product descrittivi. Prepara esempi di origine che rendano visibili queste differenze.
Includi:
- Products semplici;
- Products con SKU figli e prezzo, stock, immagine, peso, barcode o ID esterni a livello variante;
- opzioni della piattaforma di origine che modificano un Product senza creare stock indipendente;
- personalizzazione, upload di file, data, misure o scelte di servizio;
- Products con campi personalizzati, metafields, specifiche avanzate o dati di compatibilità;
- bundle, kit, abbonamenti, garanzie o configurazioni gestite dalle applicazioni;
- Products assegnati in modo differente ai canali;
- Products sincronizzati con sistemi esterni di catalogo o inventario.
| Comportamento di origine | Decisione di preparazione BigCommerce | Evidenza da fornire |
|---|---|---|
| La scelta identifica un articolo vendibile separato | Definire responsabilità di Product e variante | ID padre/figlio, valori opzione, SKU, prezzo, stock, immagini e ID esterni |
| La scelta modifica il Product ma non ha stock indipendente | Definire modificatore o altra relazione di destinazione | Tipo di input, valori consentiti, effetto su prezzo/peso ed esempio di riga Order |
| Il valore descrive il Product | Definire campo personalizzato, metafield, contenuto o responsabile app | Tipo di campo, valori controllati, sistemi che usano il dato per visualizzazione e integrazione |
| La combinazione segue logica personalizzata | Definire applicazione o responsabile della logica personalizzata nella destinazione | Esempi di regole, ID componenti ed evidenze storiche Order |
Normalizza nomi e valori delle opzioni prima dell’importazione. Nomi incoerenti possono creare set di opzioni separati e filtri deboli anche quando il concetto aziendale sottostante è lo stesso.
Preparare Categories, prezzi, gruppi Customer e canali
La preparazione BigCommerce dovrebbe trattare scoperta e prezzi come strutture collegate ma separate.
Per le Categories, prepara:
- gerarchia di origine e assegnazioni Product;
- relazioni con brand e manufacturer;
- valori di filtro o facet;
- contenuti delle landing page e metadati;
- Categories interne o obsolete;
- assegnazioni Category specifiche per canale;
- URL e priorità di redirect.
Per i prezzi, prepara evidenze separate per prezzi base, prezzi promozionali, prezzi per quantità, prezzi per gruppo Customer, listini prezzi, coupon e prezzi controllati da app o ERP.
| Relazione commerciale | Domanda di preparazione | Evidenza di preparazione |
|---|---|---|
| Gruppo Customer | Quali Customers vi appartengono e quale significato di accesso o prezzo esprime il gruppo? | Esempi Customer e sintesi delle regole del gruppo |
| Listino prezzi | Quali Products o varianti, valute, Customers o canali lo utilizzano? | Esportazione del listino e mappa delle assegnazioni |
| Prezzi per quantità | Quali soglie quantitative e contesti acquirente si applicano? | Esempi Product con soglie |
| Assegnazione al canale | Quali Products e Categories appartengono a ciascun canale? | Matrice catalogo-canale |
| Promozione | La regola è corrente, storica o obsoleta? | Responsabile della regola e decisione preservare/ricostruire/ritirare |
Non mescolare i prezzi storici degli Orders con la configurazione dei prezzi attiva. Gli Orders storici devono mantenere i valori registrati; il futuro modello di prezzo BigCommerce richiede regole e assegnazioni preparate indipendentemente.
Preparare Customers e Orders storici
Prepara campioni Customer che coprano acquirenti individuali, Orders di utenti non registrati, più indirizzi, gruppi Customer, stato fiscale, contesto company o B2B, campi personalizzati, preferenze marketing, fidelizzazione, abbonamenti e ID account esterni.
Prepara campioni Order che includano:
- Orders pagati, in sospeso, annullati, rimborsati e parzialmente rimborsati;
- più stati di evasione e metodi di spedizione;
- sconti, coupon, gift certificates, imposte, dazi e rettifiche manuali;
- selezioni di varianti e modificatori;
- contesto di gruppo Customer o listino prezzi;
- origine da canale o marketplace;
- riferimenti ERP, contabili, CRM ed evasione.
| Domanda di preparazione | Evidenza | Condizione di preparazione completata |
|---|---|---|
| Come vengono gestiti Customers duplicati? | Esempi duplicati e chiavi di matching | Le regole per mantenere separati o unire sono documentate |
| Quali gruppi Customer restano? | Elenco gruppi e finalità commerciale | Ogni gruppo mantenuto ha un responsabile e una regola associata |
| Quali dettagli degli Orders devono vedere i team di supporto? | Pacchetto rappresentativo Order | Righe, modificatori, totali, stati, rimborsi e riferimenti sono spiegati |
| Quali ID esterni restano operativi? | Mappa delle chiavi tra sistemi | Ogni chiave è associata al livello di entità corretto |
| Quali campi sensibili sono inutili? | Ambito campi approvato | I dati esclusi sono documentati prima della migrazione |
Preparare contenuti, URL e input per i redirect
Crea un inventario delle percorsi per Products, Categories, brand, CMS Pages, Blog Posts, pagine di campagna, file e contenuti localizzati. Includi, quando noti, importanza per traffico, ricavi, backlink, paid media, servizio Customer o compliance.
Per ogni percorsi prioritaria, registra:
- percorso di origine;
- Product, Category, pagina, Blog Post, canale o destinazione esterna prevista in BigCommerce;
- responsabile del contenuto;
- requisiti di metadati e link interni;
- ambito di canale e lingua;
- requisito di redirect o decisione di ritiro.
Separa i record di contenuto dalla presentazione di tema e Page Builder. Una pagina di origine può contenere contenuti riutilizzabili, riferimenti Product, form, widget, script e definizioni di layout che richiedono responsabili di destinazione diversi.
Inventariare app, metafields e sistemi esterni
Crea un registro delle dipendenze per app, script personalizzati, campi personalizzati, metafields, webhook e sistemi collegati. Includi Reviews, ricerca, abbonamenti, bundle, fidelizzazione, B2B, personalizzazione, imposte, spedizione, pagamenti, marketplace, ERP, PIM, WMS, CRM, contabilità, analisi e sistemi di consenso.
Per ogni dipendenza, documenta:
- finalità aziendale;
- record creati o modificati;
- Products, Customers, Orders o contenuti correlati;
- attuale responsabile dei dati e futuro responsabile;
- evidenze di esportazione o API;
- identificatori esterni;
- se la dipendenza continuerà, verrà sostituita o sarà ritirata.
Il registro delle dipendenze è pronto quando nessun valore personalizzato importante è descritto soltanto come “proveniente da un’app”.
Selezionare campioni rappresentativi per la migrazione verso BigCommerce
Scegli un set compatto di campioni che copra relazioni ordinarie ed eccezionali.
| Campione | Finalità della preparazione |
|---|---|
| Product semplice | Stabilire il modello ordinario di Product, Category, media, prezzo e inventario |
| Product con molte varianti | Rendere visibili identità Product/variante, opzioni, stock, immagini e ID esterni |
| Product guidato da modificatori | Rendere visibile l’input del cliente che non dovrebbe diventare una variante con stock |
| Product con campi personalizzati o metafields | Rendere visibile la responsabilità dei dati personalizzati strutturati |
| Product con contesto gruppo Customer o listino | Rendere visibili relazioni commerciali condizionali |
| Product o Category specifico per canale | Rendere visibili assegnazioni ai canali e ambito localizzato |
| Customer complesso | Rendere visibili gruppi, indirizzi, campi personalizzati e ID esterni |
| Order storico complesso | Rendere visibili modificatori, sconti, evasione, rimborsi e contesto di canale |
| Route di contenuto prioritaria | Rendere visibili preparazione di pagina, metadati, link interni e redirect |
Associa a ogni campione ID di origine, URL di origine, responsabili di destinazione previsti, chiavi esterne ed esclusioni note. Il registro dei campioni deve definire che cosa rappresenta il record di origine, quali relazioni contano e quali evidenze lo accompagnano. Includi almeno un record ordinario e uno eccezionale per ogni area operativa principale. Quando diverse strutture di origine sono materialmente differenti, utilizza campioni separati invece di chiedere a un singolo Product o Order di rappresentare schemi conflittuali.
Completare il gate di preparazione BigCommerce
| Domanda di preparazione | Evidenza richiesta | Condizione di preparazione completata |
|---|---|---|
| Gli accessi sono completi? | Registro accessi | Le aree richieste della piattaforma di origine e destinazione sono disponibili |
| Le relazioni Product sono classificate? | Mappa delle famiglie Product e matrice delle opzioni | Varianti, modificatori, campi personalizzati e dati app hanno responsabili |
| Prezzi e relazioni di canale sono documentati? | Matrici prezzi e canali | Assegnazioni tra gruppo, listino, Product, valuta e canale sono esplicite |
| Customers e Orders sono rappresentati? | Registro campioni | Sono coperti i principali schemi account e Orders storici |
| Le percorsi prioritarie sono definite? | Inventario URL | Ogni percorso prioritario di origine ha una destinazione o una decisione di ritiro |
| Le dipendenze hanno un responsabile? | Registro app e integrazioni | Ogni dipendenza importante ha un responsabile futuro |
| Backup ed esportazioni sono aggiornati? | Archivio datato | Le evidenze di origine possono essere recuperate indipendentemente |
| Le decisioni aperte sono sotto controllo? | Registro decisioni | Gli elementi critici hanno responsabili e scadenze |
La preparazione è completa quando il team di migrazione può spiegare come ogni relazione di origine ad alto valore dovrebbe essere rappresentata in BigCommerce senza dipendere da presupposti non documentati. Possono rimanere elementi aperti, ma ciascuno deve avere un responsabile, un requisito di evidenza definito e una data decisionale precedente all’inizio del lavoro di migrazione che ne dipende.
Conclusione
La preparazione per BigCommerce dovrebbe produrre un modello supportato da evidenze per Products, varianti, modificatori, Categories, prezzi, gruppi Customer, canali, Customers, Orders, contenuti e integrazioni. Il compito più importante non è esportare più record; è definire quale oggetto BigCommerce possiede ogni relazione e raccogliere campioni che rendano visibile la reale complessità.
Un pacchetto di preparazione disciplinato fornisce ai test rappresentativi di migrazione un insieme di campioni di origine tracciabili e una chiara responsabilità sulla preparazione.
Domande frequenti
Che cosa dovrebbe essere preparato prima di esportare un catalogo per BigCommerce?
Definisci la responsabilità di Product e varianti, distingui modificatori da varianti, documenta Categories e canali e identifica le relazioni di prezzo e dati personalizzati. L’esportazione diventa più utile quando il team sa già che cosa significa ogni valore di origine.
Perché gruppi Customer e listini prezzi devono essere preparati separatamente?
Un gruppo classifica i Customers, mentre un listino assegna valori commerciali in condizioni definite. Preservarne uno senza l’altro può lasciare incompleta la segmentazione Customer o i prezzi dei Product.
Quali Products BigCommerce appartengono al set di campioni rappresentativi della migrazione?
Includi un Product semplice, uno con molte varianti, uno guidato da modificatori, uno con dati personalizzati, uno con prezzi condizionale e uno specifico per canale. Aggiungi qualsiasi configurazione specifica della piattaforma che comporti ricavi o rischio operativo rilevanti.
Ogni Category della piattaforma di origine dovrebbe diventare una BigCommerce Category?
No. Alcuni raggruppamenti di origine sono link di navigazione, filtri, collection di campagna, strutture brand o classificazioni interne. Assegna ogni raggruppamento in base alla sua finalità futura.
Quali evidenze Order dovrebbero essere preparate?
Prepara Orders con selezioni di varianti e modificatori, sconti, imposte, spedizioni, più stati, rimborsi e riferimenti a sistemi esterni. I campioni devono spiegare il significato storico senza definire la futura configurazione del processo di acquisto.
Quando è completa la preparazione per BigCommerce?
È completa quando gli accessi funzionano, le evidenze della piattaforma di origine sono aggiornate, Products e relazioni commerciali hanno responsabili nella destinazione, gli URL prioritari sono mappati, le dipendenze sono inventariate e i campioni rappresentativi di migrazione sono documentati.