Pianificare una migrazione verso Adobe Commerce non significa soltanto verificare se Products, Customers, Orders, Categories, CMS Pages, Blog Posts e Reviews possano essere trasferiti. La domanda più importante è se quei record possano sostenere il modello operativo enterprise che Adobe Commerce dovrà gestire dopo il lancio. Struttura Product, ambito delle vetrine, relazioni Company B2B, shared catalogs, Customer Groups, Content Staging, proprietà dell’inventario, URL e integrazioni cambiano il modo in cui i dati di origine devono essere interpretati.
Uno store di origine può contenere record apparentemente ordinati ma non avere la struttura necessaria per Adobe Commerce. Un Customer può esistere senza l’autorità della Company. Un Product può esistere senza il corretto attribute set, assegnazione website, relazione con child SKU o visibilità shared catalog. Una pagina può migrare ma perdere tempistica di campagna, localizzazione o significato del percorso URL. La revisione del modello dati deve quindi concentrarsi sul funzionamento aziendale, non soltanto sulla presenza dei campi.
Il significato dei dati in Adobe Commerce parte dalle operazioni enterprise
Adobe Commerce eredita gran parte della base dati Magento, ma l’interpretazione della migrazione cambia perché viene spesso scelto per operazioni e-commerce più governate. Lo stesso record Product, Customer, Order o pagina può dover partecipare a una struttura multi-vetrina, acquisti B2B, regole di approvazione, prezzi per Customer Group, visibilità shared catalog, integrazioni enterprise o attività di contenuto programmato.
| Area dati | Interpretazione in Adobe Commerce | Implicazione per la pianificazione |
|---|---|---|
| Products | Tipi Product, child SKU, attributi, attribute set, website, Categories, prezzi, visibilità e relazioni di inventario. | I dati catalogo devono sostenere il comportamento di vendita enterprise, non solo la visualizzazione. |
| Customers | Acquirenti individuali, Customer Groups, utenti Company, indirizzi, storico Orders e autorità dell’account. | I dati Customer possono dover mantenere sia identità sia contesto di acquisto. |
| Companies | Amministratori, utenti, ruoli, permessi, credito, quote, purchase order e stato di approvazione. | I dati B2B devono essere definiti prima di trattare i Customers come account ordinari. |
| Shared catalogs | Visibilità e prezzi specifici per acquirente tramite Customer Groups o assegnazione Company. | L’esistenza di un Product non implica automaticamente visibilità per ogngli acquirenti. |
| Ambito delle vetrine | Website, store, store view, lingua, valuta, contenuti, configurazione e assegnazione catalogo. | Dati multi-brand, regionali o multilingua non devono essere appiattiti. |
| Contenuti e campagne | CMS Pages, CMS Blocks, aggiornamenti programmati, tempistiche promozionali, landing page e asset di campagna. | La migrazione statica dei contenuti può non mantenere l’intento commerciale legato al tempo. |
| Inventario | Sources, stocks, presupposti di salability, assegnazione ai canali e proprietà esterna delle scorte. | La quantità va valutata rispetto alla struttura di evasione degli ordini, non solo al conteggio SKU. |
| URL | URL key, rewrite, redirect, percorsi localizzati, route personalizzate e landing page ad alto valore. | La continuità SEO dipende dal significato del percorso e dall’ambito, non solo dal trasferimento della pagina. |
La domanda pratica è se ogni record abbia struttura sufficiente per continuare a funzionare dentro Adobe Commerce. Anche un record supportato può richiedere una relazione di destinazione diversa, un’assegnazione di ambito, una decisione di proprietà o un confine di implementazione specifico quando porta con sé regole aziendali enterprise.
I dati Product dipendono da tipo, attributi e logica di governance
La migrazione Product richiede un’interpretazione attenta perché i dati possono influire su comportamento della vetrina, merchandising, filtri, ricerca, prezzi, inventario e integrazioni. Il tipo Product è il primo livello di significato. Simple, configurable, grouped, virtual, bundle e downloadable Products non si comportano allo stesso modo. Un articolo di origine con opzioni può dover diventare un configurable Product con simple Products figli associati. Un pacchetto o kit può richiedere revisione prima di essere classificato come bundle, grouped, personalizzato o fuori dallo standard.
I configurable Products sono particolarmente sensibili. Il Product padre offre un’unica esperienza all’acquirente, mentre i simple Products figli conservano il significato acquistabile a livello SKU. Taglia, colore, materiale, formato confezione o specifica tecnica possono influenzare identità SKU, prezzo, immagine, inventario e riferimenti di integrazione. Se queste relazioni vengono appiattite, il catalogo può sembrare completo mentre acquisto, evasione degli ordini, reporting o sincronizzazione ERP falliscono.
Attributi e attribute set aggiungono un ulteriore livello di governance. Gli attributi possono controllare campi visibili, ricerca, layered navigation, confronto, import/export, condizioni promozionali, manutenzione amministrativa e logiche di integrazione. Gli attribute set raggruppano famiglie Product in modelli strutturati. Un campo personalizzato di origine non dovrebbe diventare automaticamente testo descrittivo se guida filtri, prezzi, sincronizzazione PIM, ricerca, reporting o operazioni successive.
| Struttura Product | Cosa deve essere interpretato | Perché conta in Adobe Commerce |
|---|---|---|
| Tipo Product | Simple, configurable, grouped, bundle, virtual, downloadable o trattamento personalizzato. | Il tipo controlla come l’acquirente seleziona e compra. |
| Relazione child SKU | Associazione padre-figlio, etichette opzioni, immagini, differenze di prezzo, stock e identificatori. | Relazioni errate possono rendere Products visibili ma inutilizzabili commercialmente. |
| Attributi | Campi di visualizzazione, ricerca, filtro, input per regole, ID integrazione e campi admin. | Le decisioni sugli attributi influenzano governance e ambitorta del catalogo. |
| Attribute set | Modelli per famiglie Product e campi richiesti. | Una pianificazione scadente rende difficile la manutenzione post-migrazione. |
| Assegnazione Category | Navigazione, merchandising, ambito, visibilità e comportamento URL. | Un significato Category errato può danneggiare ambitorta, SEO e fiducia. |
| Relazioni Product | Related Products, upsell, cross-sell, accessori, sostituzioni e compatibilità. | La perdita di relazioni può indebolire conversione e flussi di vendita. |
L’obiettivo non è ricreare ogni campo di origine alla lettera, ma mantenere il significato commerciale in una forma che Adobe Commerce possa gestire e governare senza trasformare la piattaforma di destinazione in un archivio del sistema precedente.
L’ambito delle vetrine cambia il significato dei record
In Adobe Commerce l’ambito può cambiare il significato di quasi ogni record migrato. Una piattaforma di origine può rappresentare brand, regioni, lingue, portali B2B, canali retail, aree wholesale e vetrine internazionali tramite Categories, domini, tag Customer, mercati, plugin o campi personalizzati. Adobe Commerce può richiedere che tali distinzioni diventino website, store, store view, alberi Category, Customer Groups, shared catalogs, regole di configurazione o varianti di contenuto.
L’ambito va pianificato prima del mappatura dettagliato. Un nome Product può essere globale mentre le descrizioni variano per store view. Una CMS Page può richiedere versioni localizzate. Un Product può appartenere a un website e non a un altro. Un percorso Category può essere valido per una vetrina retail ma inadatto a un catalogo B2B privato. Un prezzo può dipendere dal Customer Group o dall’accesso allo shared catalog anziché dal Product in sé.
Gli errori di ambito spesso non emergono dai conteggi. Può migrare il numero previsto di Products, Categories, Customers o pagine mentre una vetrina riceve lingua, prezzo, Category, visibilità o contesto URL sbagliati. Il modello di destinazione deve quindi assegnare esplicitamente brand, regione, lingua, website, store, store view, segmento B2B e contesto di catalogo privato.
I dati Customer possono includere identità individuale e autorità Company
In Adobe Commerce i dati Customer possono rappresentare più della sola identità account. Possono includere Customer Groups, relazioni Company, Company administrator, Company users, permessi, quote, purchase order, Company Credit, metodi di pagamento, regole sui metodi di spedizione, indirizzi legali e assegnazione shared catalog. Un Customer può trasferirsi correttamente come account individuale ma risultare comunque inutilizzabile se perde autorità Company o accesso al catalogo.
La pianificazione B2B deve separare l’identità Customer dal controllo dell’acquisto. Adobe Commerce associa account Customer standard a Company, e una Company può contenere amministratore, team, utenti, ruoli, permessi e relazioni di approvazione. Email, indirizzo e storico Orders possono bastare per un account B2C, mentre la continuità B2B può richiedere identità Company, indirizzo legale, assegnazione dell’amministratore, gerarchia organizzativa, stato account, riferimenti fiscali, contesto di credito e ID account esterni.
| Livello Customer | Cosa esaminare | Implicazione per la migrazione |
|---|---|---|
| Account individuale | Email, nome, indirizzo, stato, strategia password e associazione Orders. | Gli acquirenti devono riconoscere la continuità dell’account. |
| Customer Group | Sconti, imposte, catalogo, prezzi o trattamento della vetrina. | L’assegnazione può cambiare esperienza e correttezza degli ordini. |
| Company | Company administrator, indirizzo legale, utenti, gerarchia e stato account. | Gli acquisti Company possono fallire se la struttura non è pianificata. |
| Controlli di acquisto | Quote, purchase order, credito, metodi di pagamento/spedizione e permessi. | I flussi B2B possono richiedere configurazione o implementazione separate oltre ai record Customer migrati. |
| Identificatori esterni | ID ERP/CRM/dealer, riferimento account manager, contract ID o riferimento fiscale. | Sistemi esterni possono dipendere da ID non visibili durante la revisione della vetrina. |
I dati Company non vanno trattati come un normale elenco di campi Customer: rappresentano una struttura di acquisto. L’ambito deve distinguere identità e relazioni trasferibili da permessi Company, controlli di acquisto, comportamento del credito e integrazioni esterne che richiedono implementazione separata sul piattaforma di destinazione.
Gli shared catalogs rendono accesso e prezzi specifici per l’acquirente
Gli shared catalogs rendono visibilità Product e prezzi specifici per il compratore. Adobe Commerce può mantenere uno shared catalog pubblico e shared catalogs personalizzati assegnati alle Company. Un Product può esistere nel catalogo principale ma non appartenere a ogni shared catalog; un prezzo personalizzato può essere corretto per una Company e sbagliato per un’altra; i permessi Category possono cambiare quando Shared Catalog è abilitato.
Le piattaforme di origine possono rappresentare questa logica mediante listini wholesale, tag Customer, gruppi dealer, Categories nascoste, elenchi Product privati, prezzi contrattuali, regole ERP o campi personalizzati. Durante la migrazione queste strutture devono essere reinterpretate, non semplicemente trasferite.
La traduzione verso shared catalogs deve rispondere a quattro domande: quali Company ricevono accesso, quali Products appartengono a ciascun catalogo, quali prezzi personalizzati si applicano e quali permessi o regole di visibilità Category devono essere rappresentati. Listini, Categories nascoste, tag dealer e riferimenti contrattuali ERP sono evidenze della relazione desiderata; non sono equivalenti automatici di uno shared catalog.
Gli Orders portano contesto commerciale, B2B e di integrazione
La migrazione Orders deve conservare uno storico utile senza far credere che ogni funzionamento del processo di acquisto di origine diventi comportamento attivo in Adobe Commerce. Gli Orders storici possono includere line item, Products, quantità, sconti, imposte, spedizione, fatturazione, riferimenti Customer, stati, riferimenti pagamento, rimborso, fattura, spedizione, credit memo, purchase order, quote, contesto Company e ID esterni.
Negli store B2B ed enterprise lo storico richiede ulteriore interpretazione. Un Order può appartenere a una Company e non solo a un Customer individuale. Uno sconto storico può riflettere un prezzo contrattuale o shared catalog. Un metodo di pagamento può dipendere da regole Company. Un purchase order può avere significato di approvazione. Per l’assistenza, il numero Order ERP può essere più importante del numero della vetrina.
| Contesto Order | Cosa conservare o classificare | Perché conta |
|---|---|---|
| Relazione Customer/Company | Account acquirente, Company, relazione administrator/user e contesto di gruppo. | L’assistenza deve sapere chi ha effettuato l’ordine e sotto quale account. |
| Dettaglio finanziario | Subtotale, sconti, imposte, spedizione, rimborso, credit memo, fattura e riferimenti pagamento. | Lo storico deve restare leggibile per assistenza e riconciliazione. |
| Flusso B2B | Quote, purchase order, account credit, approvazione o riferimento contrattuale. | Il significato B2B storico può non essere semplice dato Order. |
| Stato evasione degli ordini | Shipment, evasione degli ordini parziale, cancellazione, reso, riferimento magazzino o stato ERP. | Le operazioni devono poter interpretare cosa è avvenuto dopo l’acquisto. |
| Identificatori esterni | ID Order ERP, ID contabile, marketplace, opportunità CRM o riferimento magazzino. | La continuità delle integrazioni può dipendere da ID esterni ai campi standard. |
Il modello Order di destinazione deve considerare relazioni diverse per Orders B2C, B2B, rimborsati o accreditati, sensibili a sconti e imposte, riferimenti esterni e contesto Company/Customer Group. Queste relazioni determinano se lo storico resta comprensibile dopo la migrazione.
Contenuti, campagne e URL richiedono interpretazioni separate
La migrazione dei contenuti può includere CMS Pages, CMS Blocks, contenuti Category, descrizioni Product, landing page, Blog Posts quando pertinenti, media, metadati e asset promozionali. Negli store enterprise i contenuti possono essere legati anche a tempistiche di campagna, vetrine regionali, calendari di merchandising, governance del brand, revisione legale o approvazioni.
Content Staging cambia l’interpretazione quando contano aggiornamenti programmati. Adobe Commerce può programmare modifiche per Products, Categories, catalog/cart price rules, CMS Pages e CMS Blocks come parte di campagne. Una landing page, un banner Category, una promozione o un prezzo programmato possono esistere come contenuto ma perdere il proprio significato commerciale se ridotti a un record statico. L’ambito deve quindi separare contenuti evergreen, campagne future, aggiornamenti programmati attivi e materiale scaduto.
Anche gli URL richiedono separazione: Product URL key, Category URL key, percorsi CMS, URL rewrite, percorsi localizzati, redirect e route personalizzate di landing page vanno esaminati per valore aziendale. I conteggi possono passare mentre pagine Product di alto valore, accessi B2B, portali dealer, URL regionali o pagine di campagna perdono continuità.
I dati posseduti dalle integrazioni vanno identificati prima del mappatura
I progetti Adobe Commerce dipendono spesso da ERP, PIM, CRM, OMS, WMS, imposte, pagamento, shipping, marketplace, loyalty, subscription, analytics, search, personalization o marketing. Questi sistemi possono possedere campi e identificatori non evidenti durante la revisione della vetrina.
Esempi includono ID Product ERP/PIM, ID Company, dealer ID, contract ID, riferimenti listino, codici stock di magazzino, imposte exemption ID, riferimenti CRM, marketplace item ID, subscription ID e numeri Order esterni. Se vengono rimossi, rinominati o inseriti in campi non supportati, lo store migrato può apparire corretto mentre i flussi a valle falliscono.
I dati posseduti dalle integrazioni devono essere classificati prima del mappatura definitivo. Un valore può appartenere a un attributo nativo, a un campo di estensione, a una chiave cross-system, a un payload di integrazione separato o a una struttura legacy da escludere. La decisione deve seguire il sistema che continuerà a possedere il dato, non il punto in cui era casualmente memorizzato nel sistema di origine.
Le relazioni Adobe Commerce richiedono risultati di responsabilità espliciti
Un modello di destinazione completo assegna proprietà e significato lungo l’intera catena di relazioni. I record Product sostengono la governance del catalogo; Customer e Company preservano l’autorità di acquisto; Orders conservano uno storico utilizzabile; i contenuti mantengono il corretto contesto di vetrina e campagna; gli URL preservano l’intento dei percorsi; i campi di integrazione restano tracciabili ai sistemi che continuano a usarli.
Una revisione utile deve chiedere:
- I Products possono essere gestiti per famiglia, attribute set, website e ambito di vetrina?
- Gli acquirenti B2B possono accedere a catalogo, prezzo, account, quote, purchase order e credito corretti?
- I team di assistenza possono leggere gli Orders storici senza tornare al sistema di origine per capirne il significato di base?
- Contenuti e URL possono sostenere lancio, continuità SEO e requisiti delle campagne?
- I sistemi esterni riescono ancora a riconoscere i record migrati da cui dipendono?
Se l’ambito non consente di rispondere a queste domande, le relazioni di destinazione sono ancora indefinite anche se i record di origine sono disponibili.
Conclusione
Adobe Commerce cambia la pianificazione perché i dati spesso portano con sé logica operativa enterprise. Products non sono soltanto articoli: includono tipi, attributi, attribute set, website, store view, Categories, relazioni di inventario e riferimenti di integrazione. Customers non sono soltanto profili: possono essere Company, users, administrators, Customer Groups, acquirenti di shared catalogs e partecipanti a processi di approvazione. Contenuti, URL, Orders e inventario possono dipendere da ambito, tempo e sistemi esterni.
Una migrazione solida tratta il modello dati come traduzione del significato aziendale. L’obiettivo è collocare i record in una struttura che sostenga governance del catalogo, acquisti B2B, ambiti delle vetrine, continuità dei contenuti e responsabilità delle integrazioni.
Domande frequenti
Perché la migrazione dei dati Adobe Commerce richiede più del semplice mappatura dei campi?
Perché molti record hanno significato operativo. Products, Customers, Orders, contenuti, URL e inventario possono influenzare acquisti B2B, shared catalogs, ambito delle vetrine, governance degli attributi e integrazioni.
In che modo gli shared catalogs differiscono dalle normali Categories?
Le Categories organizzano navigazione e merchandising. Gli shared catalogs possono controllare visibilità Product e prezzi per acquirente, normalmente in relazione a Company o Customer Groups. Vanno pianificati come logica di accesso e prezzo, non solo come struttura del catalogo.
Cosa rende più complessi i dati Customer in Adobe Commerce?
Possono includere account individuali, Customer Groups, Company, Company users, administrators, ruoli, credito, permessi quote, purchase order e assegnazioni shared catalog. Un Customer può migrare come account ma perdere il significato dell’acquisto B2B.
I dati Content Staging vanno trattati come normali contenuti CMS?
No. Aggiornamenti di campagna sensibili al tempo, contenuti programmati, pagine promozionali e modifiche legate al lancio vanno esaminati separatamente. Parte dei contenuti può migrare come CMS stabile, mentre tempistiche e approvazioni possono richiedere configurazione Adobe Commerce o ricostruzione manuale.
Quando i dati Adobe Commerce richiedono una gestione separata sul destinazione?
Quando l’ambito include dati di estensioni non supportati, strutture database personalizzate, relazioni Company o catalogo non standard, identificatori di sistemi esterni o comportamenti privi di una destinazione nativa Adobe Commerce.
Come devono essere rappresentati gli identificatori esterni?
Conservarli solo se un processo ERP, CRM, PIM, evasione degli ordini, fiscale o di reporting continua a dipenderne. Stabilire se appartengono a un campo nativo, un campo di estensione, un riferimento di integrazione o una chiave cross-system documentata. Il risultato deve permettere a personale e sistemi connessi di tracciare il record migrato senza esporre l’identificatore come contenuto della vetrina né confonderlo con l’ID entità di Adobe Commerce.