Se Shopify viene scelto come piattaforma di destinazione, la preparazione deve trasformare lo store di origine in un insieme di decisioni chiare e supportate da evidenze prima che inizi qualsiasi esecuzione della migrazione. Lo scopo non è riprogettare in anticipo l’intera vetrina online, ma stabilire come Products, varianti, collezioni, Customers, Orders, contenuti, URL, app, metafield, metaobject, Markets e identificatori esterni importanti dovranno essere rappresentati in Shopify.
Un pacchetto di preparazione utile risponde a quattro domande per ogni area dati importante: che cosa deve essere fornito, chi possiede la decisione, quali evidenze la supportano e quale condizione rende l’area pronta. Questo evita che il test di migrazione rappresentativo sia il primo momento in cui il team scopre che un’opzione di origine è in realtà un input Product personalizzato, una Category è una pagina di campagna o un Customer Group dipende da un sistema wholesale esterno.
Definire le decisioni sulla destinazione Shopify
Prima di raccogliere file, definire le strutture Shopify che riceveranno le principali relazioni di origine. Il registro delle decisioni deve identificare il responsabile Shopify previsto per ogni relazione significativa.
| Area di preparazione | Decisione da registrare | Responsabile | Evidenza di preparazione |
|---|---|---|---|
| Struttura Product | Quali record di origine diventano Products, varianti, metafield, metaobject, tag o record gestiti da app | Responsabile del catalogo | Esempi di mappatura approvati per ogni principale famiglia Product |
| Organizzazione del catalogo | Quali Categories di origine diventano collezioni manuali o automatiche, collegamenti di navigazione, filtri, landing page o redirect | Responsabili di merchandising e contenuti | Schema di collezioni e navigazione con percorsi di origine rappresentativi |
| Continuità Customer | Quali relazioni di account, tag, imposte, wholesale, loyalty, abbonamento o CRM esterno devono restare utilizzabili | Operazioni Customer | Inventario delle relazioni Customer e piano di comunicazione per l’accesso agli account |
| Storico Orders | Quali stati Order, dettagli delle righe, rimborsi, note e riferimenti esterni devono restare disponibili al personale | Operazioni e assistenza | Elenco di Orders storici campione e note sul significato dei campi |
| Struttura internazionale | Quali paesi, lingue, valute, domini, sottocartelle, contenuti localizzati e record specifici per mercato sono rilevanti | Responsabile internazionale | Matrice di Markets e domini |
| Dati personalizzati | Quali campi personalizzati di origine diventano metafield Shopify, metaobject, record app, contenuti o esclusioni | Responsabili catalogo e tecnici | Inventario dei campi con responsabile di destinazione e sistema utilizzatore continuativo |
Non usare il numero dei record come principale segnale di preparazione. I conteggi descrivono il volume, ma non determinano se un’opzione di origine debba diventare una variante Shopify, se un bundle resti una relazione gestita da app o se un catalogo regionale richieda decisioni separate su Market e contenuti Shopify.
Preparare accessi allo store ed evidenze di origine
Preparare gli accessi allo store di origine e a Shopify necessari per recuperare, interpretare e preservare i record inclusi nell’ambito. Il pacchetto deve poter essere utilizzato anche da chi non ha configurato lo store di origine e non deve dipendere da conoscenze non documentate del personale.
Raccogliere:
- accesso amministratore allo store di origine e allo store Shopify con il livello di autorizzazioni necessario;
- esportazioni o report recenti per Products, Customers, Orders, Categories, contenuti, Reviews, sconti e altri record inclusi nell’ambito;
- file media Product quando gli URL di origine sono temporanei, protetti o inaffidabili;
- elenchi correnti di domini, sottodomini, cartelle lingua e URL regionali;
- inventari di app e integrazioni, inclusi responsabile aziendale e responsabile del sistema esterno;
- definizioni dei campi di origine per attributi personalizzati, set di opzioni, regole di gruppo e identificatori esterni;
- esempi di record che il personale considera commercialmente critici o particolarmente complessi;
- un’istantanea datata della piattaforma di origine e una nota che identifichi i dati che possono ancora cambiare prima della finestra di migrazione.
| Evidenza | Perché è necessaria | Condizione di preparazione |
|---|---|---|
| Accesso alla piattaforma di origine | Permette di verificare il significato dei dati nel contesto amministrativo reale | L’accesso funziona e le aree dati necessarie sono visibili |
| Accesso a Shopify | Permette di confermare impostazioni della destinazione e responsabilità sui record | Le autorizzazioni richieste sono disponibili senza condivisione informale di credenziali personali |
| Archivio delle esportazioni | Conserva una copia di riferimento dello stato di origine | I file si aprono correttamente, includono i record attesi e riportano una data di esportazione |
| Dizionario dei campi personalizzati | Spiega etichette che altrimenti sarebbero ambigue | Ogni campo importante ha scopo, responsabile e valore campione |
| Elenco degli ID esterni | Protegge la continuità con ERP, PIM, CRM, WMS, marketplace o contabilità | Ogni identificatore è collegato al corretto livello Product, variante, Customer o Order |
Se un’esportazione omette record importanti gestiti da applicazioni, documentare il limite invece di presumere che tali record non esistano. Un’app senza possibilità di esportazione, una fonte media protetta o una tabella personalizzata non documentata rappresentano problemi di preparazione che richiedono un responsabile.
Preparare Products, varianti e dati personalizzati del catalogo
La preparazione dei Products per Shopify deve distinguere combinazioni realmente vendibili da informazioni descrittive, valori inseriti dagli acquirenti, relazioni di merchandising e dati dei sistemi esterni.
Creare un inventario delle famiglie Product che includa:
- Products semplici con una sola configurazione vendibile;
- Products con più opzioni e differenze di SKU, codice a barre, prezzo, inventario, peso, immagine, imposte o evasione a livello variante;
- Products le cui combinazioni di opzioni di origine devono essere consolidate, separate o ritirate;
- bundle, kit, abbonamenti, preorder, garanzie e altri comportamenti legati alle opzioni di acquisto;
- Products personalizzati che raccolgono testo, file, date, misure o scelte condizionali;
- Products con specifiche tecniche, tabelle di compatibilità, guide alle taglie, documenti o dati di riferimento strutturati;
- Products il cui contenuto o la cui disponibilità cambia per regione, canale o tipo Customer;
- Products sincronizzati con ERP, PIM, magazzino, marketplace o feed fornitori.
Per ogni famiglia, preparare un esempio di mappatura:
| Comportamento di origine | Decisione di preparazione in Shopify | Evidenza da allegare |
|---|---|---|
| La scelta crea uno SKU o un’unità di stock distinta | Definire la relazione Product-variante prevista | ID padre/figlio di origine, valori delle opzioni, SKU, inventario, prezzo e immagini di esempio |
| Il valore descrive il Product | Definire metafield, metaobject, contenuto Product o altra destinazione strutturata | Scopo del campo, tipo di valore, valori ammessi e responsabile della visualizzazione |
| Il Customer inserisce un valore una tantum | Identificare input Product, app o relazione della riga Order che lo gestirà | Esempio nella vetrina online e riga Order storica |
| Il Product è un bundle, abbonamento o insieme configurabile | Identificare applicazione o struttura di destinazione che gestisce il comportamento | Elenco componenti, logica di prezzo, responsabile dell’inventario e Orders campione |
| Il valore è usato soltanto da un sistema esterno | Preservarlo al corretto livello Product o variante | Nome del sistema esterno, regola di unicità ed esempio di ricerca |
Normalizzare i nomi di opzioni e attributi prima che diventino strutture Shopify. Decidere se “Colour”, “Color” e “Finish” rappresentano un unico concetto controllato o concetti intenzionalmente diversi. Rimuovere valori obsoleti, incoerenti o creati soltanto per aggirare limiti della piattaforma di origine.
Preparare collezioni, navigazione, Markets, contenuti e URL
Le Categories di origine raramente corrispondono uno a uno alle collezioni Shopify. Preparare una classificazione di ogni raggruppamento e percorso importante.
| Struttura di origine | Domanda di preparazione | Evidenza di preparazione |
|---|---|---|
| Category permanente | Deve diventare una collezione manuale, automatica o un’altra destinazione? | Regola della collezione o esempio di appartenenza Product |
| Raggruppamento usato soltanto nel menu | Appartiene alla navigazione invece che alla classificazione del catalogo? | Gerarchia dei menu prevista e relativi collegamenti |
| Gruppo stagionale o di campagna | È una collezione temporanea, landing page, promozione o route da ritirare? | Responsabile della campagna e decisione di mantenimento/ritiro |
| Valore di filtro | Deve usare categoria Product, valori delle opzioni, metafield o dati di ricerca gestiti da app? | Elenco controllato dei valori e responsabile dei filtri |
| Percorso regionale | Quale Market, dominio, lingua, valuta e relazione con contenuti localizzati si applica? | Matrice di Markets e URL |
Preparare un inventario di Products, collezioni, CMS Pages, Blog Posts, pagine di policy, guide e pagine di campagne attive. Per ogni route prioritaria, registrare URL di origine, destinazione Shopify prevista, responsabile dei contenuti, requisito di localizzazione e necessità di redirect.
Includere:
- URL Product ad alto traffico e ad alto fatturato;
- landing page Category e brand con backlink o valore per campagne a pagamento;
- CMS Pages e Blog Posts che supportano fiducia, SEO o assistenza Customer;
- percorsi localizzati o regionali;
- route di Products ritirati che necessitano di una sostituzione pertinente;
- link interni incorporati in descrizioni, Blog Posts, pagine e navigazione;
- file, documenti e immagini richiamati dai contenuti di origine.
La condizione di preparazione non è “tutti gli URL sono stati esportati”. È che ogni percorso di origine prioritario disponga di una destinazione Shopify definita o di una decisione intenzionale di ritiro.
Preparare Customers, account e Orders storici
La preparazione dei Customers deve distinguere l’identità dalle applicazioni e dalle regole collegate a quell’identità. Preparare campioni per Customers registrati, acquirenti senza account, indirizzi multipli, trattamento fiscale, tag o gruppi, relazioni B2B, loyalty, abbonamenti, membership e riferimenti CRM esterni.
Non presumere che le credenziali di autenticazione di origine possano essere riutilizzate in Shopify. Preparare l’approccio di comunicazione e accesso account che l’azienda utilizzerà quando i Customers migrati dovranno accedere al nuovo store.
Per gli Orders, preparare esempi che espongano la complessità storica:
- Orders pagati, in attesa, annullati, rimborsati e parzialmente rimborsati;
- Orders parzialmente evasi o con più spedizioni;
- Orders con sconti, gift card, credito store, imposte, dazi, rettifiche di spedizione o modifiche manuali;
- Orders con input Product personalizzati, bundle, abbonamenti o dati di riga gestiti da applicazioni;
- Orders collegati a marketplace, ERP, contabilità, evasione, assistenza o CRM;
- Orders provenienti da ciascun Market, valuta o vetrina online prioritari.
| Voce di preparazione | Responsabile | Evidenza richiesta | Condizione di preparazione |
|---|---|---|---|
| Regole di identità Customer | Operazioni Customer | Esempi di account duplicati e ID esterni | Regole di unione, mantenimento separato e gestione senza account documentate |
| Accesso account | Esperienza Customer | Bozza di comunicazione e team responsabile | Il personale sa come i Customers ricorrenti riacquisteranno l’accesso |
| Classificazioni Customer | Responsabile B2B, imposte, loyalty o CRM | Esempi di gruppi/tag e relativa regola aziendale | È definito il responsabile di destinazione di ogni classificazione |
| Significato degli Orders storici | Assistenza e finanza | Pacchetto di Orders rappresentativi | Righe, rettifiche, stati, rimborsi e riferimenti sono spiegati |
| Ambito dei dati sensibili | Responsabile legale o dei dati | Elenco campi approvato | Dati personali non necessari o non supportati sono esclusi |
Inventariare app, integrazioni e dipendenze esterne
Creare un unico registro delle dipendenze per ogni app, estensione di origine, script, gruppo di campi personalizzati, automazione, webhook e sistema esterno che modifica Products, Customers, Orders, prezzi, contenuti o funzionamento dell’evasione.
Per ogni dipendenza, registrare:
- scopo aziendale;
- tipi di record creati o modificati;
- record padre Shopify o di origine coinvolti;
- responsabile dei dati e responsabile tecnico;
- disponibilità di esportazione o API;
- identificatori esterni usati per la riconciliazione;
- se la dipendenza continuerà, verrà sostituita o ritirata;
- dati che devono esistere prima di poter configurare il sostituto.
Le dipendenze prioritarie comprendono spesso Reviews, ricerca e filtri, abbonamenti, bundle, loyalty, B2B, personalizzazione Product, imposte, spedizioni, pagamenti, listing marketplace, ERP, PIM, WMS, CRM, contabilità, strumenti di analisi e sistemi per il consenso.
Il registro è pronto quando ogni dipendenza commercialmente importante dispone di un responsabile definito nella destinazione. “Se ne occupava l’app” non costituisce un’evidenza sufficiente.
Selezionare campioni rappresentativi per il test di migrazione
L’insieme di campioni rappresentativi deve rendere visibili le principali decisioni di preparazione Shopify senza tentare di rappresentare l’intero catalogo. Selezionare i record intenzionalmente e allegare le note sulla responsabilità prevista.
| Campione | Scopo della preparazione |
|---|---|
| Product semplice | Stabilire il normale modello Product, collezione, immagine e inventario |
| Product con molte varianti | Esporre denominazione delle opzioni, identità variante, immagini, stock e ID esterni |
| Product con contenuti strutturati | Esporre requisiti per metafield o metaobject |
| Product personalizzato o dipendente da app | Esporre input Customer o responsabilità applicativa |
| Collezione e URL prioritari | Esporre decisioni su raggruppamento, navigazione, contenuti e redirect |
| Customer complesso | Esporre indirizzi, classificazioni, ID esterni e pianificazione dell’accesso account |
| Order storico complesso | Esporre dettagli di riga, sconti, evasione, rimborsi e riferimenti esterni |
| Record localizzato o specifico per Market | Esporre lingua, dominio, valuta e ambito dei contenuti regionali |
Per ogni campione, fornire ID del record di origine, URL di origine quando pertinente, motivo aziendale della selezione, responsabile Shopify previsto, ID esterni correlati ed esclusioni note. Il registro è pronto quando ogni record selezionato ha aspettativa di origine, identificatori correlati, esclusioni note e un responsabile della revisione.
Completare la verifica di preparazione per Shopify
Utilizzare una verifica finale prima di programmare l’esecuzione della migrazione.
| Domanda di preparazione | Evidenza richiesta | Condizione di preparazione |
|---|---|---|
| Gli accessi necessari sono disponibili? | Registro accessi e contatti responsabili | Le aree richieste della piattaforma di origine e di Shopify sono accessibili |
| Le famiglie Product sono classificate? | Matrice delle famiglie Product | Ogni modello Product importante ha un responsabile nella destinazione |
| Le decisioni su collezioni e URL sono complete? | Inventario delle route e schema delle collezioni | I percorsi prioritari hanno una destinazione o una decisione di ritiro |
| I campioni Customer e Order sono spiegati? | Pacchetto di evidenze Customer e Order | Le relazioni storiche e account sono documentate |
| App e sistemi esterni sono inventariati? | Registro delle dipendenze | Ogni dipendenza importante ha un responsabile continuativo |
| Backup ed esportazioni di origine sono aggiornati? | Archivio datato e checksum o elenco file | Le evidenze di origine possono essere recuperate indipendentemente dallo store live |
| I campioni rappresentativi sono selezionati? | Registro dei campioni | L’insieme copre record ordinari ed eccezionali |
| Gli elementi irrisolti hanno un responsabile? | Registro delle decisioni | Ogni elemento aperto ha un responsabile e una scadenza |
La migrazione è pronta per essere pianificata quando nessuna decisione critica su Product, Customer, Order, URL o integrazione dipende da ipotesi non documentate. La revisione finale deve inoltre confermare che il pacchetto di evidenze sia comprensibile anche fuori dal team che ha costruito lo store di origine. Se una decisione dipende dal ricordo di una sola persona su come funzionava una vecchia app o un campo, documentare quella conoscenza prima di programmare l’esecuzione.
Conclusione
La preparazione per Shopify deve produrre un pacchetto di evidenze pratico, non una checklist generica. Products e varianti hanno bisogno di responsabilità definite, le collezioni devono essere separate da navigazione e URL, l’identità Customer deve essere distinta dal comportamento di account e applicazioni, gli Orders storici richiedono evidenze rappresentative e ogni app o identificatore esterno deve avere un responsabile continuativo.
Quando queste decisioni vengono documentate prima del test di migrazione rappresentativo, il team può valutare la rappresentazione Shopify prevista invece di scoprire il modello della destinazione osservando singoli record già migrati.
Domande frequenti
Quale documento di preparazione Shopify va creato per primo?
Iniziare dalla mappa delle decisioni della destinazione per Products, collezioni, Customers, Orders, contenuti, Markets, app e sistemi esterni. Questa mappa determina quali esportazioni, campioni e responsabili sono necessari per il resto del pacchetto.
Quanti Products devono essere selezionati per preparare un test di migrazione rappresentativo?
Usare il più piccolo insieme in grado di coprire ogni modello Product importante: semplice, con molte varianti, con contenuti strutturati, personalizzato, bundle o abbonamento, localizzato e sincronizzato con sistemi esterni. La copertura dei comportamenti conta più di un numero fisso.
Tutti i campi personalizzati di origine devono diventare metafield Shopify?
No. Alcuni valori appartengono a metafield o metaobject, altri a contenuti Product, varianti, app, sistemi esterni o esclusioni intenzionali. Classificare il campo in base a scopo e sistema che continuerà a utilizzarlo prima di scegliere la destinazione.
Quali informazioni degli account Customer richiedono preparazione specifica?
Preparare regole di identità, gestione degli account duplicati, esempi di indirizzi, classificazioni Customer, ID esterni e approccio di comunicazione per i Customers ricorrenti. Non presumere che le credenziali di login della piattaforma di origine possano essere semplicemente riutilizzate.
Che cosa deve includere l’inventario URL di Shopify?
Includere route prioritarie per Products, equivalenti delle collezioni, CMS Pages, Blog Posts, policy, campagne, contenuti localizzati e collegamenti esterni. Ciascuna deve avere una destinazione Shopify prevista o una decisione esplicita di ritiro.
Quando è completa la verifica di preparazione per Shopify?
Quando gli accessi richiesti funzionano, le evidenze di origine sono recuperabili, i record importanti hanno responsabili documentati nella destinazione, i campioni rappresentativi coprono la complessità reale e ogni elemento irrisolto ha un responsabile definito.