Le migrazioni verso Adobe Commerce falliscono più spesso quando i record trasferiti vengono separati dalle relazioni enterprise che controllano chi può acquistare, cosa può vedere, quale prezzo si applica, da dove viene evaso l’ordine e quando un contenuto diventa attivo. Un Product può esistere nell’Admin e risultare comunque commercialmente errato perché appartiene al website sbagliato, non ha i configurable children, è escluso dallo shared catalog corretto oppure non conserva una relazione utilizzabile tra source e stock.
I problemi più dannosi non sono quindi semplici record mancanti. Sono rotture di relazione che possono sembrare complete durante una revisione superficiale. La prevenzione richiede che ogni regola enterprise abbia un proprietario Adobe Commerce definito, uno scenario rappresentativo e una chiara condizione di Pass.
Problema 1: trasformare gli account Company in record Customer scollegati
Cosa va storto
Gli account Company B2B possono contenere Company administrators, team, users, ruoli, permessi, indirizzi, aspettative di pagamento e relazioni di acquisto. Una migrazione che importa soltanto i Customers individuali conserva i dati di contatto ma elimina l’organizzazione che governa quegli acquirenti.
Lo store può mostrare tutti gli indirizzi email previsti mentre i Company administrator non riescono a gestire gli utenti, gli acquirenti con permessi limitati ricevono accesso eccessivo e gli Orders non sono più associati al corretto account aziendale.
Segnali di allerta iniziali
| Segnale | Cosa indica |
|---|---|
| Company, division, team e user vengono esportati come un unico elenco Customer. | La gerarchia B2B viene appiattita in account individuali scollegati. |
| Administrator e acquirente roles sono rappresentati soltanto da etichette testuali. | Permessi e responsabilità delle approvazioni non possono essere ricostruiti in modo affidabile. |
| Più acquirente condividono prezzi o indirizzi Company senza un identificatore Company durevole. | Il contesto commerciale condiviso verrà frammentato tra Customers. |
| La sorgente usa approval, account credit o restrizioni di pagamento fuori dal record Customer. | Un comportamento B2B critico non ha un proprietario sul piattaforma di destinazione. |
Prevenzione
Modellare la Company come entità aziendale padre. Conservare identificatore Company, Company administrator, subordinate users, team, assegnazioni dei ruoli, indirizzi, relazione Customer Group e chiave account esterna usata da CRM o ERP. Non dedurre l’appartenenza a una Company soltanto dal dominio email o dalla somiglianza degli indirizzi.
Esempio di raccomandazione
Usare come pattern una Company con administrator, senior acquirente e restricted acquirente. Rappresentare separatamente l’appartenenza e il ruolo di ogni user, quindi conservare account condiviso e identificatore Company esterno.
Condizione di Pass
La Company rappresentativa compare una sola volta, contiene users e team corretti, assegna a ciascun ruolo i permessi previsti e resta collegata a Customer Group, indirizzi e chiave account esterna corretti.
Problema 2: assegnare shared catalogs senza mantenere i prezzi specifici per Company
Cosa va storto
Gli shared catalogs possono controllare selezione Product e prezzi personalizzati per Company. Importare Products e Company senza la relazione shared catalog può esporre Products riservati al pubblico, nascondere articoli contrattuali ai acquirenti autorizzati oppure sostituire prezzi negoziati con prezzi generali di catalogo.
L’errore è facile da perdere perché il catalogo principale può apparire completo nell’Admin mentre la visibilità cambia nel contesto della singola Company.
Segnali di allerta iniziali
- Lo stesso SKU ha prezzi diversi per Company o Customer Groups differenti.
- Products privati sono inclusi nell’export generale dei Products.
- Contratti o record ERP definiscono prezzi non memorizzati sul Product di origine.
- Assegnazione Company e assegnazione catalogo vengono mantenute in sistemi di origine separati.
Prevenzione
Creare una relazione esplicita tra Company, shared catalog, selezione Product, prezzo personalizzato, ambito website e Customer Group. Mantenere separati catalogo pubblico e cataloghi specifici per Company e conservare l’eventuale contract ID esterno che spiega la fonte del prezzo.
Esempio di raccomandazione
Usare uno SKU pubblico, uno SKU riservato e uno SKU con prezzo contrattuale. Rappresentare come ciascuno appare a un acquirente senza account, a un Customer ordinario e a due Company con shared catalogs differenti.
Condizione di Pass
Ogngli acquirenti rappresentativo vede soltanto Products e prezzi previsti, mentre utenti esterni alla Company assegnata non possono accedere a Products riservati o valori negoziati tramite Categories, search, URL diretto, cart o processo di acquisto.
Problema 3: ricreare gli acquirenti ma perdere quote, purchase order e relazioni di approvazione
Cosa va storto
Gli acquisti B2B Adobe Commerce possono includere negotiable quotes, purchase orders, approval rules, requisition lists e accesso basato su ruoli. Questi record non sono normali Orders o wish list. Appiattirli in note generiche elimina stato, responsabile, percorso di approvazione, storico delle righe e relazione con la Company.
Un acquirente può mantenere lo storico Orders ma perdere una quote aperta, un purchase order in attesa o la requisition list usata per acquisti ricorrenti.
Segnali di allerta iniziali
| Segnale | Cosa indica |
|---|---|
| Quote e purchase order vengono esportati insieme agli Orders ma usano ID o stati diversi. | Flussi di acquisto distinti stanno venendo ridotti a storico Orders completati. |
| Approval limit esistono in policy o in un sistema procurement esterno. | La logica di controllo è fuori dall’insieme dei record migrati. |
| Le requisition lists contengono set SKU ricorrenti ma vengono trattate come wish list. | L’intento operativo di acquisto viene confuso con una preferenza di merchandising. |
| Commenti quote, revisioni, scadenze o sconti negoziati non hanno un responsabile proposto. | Lo storico della negoziazione commerciale risulterà incompleto. |
Prevenzione
Classificare separatamente ogni flusso B2B. Conservare Company, creatore, approvatore, stato, line item, quantità, adeguamenti negoziati, commenti, date e riferimenti esterni quando la continuità del flusso sul destinazione lo richiede. I record storici che non possono restare attivi devono comunque mantenere contesto sufficiente per consentire a personale e acquirente di comprenderne lo stato.
Esempio di raccomandazione
Selezionare una negotiable quote aperta, un purchase order approvato, un purchase order in attesa di approvazione e una requisition list. Definire per ciascun tipo responsabile di destinazione e storico da mantenere.
Condizione di Pass
La destinazione distingue quote, purchase order, relazioni di approvazione, requisition lists e Orders completati; ogni record rappresentativo resta collegato a Company e user corretti con stato e storico delle righe comprensibili.
Problema 4: appiattire l’ambito Adobe Commerce tra website, store e store view
Cosa va storto
Adobe Commerce usa una gerarchia website, store e store view. L’ambito può influenzare assegnazioni Product, root Categories, testi localizzati, URL, configurazione, valute e contesto commerciale B2B. Un’importazione globale può sovrascrivere valori regionali o linguistici e collocare Products o contenuti nella vetrina sbagliata.
La store view predefinita può apparire corretta mentre un’altra lingua, brand o regione mostra fallback text, Products mancanti o route errate.
Segnali di allerta iniziali
- Products o Categories differiscono per website o brand.
- Nomi, descrizioni, metadati e URL key variano per store view.
- Ogni store ha root Category o menu differenti.
- Customers, shared catalogs, valute o contenuti sono legati a website specifici.
Prevenzione
Mappare la gerarchia Store della sorgente verso responsabilità Adobe Commerce di website, store e store view prima di assegnare valori alle entità. Separare attributi globali da prezzi website-ambitod e contenuti store-view. Conservare source ambito code quando integrazioni o import dipendono da essi.
Esempio di raccomandazione
Usare un configurable Product e una CMS Page con testo, URL key e visibilità differenti su due store view e due website. Documentare quali valori sono globali e quali hanno ambito specifico.
Condizione di Pass
Ogni website, store e store view rappresentativo mostra assegnazione Product, root Category, contenuto localizzato, URL e contesto commerciale previsti senza contaminazioni da un altro ambito.
Problema 5: ridurre tipi Product complessi a Products piatti
Cosa va storto
Adobe Commerce supporta simple, configurable, grouped, virtual, bundle, downloadable e gift-card Products. Questi tipi usano relazioni padre/figlio, inventario, prezzo, peso, file e cart differenti. Appiattirli in Products ordinari può duplicare SKU, eliminare combinazioni selezionabili, rompere la composizione bundle o scollegare file downloadable.
Un Product può apparire completo ma non comportarsi più come l’offerta acquistata dai clienti nella sorgente.
Segnali di allerta iniziali
- SKU padre e child non sono identificati separatamente.
- Componenti bundle o grouped Products sono memorizzati come testo nelle descrizioni.
- Download link e access limit sono mantenuti fuori dall’export Product.
- Custom options e configurable attributes vengono mescolati.
Prevenzione
Classificare il tipo Product prima del mappatura dei campi. Conservare associazioni configurable padre/figlio, attributi di variazione, bundle option, grouped link, file downloadable, significato di virtual shipping e interpretazione delle righe Order. Non creare varianti da attributi descrittivi che non rappresentano unità vendibili indipendenti.
Esempio di raccomandazione
Usare un configurable Product con child stock misto, un bundle con prezzo dinamico, un grouped Product e un downloadable Product. Conservare per ciascuno composizione e significato di evasione degli ordini distinti.
Condizione di Pass
Ogni Product rappresentativo mantiene struttura padre/figlio o componenti, valori selezionabili, identità SKU, fonte prezzo, comportamento stock, media e significato delle righe Order corretti.
Problema 6: importare contenuti di campagna senza la timeline di staging
Cosa va storto
Adobe Commerce Content Staging può programmare aggiornamenti a Products, Categories, catalog/cart price rules e CMS Pages attraverso campagne. Importare soltanto i valori attualmente visibili può eliminare campagne future, contenuto baseline, raggruppamento delle campagne, finestre temporali e reversione automatica dopo la data di fine.
Una promozione futura può non comparire mai oppure un contenuto di campagna può restare attivo permanentemente perché la timeline è stata ridotta a campi statici.
Segnali di allerta iniziali
| Segnale | Cosa indica |
|---|---|
| La sorgente contiene modifiche programmate a Product, prezzo, Category, rule o CMS. | I soli valori correnti non rappresentano il piano della campagna. |
| Il marketing dipende da un calendario di staging o da nomi di campagne. | Tempistica e attivazione coordinata fanno parte del significato aziendale. |
| Più entità cambiano insieme alla stessa ora di lancio. | Un’importazione record per record non può mantenere la relazione di campagna. |
| Il contenuto attivo differisce dalla versione baseline memorizzata. | La migrazione può acquisire lo stato temporale sbagliato. |
Prevenzione
Inventariare valori baseline, aggiornamenti programmati, appartenenza alle campagne, orari di inizio/fine, presupposti sul fuso orario e store view interessate. Decidere quali campagne restano rilevanti e quali devono essere ricostruite come record Content Staging correnti invece di essere importate come contenuti statici.
Esempio di raccomandazione
Usare una campagna che modifica insieme prezzo Product, contenuto Category e CMS landing page. Conservare baseline e finestra della campagna come stati separati.
Condizione di Pass
La campagna rappresentativa contiene entità, contenuto baseline, programmazione, contesto store view e comportamento di reversione corretti; nessun aggiornamento futuro viene trasformato silenziosamente in dato operativi permanente.
Problema 7: copiare quantità senza ricostruire sources, stocks e relazioni con i canali di vendita
Cosa va storto
L’inventario Adobe Commerce separa sources fisiche da stocks che aggregano le sources per i canali di vendita. Una quantità priva di source, stock, website, stato e contesto salable può collocare inventario nel magazzino sbagliato o rendere indisponibile un Product pur con quantità positiva.
Gli store multi-source sono particolarmente vulnerabili quando tutte le location vengono sommate nella Default Source.
Segnali di allerta iniziali
- Quantità di warehouse, store, drop shipper o pickup sono separate.
- La sorgente usa allocazione, reservation o disponibilità per canale.
- I Products importati finiscono nella stessa source anche se più location evadono Orders.
- I child configurable hanno copertura di location differente.
Prevenzione
Conservare source identity, source code, source quantity, stock assignment, website relationship, status ed external warehouse key. Distinguere quantità on-hand dal valore che può essere venduto attraverso un determinato sales channel. Definire quale sistema resta autorevole dopo la migrazione.
Esempio di raccomandazione
Usare uno SKU presente in due magazzini e un configurable Product con children disponibili da sources diverse. Mappare ogni source allo stock che serve il website previsto.
Condizione di Pass
I Products rappresentativi mostrano source quantities, assegnazioni stock/website, disponibilità vendibile e responsabilità dell’evasione degli ordini corretti senza appiattire location distinte in un totale non spiegato.
Problema 8: trattare URL rewrite e contenuti con ambito come semplici slug
Cosa va storto
Adobe Commerce può mantenere URL rewrite per Products, Categories e CMS Pages. Le route possono variare per website/store view e i contenuti possono includere link interni, media path, strutture Page Builder o riferimenti di campagna. Copiare soltanto lo slug corrente può eliminare lo storico redirect e interrompere percorsi di alto valore.
Segnali di allerta iniziali
- La sorgente contiene più URL storici per la stessa entità.
- Product o Category URL key variano per store view.
- I contenuti CMS includono URL di origine o media path hard-coded.
- Campagne, paid media o link partner dipendono da route legacy.
Prevenzione
Trattare ogni percorso di origine come relazione tra vecchia route, entità di destinazione, ambito, tipo redirect e percorso canonical previsto. Riscrivere link interni e riferimenti media in base al proprietario di destinazione. Mantenere distinti contenuti CMS, layout Page Builder e storico URL.
Esempio di raccomandazione
Usare un Product con URL rinominato, una Category spostata nella gerarchia e una CMS Page localizzata. Conservare destinazione canonical e tutti i percorsi di origine critico per l’attività.
Condizione di Pass
Ogni route legacy rappresentativa raggiunge la destinazione con ambito corretto, link interni e media si risolvono e nessun contenuto riservato o localizzato viene reindirizzato al website/store view sbagliato.
Problema 9: conservare i totali Order ma perdere contesto Company e evasione degli ordini
Cosa va storto
Gli Orders storici possono conservare i totali e perdere Company responsabilità, purchaser role, contesto shared catalog, discendenza da quote/purchase order, source item, spedizione, fattura, rimborso e identificatori transazionali esterni. Il personale vede quindi un record finanziario senza evidenze sufficienti per assistere l’acquirente o riconciliare la transazione.
Segnali di allerta iniziali
- Orders B2B sono collegati soltanto a Customers individuali.
- Le righe Order non identificano il configurable child o bundle component originale.
- Shipment e rimborso sono memorizzati separatamente dall’export Order.
- Riferimenti ERP o pagamento esistono soltanto in tabelle di estensione.
Prevenzione
Conservare header Order, identità Company e acquirente, indirizzi, snapshot delle righe, opzioni selezionate, prezzi, sconti, imposte, riferimento shared catalog o quote, fattura, spedizione, rimborso, commenti e ID esterni. Mantenere gli snapshot storici indipendenti dalle impostazioni correnti Product e Company.
Esempio di raccomandazione
Usare un Order Company creato da una quote, un Order parzialmente spedito e un Order rimborsato contenente un configurable Product. Tracciare ogni record correlato fino all’Order.
Condizione di Pass
Ogni Order rappresentativo resta comprensibile a Customer service, team finanziario e operations, con contesto Company, acquirente, Product, pagamento, spedizione, rimborso e sistema esterno intatto.
Problema 10: copiare campi di estensioni e integrazioni senza la logica che li possiede
Cosa va storto
Le installazioni Adobe Commerce contengono spesso moduli, attributi personalizzati, tabelle personalizzate, API, event observer, identificatori ERP/PIM, record marketplace, integrazioni imposte, dati evasione degli ordini e campi personalizzati del processo di acquisto. Copiare i valori in campi generici non mantiene il flusso che li crea, aggiorna o utilizza.
Il destinazione può contenere il dato mentre ogni sistema connesso lo considera mancante o non aggiornato.
Segnali di allerta iniziali
| Segnale | Cosa indica |
|---|---|
| Valori importanti hanno prefissi di modulo o vivono in tabelle personalizzate. | Il dato è probabilmente posseduto dalla logica di un’estensione e non da un’entità standard. |
| I sistemi esterni identificano Products, Company, Customers o Orders tramite chiavi non standard. | La continuità cross-system dipende da identificatori fuori dai campi predefiniti. |
| I valori validi di un campo sono imposti dal codice e non dalla sola struttura database. | Copiare il valore non conserva le relative regole. |
| Il personale non sa spiegare quale sistema sia autorevole per il campo. | Un conflitto di responsabilità può causare sovrascrittura o ignorare il valore. |
Prevenzione
Creare un registro di responsabilità per ogni record di estensione e integrazione. Indicare entità padre, tabella/API di origine, chiave esterna, sistema autorevole, direzione di aggiornamento e proprietario di destinazione. Escludere residui tecnici obsoleti invece di promuoverli a campi personalizzati permanenti.
Esempio di raccomandazione
Tracciare un Product dal PIM ad Adobe Commerce, una Company dal CRM e un Order verso ERP e evasione degli ordini. Registrare identificatori e confini di responsabilità necessari a ogni passaggio.
Condizione di Pass
Ogni valore personalizzato o di integrazione mantenuto ha proprietario di destinazione, relazione padre stabile, sistema autorevole e identificatore cross-system utilizzabile; nessun flusso essenziale dipende da un campo orfano.
Priorità di prevenzione tra i problemi
La prevenzione dovrebbe mantenere cinque livelli collegati: identità Company, regole commerciali specifiche per acquirente, dati di vetrina con ambito, relazioni Product/inventario e responsabilità dei sistemi esterni. Una correzione su un livello non deve rompere silenziosamente gli altri. Per esempio, ricostruire uno shared catalog modifica anche Company assignment, Category permissions, price indexing e accesso alla vetrina.
| Livello di prevenzione | Controllo richiesto |
|---|---|
| Identità Company e acquirente | Mantenere collegate relazioni Company, location, ruolo, approvazione e Customer. |
| Assegnazione commerciale | Conservare insieme shared catalog, Company assignment, prezzo delle varianti e contesto delle regole di acquisto. |
| Dati vetrina con ambito | Mantenere responsabilità website, store e store view per Products, contenuti, URL e Customers. |
| Contenuti temporali | Separare stato attivo da versioni di campagne programmate e modifiche coordinate. |
| Responsabilità esterna | Assegnare campi di estensioni, tabelle personalizzate e ID esterni a un sistema autorevole. |
Conclusione
Le migrazioni Adobe Commerce diventano inaffidabili quando relazioni enterprise vengono ridotte a normali campi e-commerce. Company, ruoli, shared catalogs, quote, purchase order, valori con ambito, campagne Content Staging, inventory sources, Orders storici, URL rewrite e identificatori di integrazione richiedono tutti un proprietario chiaro.
Il modello più sicuro tratta ogni problema come una relazione spezzata, non come una riga mancante. Quando entità padre, regole commerciali, ambito, storici e chiavi esterne restano collegati, lo store migrato può sostenere i flussi enterprise per cui quei record esistono.
Domande frequenti
Perché i Company users non equivalgono a normali Customers?
I Company users ereditano il contesto aziendale dalla Company, inclusi ruoli, permessi, shared catalogs e flussi di acquisto. Un account Customer individuale non mantiene queste relazioni organizzative.
I prezzi shared catalog possono essere migrati come normali prezzi Product?
Non in sicurezza. I prezzi shared catalog appartengono a relazioni specifiche tra catalogo e Company. Spostarli nel pricing generale può esporre valori negoziati agli acquirenti sbagliati o rimuoverli dalle Company che dovrebbero riceverli.
Perché website, store e store view devono essere mantenuti separatamente?
La gerarchia può controllare assegnazione Product, root Categories, valori localizzati, URL, configurazione e contesto commerciale. Un valore globale può sovrascrivere o far trapelare informazioni che erano intenzionalmente ambitod.
Cosa distingue Content Staging da normali contenuti CMS?
Content Staging mantiene valori baseline, aggiornamenti programmati, raggruppamento delle campagne, tempistiche e comportamento di reversione. Il valore attualmente visibile rappresenta soltanto un punto lungo quella timeline.
Perché una quantità della sorgente non basta per l’inventario Adobe Commerce?
Il significato dell’inventario dipende da source fisica, stock che aggrega sources, sales channel/website, stato e sistema che resta autorevole. La quantità da sola non identifica dove o come il Product possa essere evaso.
Come vanno gestiti i dati Adobe Commerce posseduti dalle estensioni?
Identificare modulo o sistema esterno, entità core estesa, identificatore stabile e flusso che utilizza il valore. Mantenere soltanto record con un responsabile di destinazione definito e un uso aziendale continuativo.