Data mapping nella migrazione eCommerce: come mantenere collegati campi personalizzati, varianti e SKU

Il data mapping in una migrazione eCommerce definisce dove devono finire i dati di origine nella nuova piattaforma, come conservarne il significato e quali record devono restare collegati. Se configurato bene, mantiene ogni variante associata al prodotto corretto, ogni SKU legato all’articolo vendibile giusto e ogni ordine collegato al cliente corretto.

Per chi gestisce un negozio, questo significa maggiore tranquillità operativa: il cliente può scegliere la taglia desiderata, il magazzino riceve il codice articolo corretto e il servizio clienti riesce a interpretare un vecchio ordine. Un catalogo può sembrare completo anche quando uno di questi collegamenti è errato. Per questo il mapping va controllato con attenzione prima della Full Migration.

Che cosa collega davvero il data mapping?

Ogni piattaforma ha uno schema, cioè la struttura con cui organizza prodotti, clienti, ordini e relativi campi. Due negozi possono mostrare la stessa pagina prodotto ma memorizzare le informazioni in modo diverso. Il mapping collega queste strutture in base al risultato desiderato.

Tre concetti rendono il processo più facile da seguire:

Mapping dei campi: scegliere dove deve essere memorizzato un valore nel target, ad esempio un riferimento del fornitore o un identificativo fiscale del cliente.

Mapping delle relazioni: preservare i collegamenti tra record, ad esempio tra un prodotto e le sue varianti o tra un cliente e i suoi ordini.

Trasformazione dei dati: modificare un valore secondo una regola concordata, ad esempio convertire un peso da grammi a chilogrammi.

Queste decisioni fanno parte dello stesso piano di migrazione, ma svolgono funzioni diverse. Spostare “500” in un campo peso non lo trasforma automaticamente in 0,5 chilogrammi. Allo stesso modo, copiare l’ID di un prodotto in un ordine non crea una relazione valida se la piattaforma di destinazione assegna ID differenti.

Segui un prodotto durante l’intera migrazione

Immagina un negozio outdoor che vende una Trail Jacket in due colori e tre taglie. La giacca blu navy, taglia M, ha SKU TJ-NV-M, una propria quantità di stock e un barcode. Il prodotto include anche un campo con le istruzioni di cura, mentre ogni variante ha un codice fornitore separato.

La migrazione deve preservare quali informazioni appartengono all’intero prodotto e quali a una singola combinazione. Spostare un codice fornitore specifico della variante sul prodotto padre potrebbe far sì che tutte le taglie puntino allo stesso articolo del fornitore.

Di seguito trovi un piano di mapping illustrativo. Le etichette descrivono il risultato desiderato, non garantiscono che questi campi siano disponibili in ogni Migration Path.

Per una migrazione da WooCommerce a Shopify, parti dai dati supportati per quella specifica combinazione. WooCommerce documenta variazioni con impostazioni proprie di prezzo, stock e immagine; anche il modello di varianti di Shopify collega una combinazione vendibile alle informazioni di prodotto e inventario. Un comportamento simile nello storefront richiede comunque controlli accurati su campi e relazioni.

Come restano collegati varianti e SKU?

Una variante rappresenta una combinazione vendibile. Uno SKU è un identificativo commerciale associato a un articolo. Un internal ID identifica un record all’interno di uno specifico sistema. Trattare questi elementi come equivalenti crea errori di matching evitabili.

Mantieni distinti il prodotto padre e ogni combinazione vendibile

Per la Trail Jacket, “Navy / Medium” deve restare associata al prodotto padre corretto, con prezzo, stock, immagine e barcode corretti. Un buon controllo segue la combinazione selezionata dallo storefront fino all’ordine. Contare sei varianti importate non basta per dimostrare che i loro attributi siano corretti.

Distingui inoltre le varianti dai campi di personalizzazione. Un messaggio da incidere o una nota di consegna può descrivere un acquisto senza rappresentare un articolo con stock separato. Convertire ogni opzione in variante può modificare la struttura del catalogo e creare combinazioni che il negozio non ha mai venduto.

Verifica se gli SKU sono chiavi di matching affidabili

Gli SKU possono aiutare ad associare i record quando sono valorizzati, univoci nell’ambito concordato e stabili. Sono meno affidabili quando prodotto padre e varianti condividono lo stesso SKU, due negozi sorgente riutilizzano gli stessi codici oppure vecchi prodotti hanno valori vuoti.

• Individua SKU mancanti o duplicati sia a livello di prodotto sia di variante.
• Conserva la formattazione significativa, inclusi zeri iniziali, punteggiatura e maiuscole/minuscole.
• Definisci come i record sorgente devono corrispondere agli articoli già presenti nel target.
• Documenta le eccezioni invece di rinominare automaticamente codici utilizzati dai sistemi di inventario o fulfillment.

Quando uno SKU non è una chiave sicura, la migrazione richiede un altro metodo di matching supportato o una regola personalizzata concordata. Un riferimento incrociato tra ID di origine e destinazione può preservare la relazione anche quando il target genera nuovi internal ID.

Importante: Conservare uno SKU non riconnette automaticamente un ERP, un sistema di magazzino o un feed marketplace. Verifica quale identificativo usa ogni integrazione e testa la connessione separatamente.

Dove devono andare i campi personalizzati?

Parti dallo scopo del campo, poi scegli la destinazione. Un’istruzione di cura è testo leggibile. Un codice fornitore è un identificativo. Un numero fiscale cliente può supportare un workflow aziendale. Inserire tutti e tre in un campo descrizione può preservare i caratteri, ma rende i dati più difficili da utilizzare.

Per ogni campo personalizzato, verifica quattro aspetti:

• Appartenenza: il campo appartiene a un prodotto, una variante, un cliente, un ordine o una riga d’ordine?
• Tipo: il target deve memorizzarlo come testo, numero, data, valore vero/falso o riferimento?
• Significato: unità, valori ammessi, valori vuoti e formattazione vengono interpretati in modo coerente?
• Utilizzo: quale theme, app, filtro o integrazione deve leggerlo?

Ad esempio, memorizza un codice fornitore come 00127 come identificativo, senza presumere che sia una quantità. In caso contrario, una conversione numerica potrebbe eliminare gli zeri iniziali. Se un campo sorgente contiene più valori, verifica se il target accetta una lista o richiede un’altra struttura supportata.

Un campo può anche migrare correttamente senza comparire nello storefront. Archiviazione, visualizzazione, filtri e comportamento delle app richiedono controlli separati. La nostra guida su metadata, campi personalizzati ed estensioni spiega queste differenze, mentre l’articolo su come strutturare campi personalizzati e workflow degli account ne mostra l’importanza nei negozi wholesale.

Prima di definire il design di un campo, condividi con Next-Cart un record normale e un caso difficile. Mostrare il valore sorgente insieme al risultato desiderato è molto più utile di una richiesta generica come “migrare tutti i campi personalizzati”.

Anche categorie, clienti e ordini hanno bisogno di mapping

Categorie: preserva il posizionamento e la navigazione prevista

Una giacca può appartenere sia a Outerwear sia a Winter Essentials. Decidi come queste appartenenze e qualsiasi struttura padre-figlio delle categorie devono apparire nel target. Verifica sia il posizionamento del prodotto sia l’esistenza di ogni categoria. Se il target organizza le collection in modo diverso, una regola esplicita è più utile del solo matching dei nomi categoria.

Clienti: proteggi identità e contesto aziendale

Email, indirizzo di fatturazione, identificativo fiscale e classificazione account di un cliente hanno finalità diverse. Concorda la policy di matching prima di unire i record. Lo stesso indirizzo email usato in più negozi non autorizza, da solo, la fusione dei relativi account business.

Per i clienti wholesale, anche un’etichetta di gruppo o un campo fiscale migrato deve essere validato rispetto alla configurazione account e prezzi del target. Memorizzare il valore non ricrea automaticamente il workflow che lo utilizzava.

Ordini: conserva il significato della transazione originale

Un ordine collega un cliente agli articoli acquistati, alle quantità, ai prezzi, alle imposte, agli sconti e ai dettagli di spedizione. I valori storici devono riflettere la transazione originale, non essere ricalcolati in modo invisibile sul catalogo attuale.

Prevedi ordini guest, prodotti eliminati e varianti fuori produzione. Quando non è possibile ricreare un collegamento a un prodotto attivo, definisci come conservare i dettagli storici supportati delle righe d’ordine. Testa l’ordine come farebbe il servizio clienti: riesci a capire cosa è stato acquistato e a ricostruire il totale?

Come validare il mapping prima del go-live?

Usa Demo Migration per controllare record rappresentativi, quindi ripeti i controlli pertinenti dopo Full Migration e dopo eventuali run aggiuntivi approvati. Se il campione della demo non include un edge case critico, pianifica ulteriori verifiche prima di considerare il requisito dimostrato.

Crea un piccolo set di test che includa volutamente record difficili:

• Un prodotto con più varianti, immagini diverse e campi personalizzati specifici delle varianti.
• Uno SKU mancante o duplicato e un identificativo con zeri iniziali.
• Un prodotto assegnato a più categorie e un cliente con campi business.
• Un ordine scontato, un ordine guest e un ordine contenente un articolo fuori produzione.

Per ogni esempio, registra valore sorgente, risultato atteso nel target, risultato effettivo ed eventuali discrepanze. Confronta tre livelli: numero di record, valori dei campi e relazioni. Spiega le differenze di conteggio dovute a filtri, unioni o ristrutturazioni approvate; non dare per scontato che totali uguali dimostrino correttezza.

Concludi con controlli di comportamento. Seleziona una variante, verifica le informazioni visualizzate, aggiungila al carrello e controlla l’articolo risultante. Esamina la cronologia ordini del cliente quando pertinente e testa le integrazioni che utilizzano identificativi migrati. Questi controlli collegano l’accuratezza del database alle attività quotidiane del negozio.

Prima dell’approvazione finale: risolvi le discrepanze critiche, ritesta i record interessati e conserva le regole di mapping approvate nelle note di progetto. Se le regole cambiano in seguito, verifica l’effetto sui dati già migrati prima di eseguire nuovamente la migrazione.

Quando il mapping richiede una Custom Migration?

La presenza di campi personalizzati non significa automaticamente che ogni progetto richieda sviluppo custom. La domanda decisiva è se il risultato richiesto rientra nel comportamento supportato del Migration Path selezionato e degli Add-ons applicabili.

Advanced Data Mapping di Next-Cart indirizza i campi sorgente supportati verso destinazioni compatibili. Data Transformation gestisce le modifiche di valore supportate. Campi e operazioni disponibili dipendono dalla migrazione attiva, quindi conferma il requisito esatto prima di scegliere un Add-on.

Standard Migration è adatta al lavoro supportato che preferisci gestire in autonomia. Managed Migration aggiunge l’esecuzione guidata da Next-Cart entro l’ambito supportato. Nessuna delle due deve essere interpretata come una promessa di riprodurre qualsiasi comportamento custom di app o database.

Custom Migration è adatta alla valutazione quando il progetto richiede estrazione non supportata, matching su misura, relazioni insolite o logica personalizzata. Ad esempio, unire più cataloghi sorgente con regole specifiche del business o spostare dati gestiti da un’app in una struttura target diversa.

Prepara record di esempio, risultato target desiderato, regole di matching e trasformazione, sistemi collegati e controlli di accettazione chiari. In questo modo il team dispone di una base concreta per valutare la fattibilità e definire il lavoro.

Dai al nuovo negozio una base dati chiara

Un buon mapping preserva il significato del catalogo e della cronologia clienti durante il cambio di piattaforma. Quando struttura prodotto, identificativi, campi personalizzati e relazioni delle transazioni vengono esaminati insieme, il team può individuare più facilmente i problemi e approvare il risultato.

Pronto a controllare i dati del tuo negozio? Richiedi una Demo con Next-Cart e porta record rappresentativi da esaminare. Per approfondire i sistemi che stanno dietro una migrazione, esplora i nostri articoli sulla Tecnologia eCommerce.