Se Adobe Commerce viene scelto come piattaforma di destinazione, la preparazione deve trasformare il modello operativo enterprise in un pacchetto di evidenze controllato prima di qualsiasi esecuzione. Il team deve sapere come rappresentare nello store di destinazione Customers B2C, Company B2B, Company users, shared catalogs, website, store, store view, tipi Product, inventory sources, Orders storici, contenuti e sistemi esterni.
Un pacchetto di preparazione utile risponde a quattro domande per ogni area importante: quale azione è richiesta, chi ne è responsabile, quale evidenza sostiene la decisione e quale condizione rende l’area pronta. Questo evita di scoprire relazioni Company, prezzi specifici per acquirente, vetrine regionali o identificatori ERP soltanto dopo che i record di prova sono già stati migrati.
Definire le decisioni operative di Adobe Commerce
Iniziare con un documento sintetico sul modello operativo. Deve definire quali strutture e-commerce devono esistere in Adobe Commerce e quali sistemi restano autorevoli all’esterno della piattaforma.
| Area di preparazione | Decisione da registrare | Responsabile | Evidenza di preparazione |
|---|---|---|---|
| Modello acquirenti | Customers B2C, Company B2B, sedi Company, Company users, ruoli, approvatori e sales representatives | B2B e Customer operations | Diagramma approvato delle relazioni account con record rappresentativi di origine |
| Modello catalogo | Tipi Product, attribute set, Categories, shared catalogs, visibilità per acquirente e assortimento regionale | Responsabili catalogo e merchandising | Matrice famiglie Product e ambito catalogo |
| Ambito vetrine | Website, store, store view, lingue, valute, brand, regioni e domini | Responsabile architettura e-commerce | Mappa website/store/store view |
| Responsabilità dei prezzi | Base price, tier price, negotiated price, shared-catalog price e prezzi contrattuali esterni | Responsabili commerciali e integrazioni | Registro delle fonti prezzo ed esempgli acquirenti |
| Responsabilità inventario | Sources, stocks, website, magazzini, drop shipper, punti di ritiro e sistemi inventario esterni | Responsabili inventario ed evasione degli ordini | Mappa di responsabilità source/stock |
| Modello integrazioni | Dipendenze ERP, PIM, CRM, WMS, procurement, accounting, imposte, shipping, search e reporting | Responsabile tecnico | Registro dipendenze con identificatori durevoli |
Il documento deve essere abbastanza specifico da guidare la preparazione senza diventare una specifica di configurazione Adobe Commerce. Lo scopo è stabilire il proprietario di destinazione per ogni relazione aziendale.
Preparare accessi, evidenze di origine e backup recuperabili
Raccogliere gli accessi e le evidenze necessari per interpretare lo store di origine senza dipendere da conoscenze non documentate del personale.
Preparare:
- accesso amministratore allo store di origine e all’ambiente Adobe Commerce con i permessi necessari;
- export o report datati per Products, Categories, Customers, Company, Company users, Orders, contenuti, Reviews, promozioni e altri record in ambito;
- backup di database e media dove disponibili;
- riferimenti per attributi Product, attribute set e tipi Product;
- inventari di website, store, store view, lingue, valute e domini;
- esempi B2B relativi a Company, ruoli, shared catalogs, prezzi e credito;
- report su inventory sources, stocks, magazzini e evasione degli ordini;
- inventari di estensioni, moduli personalizzati, API e sistemi esterni;
- elenchi di URL ad alto valore, redirect, CMS Pages, block e campagne;
- screenshot o report che spieghino comportamenti importanti della sorgente.
| Evidenza | Perché serve | Condizione di preparazione |
|---|---|---|
| Registro accessi | Conferma che le aree necessarie di sorgente e destinazione possano essere ispezionate | Gli account richiesti funzionano e i responsabili dei permessi sono identificati |
| Archivio export | Conserva uno stato di riferimento datato | I file si aprono correttamente e contengono le famiglie di record previste |
| Backup database/media | Protegge record non esposti dagli export ordinari | Posizione, data e responsabile del ripristino sono documentati |
| Dizionario dei campi | Spiega etichette, flag e identificatori personalizzati | Ogni campo importante ha scopo, proprietario ed esempio |
| Mappa ambito | Evita di appiattire website, store view, relazioni B2B e inventario | Ogni business unit e vetrina in ambito ha una destinazione assegnata |
Se un export omette record di estensioni o B2B, documentare la lacuna e assegnare un responsabile. L’assenza di evidenza è un problema di preparazione, non la prova che i dati non esistano.
Preparare Company B2B, users, ruoli e contesto di acquisto
Le relazioni B2B richiedono preparazione oltre ai normali profili Customer. Una Company può contenere users, team, ruoli, permessi, assegnazioni shared catalog, credito, purchase order, restrizioni su pagamento e spedizione e identificatori account esterni.
Preparare evidenze rappresentative per:
- identità legale Company, stato, imposte ID, reseller ID e indirizzo legale;
- relazioni tra Company administrator e sedi Company;
- acquirente, approver, branch user, purchasing team e users associati a più Company;
- ruoli e permessi per Orders, quote, purchase order, users, team e Company Credit;
- credit limit, saldo disponibile, valuta, contesto pagamento-on-account e storico credito quando rilevante;
- aspettative di approvazione purchase order e riferimenti procurement;
- metodi di pagamento e spedizione consentiti;
- riferimenti sales representative, account ERP, dealer, procurement e CRM.
| Elemento di preparazione | Responsabile | Evidenza richiesta | Condizione di preparazione |
|---|---|---|---|
| Identità Company | B2B operations | Elenco master Company e ID di origine | Ogni Company ha un record Adobe Commerce previsto |
| Appartenenza users | Customer operations | Matrice user-to-company e user-to-team | Ogni Company user ha Company, stato e ruolo definiti |
| Modello permessi | Responsabile processo B2B | Esempi di ruoli e permessi | Le responsabilità di acquisto richieste sono documentate |
| Contesto credito e PO | Team finanziario e procurement | Record rappresentativi di credito e purchase order | Relazioni finanziarie e di approvazione hanno un proprietario di destinazione |
| Chiavi account esterne | Responsabile dell’integrazione | ID ERP, CRM, procurement e dealer | Ogni chiave è collegata al livello Company o user corretto |
Se il significato B2B è nascosto in Customer Groups, tag, campi personalizzati, fogli di calcolo o sistemi esterni, preparare un registro di traduzione invece di forzare tali valori in normali campi Customer.
Preparare shared catalogs, prezzi e visibilità Product
Gli shared catalogs possono controllare disponibilità Product e prezzi personalizzati per Company. La preparazione deve identificare quali cataloghi contano, quali Company li ricevono, quali Products vi appartengono e quale sistema è autorevole per i prezzi.
| Record catalogo o prezzo | Azione di preparazione | Evidenza |
|---|---|---|
| Catalogo pubblico | Definire Products e Categories disponibili ai Customers ordinari | Campione di appartenenza Product/Category |
| Shared catalog personalizzato | Definire assegnazione Company, appartenenza Product e prezzi personalizzati | Matrice Company-to-catalog e Product-to-catalog |
| Prezzo Customer Group | Identificare relazione Customer Group/Product | Esempio Product e Customer Group |
| Tier o quantity price | Registrare Product, soglia, ambito acquirente e importo | Campione price tier con responsabile della sorgente |
| Contract o negotiated price | Identificare l’autorità prezzo interna o esterna | Esempio acquirente/Product e chiave del sistema esterno |
| Assortimento limitato | Definire Company o gruppi autorizzati a vedere o comprare | Campione visibilità ed elenco eccezioni |
Normalizzare nomi catalogo duplicati, listini obsoleti, eccezioni scadute e identificatori Product incoerenti prima che diventino strutture Adobe Commerce. L’area è pronta quando ogni Company prioritaria può essere associata a catalogo e fonte prezzo previsti senza dipendere dalla memoria del personale.
Preparare tipi Product, attributi e governance del catalogo
Selezionare Products rappresentativi in base alla struttura, non soltanto alla popolarità. Adobe Commerce supporta più tipi Product e i record di origine devono essere classificati in funzione di come vengono venduti e gestiti.
Includere esempi di:
- simple Products;
- configurable Products con child SKU gestiti a stock indipendentemente;
- grouped e bundle Products;
- virtual e downloadable Products;
- gift card o tipi Product personalizzati quando pertinenti;
- Products con opzioni personalizzate;
- Products con valori localizzati o specifici per website;
- Products con attributi personalizzati, ID esterni o dati posseduti dalle integrazioni;
- Products assegnati a più Categories o cataloghi limitati.
Preparare un foglio di governance degli attributi:
| Comportamento di origine | Decisione di preparazione Adobe Commerce | Evidenza di preparazione |
|---|---|---|
| Il valore definisce una variazione vendibile | Definire configurable Product, child simple Products e attributi di variazione | ID padre/figlio, SKU, valori opzione, stock, prezzo e immagini |
| Il valore descrive il Product | Definire attributo Product, tipo di dati, ambito e attribute set | Definizione campo e valori rappresentativi |
| L’acquirente inserisce un valore una tantum | Definire opzione personalizzata, estensione o proprietario della riga Order | Esempio della vetrina e di Order storico |
| Il valore cambia per website o store view | Definire ambito attributo e responsabilità localizzata | Matrice valori website/store view |
| Il Product è bundle o group | Definire component Products e relazione commerciale | Elenco componenti, quantità, pricing e responsabile dell’inventario |
| Il valore è metadato di un sistema esterno | Conservarlo a livello Product o child SKU utilizzato dal sistema esterno | Chiave esterna ed esempio di lookup |
Rimuovere attributi inutilizzati, normalizzare valori controllati, identificare gli attribute set richiesti e documentare i campi da escludere. Il catalogo è pronto quando ogni famiglia Product principale ha tipo, attribute set, relazione child, responsabilità Category e piano per identificatori esterni chiaramente definiti.
Preparare website, store view, contenuti, URL e campagne
Mappare la struttura della vetrina di origine verso website, store e store view Adobe Commerce. Registrare quali valori cambiano per brand, regione, lingua, valuta, dominio o entità legale.
Preparare:
- gerarchia website/store/store view;
- assegnazioni lingua e valuta;
- contenuti Product e Category per ambito;
- CMS Pages, CMS Blocks, contenuti Page Builder, form, banner e media;
- record di campagne programmate o staged ancora rilevanti;
- URL Product, Category, CMS, campagne e URL localizzati;
- storico redirect e percorsi di origine ad alto valore;
- link interni incorporati in descrizioni Product e contenuti CMS.
| Route o contenuto di origine | Domanda di preparazione | Evidenza di preparazione |
|---|---|---|
| URL Product o Category | Quale website e store view possiedono la route di destinazione? | Registro route origine/destinazione |
| Contenuto localizzato | Quali valori sono tradotti o specifici per regione? | Matrice contenuti per store view |
| CMS Page o block | È contenuto riutilizzabile, pagina, campagna o solo presentazione? | Inventario contenuti con responsabile di destinazione |
| Campagna programmata | Il contenuto è ancora necessario, solo storico o intenzionalmente ritirato? | Decisione campagna e responsabile dei contenuti |
| Link interno | Quale route destinazione deve sostituire il percorso di origine? | Elenco di riscrittura link per contenuti prioritari |
L’area è pronta quando ogni route pubblica e asset prioritario ha destinazione, ambito o decisione di ritiro prevista.
Preparare inventario, Customers e Orders storici
Le evidenze inventario devono definire la relazione tra location di origine, Adobe Commerce sources, stocks, website, salable quantity ed eventuale autorità inventario esterna. Preparare esempi per Products single-source e multi-source, child SKU configurable, backorder, pickup location, drop shipper e stock controllato da ERP/WMS.
Per Customers e Orders, scegliere campioni che espongano le relazioni storiche che il personale deve poter comprendere:
- Customers B2C registrati, acquirente senza account, più indirizzi, Customer Groups, trattamento fiscale e ID esterni;
- Customers Company e Company users;
- Orders con configurable, bundle, virtual, downloadable o Products con opzioni personalizzate;
- sconti, imposte, shipping, pagamento label, fattura, spedizione, credit memo, return, commenti e riferimenti esterni;
- Orders provenienti da ogni website, valuta, regione, Company o percorso evasione degli ordini importante.
| Area | Responsabile | Evidenza | Condizione di preparazione |
|---|---|---|---|
| Inventory sources e stocks | Operazioni di inventario | Mappa source/stock/location e campioni SKU | Ogni SKU prioritario ha stock responsabile e relazione website dichiarati |
| Identità Customer | Customer operations | Esempi duplicati, senza account, indirizzi, gruppi e ID esterni | Regole di identità e merge sono documentate |
| Significato Orders storici | Support e team finanziario | Pacchetto Orders rappresentativi | Righe Product, totali, stati, evasione degli ordini, rimborso e riferimenti sono spiegati |
| Dati sensibili | Ufficio legale e responsabile dei dati | Elenco campi approvato | Dati personali o finanziari non necessari sono esclusi |
Gli Orders storici vanno preparati come evidenza del commercio passato. Configurazione corrente di pagamento, shipping, imposte, inventario ed evasione degli ordini in Adobe Commerce resta responsabilità di implementazione separata.
Inventariare estensioni, moduli personalizzati e sistemi esterni
Creare un unico registro delle dipendenze per ogni estensione, modulo personalizzato, integrazione, scheduled job, tabella personalizzata, API e sistema esterno che crea o modifica record in ambito.
Per ciascuna dipendenza, registrare:
- scopo aziendale;
- record core estesi;
- tabelle, attributi, stati o identificatori creati;
- responsabile dei dati e responsabile tecnico;
- disponibilità export o API;
- proprietario o sistema sostitutivo sul destinazione;
- chiavi stabili necessarie alla riconnessione;
- record che possono essere ritirati o archiviati.
Le dipendenze prioritarie includono spesso ERP, PIM, CRM, WMS, procurement, search, subscriptions, loyalty, Reviews, imposte, pagamento, shipping, marketplace, analytics, reporting e flussi B2B personalizzati.
Il registro è pronto quando ogni dipendenza importante ha un proprietario continuativo definito e nessun campo critico è descritto soltanto con “lo gestiva l’estensione”.
Selezionare campioni rappresentativi per il test di migrazione
Scegliere campioni che espongano le decisioni enterprise preparate. Non usare Products casuali o soltanto Orders semplici.
| Campione | Scopo della preparazione |
|---|---|
| Famiglia Product simple e configurable | Stabilire tipo Product, child SKU, attributi, media e pattern inventario |
| Bundle o grouped Product | Esporre relazioni componenti e pricing |
| Company B2B con più users | Esporre Company, team, ruoli e ID esterni |
| Product shared catalog | Esporre assegnazione Company, visibilità e prezzo |
| SKU multi-source inventory | Esporre source, stock, website e responsabilità inventario esterno |
| Product o CMS Page localizzato | Esporre ambito store view e responsabilità route |
| Order storico complesso | Esporre righe Product, totali, evasione degli ordini, credit memo e riferimenti esterni |
| Record posseduto da estensione | Esporre campi personalizzati, tabelle e decisioni di responsabilità sul destinazione |
Per ogni campione fornire source ID, URL di origine se pertinente, motivo aziendale, proprietario Adobe Commerce previsto, identificatori esterni correlati, esclusioni note e revisore responsabile. In questo modo ogni campione ha un’aspettativa tracciabile e un revisore nominato.
Completare il gate di preparazione Adobe Commerce
| Domanda di preparazione | Evidenza richiesta | Condizione di preparazione |
|---|---|---|
| Accessi e backup sono disponibili? | Registro accessi e archivio datato | Sistemi richiesti ed evidenze di origine sono recuperabili |
| Il modello operativo è documentato? | Mappe acquirenti, vetrine, catalogo, pricing e inventario | Ogni relazione principale ha un responsabile |
| Le strutture B2B sono preparate? | Evidenze Company, user, ruoli, catalogo, credito e PO | Relazioni Company rappresentative complete |
| Le famiglie Product sono classificate? | Matrice Product e attributi | Ogni pattern Product principale ha una struttura Adobe Commerce prevista |
| Contenuti e URL sono assegnati? | Registro route e contenuti | Le route prioritarie hanno destinazione o decisione di ritiro |
| Le integrazioni sono inventariate? | Registro dipendenze | Ogni dipendenza critica ha proprietario continuativo e chiave |
| Sono selezionati campioni rappresentativi? | Registro campioni | Record ordinari ed eccezionali sono coperti |
| Gli elementi irrisolti sono controllati? | Decision log | Ogni punto aperto ha responsabile e scadenza |
Il gate è completo quando le evidenze sono comprensibili anche da chi non ha configurato lo store di origine e nessuna decisione critica su B2B, Product, inventario, Order, URL o integrazioni dipende da ipotesi non documentate.
Conclusione
La preparazione Adobe Commerce deve produrre un pacchetto di evidenze enterprise, non una generica checklist di export. Company, users, ruoli, shared catalogs, tipi Product, attributi, store view, inventory sources, Orders storici, contenuti e integrazioni richiedono proprietari espliciti e record rappresentativi.
Quando queste decisioni sono documentate prima del test rappresentativo, il team può valutare la rappresentazione Adobe Commerce prevista usando evidenze controllate invece di dedurre il modello operativo da record migrati isolati.
Domande frequenti
Quale documento di preparazione Adobe Commerce dovrebbe essere creato per primo?
Iniziare dalla mappa del modello operativo per acquirente, website, store view, cataloghi, prezzi, inventario e sistemi esterni. Determina quali evidenze dettagliate e quali responsabili servono.
Come vanno preparate le Company B2B?
Preparare identità Company, administrator, users, team, ruoli, permessi, credito, contesto purchase order, assegnazioni catalogo e ID esterni come record collegati. Non ridurre la Company a un normale Customer Group.
Quali evidenze servono per gli shared catalogs?
Fornire appartenenza al catalogo, assegnazione Company, visibilità Product, fonte prezzo, eccezioni ed esempi Product/acquirente. Ogni catalogo deve avere un proprietario commerciale chiaro.
Come vanno preparati i configurable Products?
Documentare Product padre, child simple Products, attributi di variazione, SKU, stock, prezzi, immagini e identificatori esterni. Identificare inoltre valori di origine che sono descrizioni o input personalizzati e non vere variazioni.
Quali record di inventario richiedono particolare preparazione?
Dare priorità a SKU multi-source, child SKU configurable, location pickup o drop-ship, backorder e inventario sincronizzato esternamente. Ogni quantità deve avere una relazione dichiarata con source, stock, website e sistema autorevole.
Quando la preparazione Adobe Commerce è completa?
Quando accessi e backup sono recuperabili, strutture B2B e catalogo hanno responsabile, route prioritarie e integrazioni sono documentate, i campioni rappresentativi sono selezionati e ogni decisione aperta ha un responsabile definito.