Se Magento Open Source viene scelto come piattaforma di destinazione, la preparazione deve tradurre lo store di origine in un modello documentato di catalogo, Customers, Orders, contenuti ed estensioni prima che inizi qualsiasi esecuzione della migrazione. La piattaforma è flessibile, ma proprio questa flessibilità rende ancora più importante distinguere tipi di Product, SKU figli dei configurable Products, custom options, attributi, attribute set, store view, inventory source, Orders storici, dati gestiti dalle estensioni e identificatori esterni.
Per ogni area di preparazione, definire azione, responsabile, evidenza e condizione di prontezza. In questo modo, il test di migrazione rappresentativo diventa un campione controllato della struttura Magento prevista invece del primo tentativo di capire come funziona lo store di origine.
Definire la struttura Magento Open Source di destinazione
Preparare una mappa sintetica della struttura di destinazione che copra website, store, store view, lingue, valute, responsabilità sul catalogo, Customer group, inventario, contenuti e integrazioni.
| Area di preparazione | Decisione da registrare | Responsabile | Evidenza di prontezza |
|---|---|---|---|
| Scope di website e store view | Quali brand, regioni, lingue, valute, domini e valori localizzati richiedono scope separati | Responsabile e-commerce | Matrice website/store/store view |
| Architettura Product | Quali record di origine diventano Products simple, configurable, grouped, bundle, virtual o downloadable | Responsabile catalogo | Classificazione delle famiglie Product |
| Governance degli attributi | Quali campi diventano attributi, attribute set, custom options, contenuti o dati esterni | Responsabili catalogo e tecnici | Dizionario attributi ed esempi di valori |
| Responsabilità sull’inventario | Se stock e disponibilità saranno gestiti da Magento, ERP, WMS, fornitore o marketplace | Responsabile inventario | Mappa source/stock/sistema di record |
| Customers e storico Orders | Quali Customer group, indirizzi, stati, rettifiche e riferimenti esterni devono restare comprensibili | Operazioni e assistenza | Pacchetto rappresentativo Customer/Order |
| Confini delle estensioni | Quali moduli e tabelle personalizzate creano record importanti | Responsabile tecnico | Registro delle dipendenze |
La mappa deve chiarire la responsabilità nella destinazione senza diventare una specifica completa dell’implementazione Magento.
Preparare accessi, backup ed evidenze della piattaforma di origine
Raccogliere:
- accesso amministrativo alla piattaforma di origine e accesso amministrativo a Magento con il livello di autorizzazione richiesto;
- backup di database e media, quando disponibili;
- export o report recenti di Products, Categories, Customers, Orders, coupon, recensioni, CMS Pages, Blog Posts e media;
- elenchi di website, store, store view, lingue, valute e domini;
- riferimenti su tipi di Product, attributi, attribute set, custom options e Categories;
- report relativi a inventory source, stock, magazzini e sistemi di inventario esterni;
- esempi di Customer group, fiscalità e stato degli account;
- inventari di estensioni, moduli personalizzati, cron, API e integrazioni;
- elenchi di URL rewrite, redirect, sitemap e percorsi ad alto valore;
- screenshot o report che spieghino comportamenti insoliti nella piattaforma di origine.
| Evidenza | Perché è necessaria | Condizione di prontezza |
|---|---|---|
| Backup database/media | Preserva record non esposti tramite export standard | Data del backup, posizione di archiviazione e responsabile del ripristino sono documentati |
| Dizionario attributi | Spiega campi personalizzati e differenze tra classi Product | Ogni attributo importante ha finalità, tipo, scope ed esempi di valori |
| Inventario delle estensioni | Identifica record al di fuori del core Magento | Ogni modulo critico ha un responsabile aziendale e uno tecnico |
| Inventario URL | Protegge la continuità dei percorsi | I percorsi prioritari di Product, Category e contenuti hanno destinazioni previste |
| Registro ID esterni | Protegge la continuità delle integrazioni | Le chiavi sono assegnate al livello corretto di Product, Customer, Order o inventario |
Un export mancante di un’estensione, una cartella media non accessibile o una tabella personalizzata non documentata devono restare visibili come elementi di preparazione ancora irrisolti.
Preparare tipi di Product e relazioni vendibili
Selezionare esempi per ogni struttura Product che influisce materialmente sulla gestione del catalogo o sullo storico Orders:
- simple Products;
- configurable Products con simple Products associati;
- grouped Products;
- bundle Products;
- Products virtual e downloadable;
- Products con custom options;
- Products assegnati a più website o con valori differenziati per store view;
- Products con campi gestiti da estensioni, tabelle personalizzate o ID esterni.
| Comportamento nella piattaforma di origine | Decisione di preparazione in Magento | Evidenza richiesta |
|---|---|---|
| La scelta crea uno SKU o un record stock indipendente | Definire configurable parent e simple Products associati | ID padre/figlio, SKU, attributi, stock, prezzi e immagini |
| I Products sono presentati insieme ma venduti indipendentemente | Definire una relazione grouped Product | Membri del gruppo e quantità |
| Il Customer compone un set | Definire componenti bundle e regole di selezione | Component Products, quantità, prezzi e responsabile dell’inventario |
| Il valore modifica un singolo Product senza stock indipendente | Definire una custom option o un altro responsabile | Tipo di opzione, valori, effetto sul prezzo ed esempio Order storico |
| Il Product è digitale o non viene spedito | Definire una struttura downloadable o virtual | File, accesso, spedizione e contesto Order |
| La piattaforma di origine usa Products duplicati per scope regionali | Definire responsabilità a livello di website/store view oppure Products separati intenzionalmente | Esempi regionali di contenuto, prezzo, URL e identificatore |
Normalizzare SKU duplicati, Products figli orfani, etichette delle opzioni incoerenti, collegamenti padre mancanti, Products obsoleti e combinazioni non supportate prima di finalizzare la mappatura.
Ripulire attributi e attribute set
Gli attributi Magento possono influire su modifica, filtri, ricerca, confronto, creazione dei Products e contenuti a livello di store view. Preparare un inventario governato dei campi invece di copiare ogni campo della piattaforma di origine in un unico attribute set sovradimensionato.
Per ogni campo, documentare:
- finalità aziendale;
- tipo di dato e valori consentiti;
- classi Product che lo utilizzano;
- scope globale, website o store view;
- se il Customer lo seleziona;
- se ricerca, filtri, confronto o integrazione dipendono da esso;
- se contiene l’identificatore di un altro record;
- se deve essere mantenuto, normalizzato, unito o escluso.
| Modello del campo | Responsabile previsto in Magento | Evidenza di prontezza |
|---|---|---|
| Valore che definisce una variante | Attributo configurable e simple Products associati | Valori controllati ed esempi delle famiglie Product |
| Specifica tecnica | Attributo Product assegnato tramite attribute set | Tipo, scope, valori consentiti e finalità di visualizzazione/ricerca |
| Valore inserito dal Customer | Custom option, estensione o responsabile della riga Order | Esempio nel sito pubblico e in un Order storico |
| Valore usato solo dalle integrazioni | Attributo Product o SKU figlio utilizzato da un sistema esterno | Responsabile del sistema esterno e regola di unicità |
| Soluzione legacy della piattaforma di origine | Attributo di destinazione normalizzato, contenuto, estensione o esclusione | Decisione documentata che spiega la finalità futura |
La condizione di prontezza è che ogni principale classe Product disponga di un attribute set approvato e che nessun campo importante resti indefinito o assegnato a più responsabili in conflitto.
Preparare Categories, contenuti, URL e valori delle store view
Preparare un inventario di percorsi e contenuti che includa:
- gerarchia Category e appartenenza dei Products;
- Categories utilizzate soltanto per organizzazione interna o campagne;
- URL key di Product e Category;
- CMS Pages, CMS Blocks, contenuti gestiti da Page Builder o dal tema;
- Blog Posts e contenuti gestiti da estensioni;
- valori Product, Category e CMS localizzati;
- backlink ad alto valore, percorsi di campagne a pagamento, pagine di policy e landing page;
- URL rewrite, redirect e link interni.
| Record di origine | Domanda di preparazione | Evidenza di prontezza |
|---|---|---|
| Category | È struttura di catalogo durevole, navigazione, raggruppamento di campagna o classificazione interna? | Decisione Category ed esempio di appartenenza Product |
| Product o pagina localizzata | Quale store view possiede ogni valore? | Matrice dei valori per store view |
| CMS Page/block | È contenuto riutilizzabile, contenuto di pagina o presentazione del tema? | Inventario contenuti e responsabile della destinazione |
| Blog Post | Quale estensione o sistema di contenuti lo gestirà? | Elenco post, media, URL e responsabile della destinazione |
| URL legacy | Quale Product, Category o record di contenuto della destinazione deve ricevere il redirect? | Registro dei percorsi origine/destinazione |
L’area è pronta quando ogni percorso pubblico prioritario ha una destinazione o una decisione di ritiro e ogni valore localizzato ha un responsabile assegnato a livello di store view.
Preparare Customer group, Customers e Orders storici
La preparazione dei Customers deve coprire Customers registrati, guest, più indirizzi, Customer group, trattamento fiscale, stato dell’account, identità duplicate, campi personalizzati e chiavi CRM o ERP esterne.
Per gli Orders, selezionare esempi con:
- configurable Products e custom options;
- grouped o bundle Products;
- sconti, coupon, imposte, etichette di spedizione e pagamento;
- invoice, shipment, credit memo, cancellazioni e commenti;
- riferimenti marketplace, ERP, evasione degli ordini, contabilità o CRM;
- ogni website, valuta o Customer group importante.
| Elemento di preparazione | Responsabile | Evidenza richiesta | Condizione di prontezza |
|---|---|---|---|
| Identità Customer | Operazioni Customer | Esempi di duplicati, guest, indirizzi e ID esterni | Le regole di unione e mantenimento separato sono documentate |
| Customer group | Responsabile commerciale | Elenco gruppi e relativa finalità per prezzi/fiscalità/accesso | Ogni gruppo mantiene un significato aziendale futuro |
| Orders storici | Assistenza e finanza | Pacchetto Order rappresentativo | Righe, totali, stati, evasione, rimborsi e riferimenti sono spiegati |
| Dati sensibili | Responsabile legale/dati | Elenco campi approvati | I dati personali non necessari o non supportati sono esclusi |
Non usare i Customer group correnti o i prezzi Product correnti per reinterpretare gli Orders storici. Il record Order deve preservare le proprie evidenze relative al momento della transazione.
Preparare la responsabilità su inventario ed evasione degli ordini
L’inventario Magento può coinvolgere sources, stocks, assegnazioni website, quantità per source, salable quantity, reservation, backorder, punti di ritiro, drop shipper e sistemi esterni di inventario.
Preparare esempi per:
- SKU simple e figli di configurable Products;
- Products single-source e multi-source;
- record in backorder, low stock, out of stock o simili a preorder;
- ubicazioni di magazzino, store, fornitori e drop-ship;
- Products sincronizzati con ERP, WMS, marketplace o sistemi di evasione degli ordini;
- stock da aggiornare vicino alla finestra di migrazione.
| Domanda sull’inventario | Evidenza | Condizione di prontezza |
|---|---|---|
| Quale sistema controlla la quantità? | Mappa del sistema di record | Ogni SKU prioritario ha una sola autorità dichiarata sull’inventario |
| Quale ubicazione di origine corrisponde a quale source Magento? | Matrice delle ubicazioni | I codici source di origine e destinazione sono documentati |
| Quali website utilizzano ciascuno stock? | Relazione website/stock | La responsabilità per canale di vendita è definita |
| Quale livello Product gestisce l’inventario? | Esempi di SKU padre/figlio | Le responsabilità tra configurable parent e figli sono chiare |
| Quali valori sono snapshot iniziali? | Report stock datato | Data dello snapshot e responsabile dell’aggiornamento sono registrati |
L’inventario è pronto quando quantità, ubicazione, livello Product, relazione con il website e responsabilità del sistema esterno sono tutti espliciti.
Inventariare estensioni, moduli personalizzati e sistemi esterni
Creare un registro delle dipendenze per ogni estensione, modulo personalizzato, tabella modificata, API, processo pianificato e sistema esterno che modifica il comportamento di Product, Customer, Order, inventario, contenuti o URL.
Registrare:
- nome del modulo o sistema;
- finalità aziendale;
- record core estesi;
- campi, tabelle, stati o ID personalizzati creati;
- disponibilità di export o API;
- responsabile aziendale e tecnico;
- responsabile futuro nella destinazione o soluzione sostitutiva;
- dati da archiviare o escludere.
Le dipendenze prioritarie includono ricerca, recensioni, loyalty, abbonamenti, pagamenti, imposte, spedizione, marketplace, ERP, PIM, WMS, CRM, contabilità, consenso, strumenti di analisi e logiche personalizzate di checkout o evasione degli ordini.
Il registro è pronto quando ogni dipendenza importante dispone di un responsabile nominato nella destinazione e di una chiave stabile. Non descrivere record delle estensioni come normali campi Magento se il core della piattaforma non li possiede realmente.
Selezionare campioni rappresentativi per il test di migrazione
| Campione | Finalità della preparazione |
|---|---|
| Famiglia Product simple e configurable | Verificare tipo di Product, attributi, SKU figli, media e inventario |
| Grouped o bundle Product | Esporre relazioni tra componenti e responsabilità sul prezzi |
| Product con custom options | Esporre input Customer una tantum e rappresentazione negli Orders storici |
| Product o Category localizzata | Esporre scope di website, store view, contenuti e URL |
| Customer con gruppo e ID esterno | Esporre relazioni di identità, segmentazione e integrazione |
| Order storico complesso | Esporre opzioni, totali, shipment, credit memo e riferimenti |
| SKU con inventario multi-source | Esporre responsabilità tra source, stock, website e sistema esterno |
| Record gestito da un’estensione | Esporre decisioni su tabelle personalizzate e responsabile della destinazione |
Per ogni campione, registrare ID di origine, URL di origine quando pertinente, motivazione aziendale, responsabile Magento previsto, identificatori esterni correlati, esclusioni note e revisore responsabile. Il registro dei campioni è pronto quando ogni record selezionato ha un’aspettativa tracciabile sulla piattaforma di origine e un revisore nominato.
Completare il gate di prontezza per Magento Open Source
| Domanda di prontezza | Evidenza richiesta | Condizione di prontezza |
|---|---|---|
| Accessi e archivi della piattaforma di origine sono recuperabili? | Registro degli accessi, backup database, backup media ed export | I record richiesti possono essere verificati indipendentemente dallo store di origine live |
| Famiglie Product e attribute set sono definiti? | Matrice Product/attributi | Ogni principale modello di catalogo ha una struttura Magento prevista |
| Categories, contenuti e URL sono assegnati? | Registro contenuti e percorsi | I record prioritari hanno destinazioni o decisioni di ritiro |
| Il significato di Customers e Orders è documentato? | Pacchetto di evidenze Customer/Order | Identità, stato e relazioni storiche sono spiegati |
| La responsabilità sull’inventario è esplicita? | Mappa source/stock/sistema di record | Ogni SKU prioritario ha un responsabile dichiarato per la quantità |
| Estensioni e sistemi esterni sono inventariati? | Registro delle dipendenze | Ogni dipendenza critica ha un responsabile futuro |
| Sono stati selezionati campioni rappresentativi? | Registro dei campioni | Sono coperti modelli ordinari ed eccezionali |
| Gli elementi irrisolti sono controllati? | Registro delle decisioni | Ogni punto aperto ha un responsabile e una scadenza |
Il gate di preparazione è completo quando nessuna decisione critica relativa a Product, attributi, Customers, Orders, inventario, URL o estensioni dipende da ipotesi non documentate.
Conclusione
La preparazione a una migrazione verso Magento Open Source deve creare un pacchetto di evidenze recuperabile e specifico per la piattaforma. Tipi di Product, attribute set, Categories, store view, inventory source, Customer group, Orders storici, estensioni, contenuti, URL e ID esterni richiedono tutti responsabili espliciti.
Quando queste decisioni sono documentate prima del test di migrazione rappresentativo, i record campione possono rappresentare l’architettura Magento prevista invece di costringere il team a dedurla dai dati importati.
Domande frequenti
Quale documento di preparazione per Magento Open Source dovrebbe essere creato per primo?
Creare la mappa della struttura di destinazione per website, store view, tipi di Product, attributi, inventario, Customers, Orders, contenuti e integrazioni. Questa mappa determina le evidenze necessarie per il resto della checklist.
Perché i campioni Product sono più importanti dei conteggi dei Products?
I conteggi non mostrano relazioni tra figli configurable, componenti bundle, custom options, valori localizzati o campi gestiti dalle estensioni. Famiglie Product rappresentative espongono le strutture che la destinazione deve supportare.
Ogni campo della piattaforma di origine dovrebbe diventare un attributo Magento?
No. Un valore può appartenere a una variante, una custom option, un campo di contenuto, un’estensione, un sistema esterno o un’esclusione deliberata. Assegnare il campo in base alla sua finalità aziendale e a chi continuerà a utilizzarlo.
Come devono essere preparati gli attribute set?
Raggruppare i Products in base alle reali esigenze di gestione, definire gli attributi richiesti da ciascun gruppo, normalizzare i valori controllati, documentare lo scope e rimuovere campi obsoleti o duplicati.
Quando l’inventario dovrebbe essere preparato separatamente dai dati di catalogo?
Prepararlo separatamente quando lo stock dipende da sources, stocks, website, SKU figli dei configurable Products, backorder, reservation oppure da un ERP, WMS, marketplace o feed di fornitori esterno.
Cosa dovrebbe accadere ai dati delle estensioni o dei moduli personalizzati?
Identificare modulo, record core, finalità aziendale, tabelle o campi, identificatori esterni e responsabile futuro nella destinazione. I record importanti devono avere una destinazione esplicita; quelli obsoleti possono essere archiviati o esclusi.