Se il progetto sceglie AmeriCommerce come piattaforma di destinazione, la preparazione deve rendere comprensibile lo Store di origine prima che la configurazione della migrazione venga finalizzata. Un’installazione può combinare più vetrine, restrizioni di active catalog, Customer Types, varianti, Product Groups, kit, prezzi avanzati, campi personalizzati, contenuti e sistemi esterni. Un’esportazione mostra ciò che esiste, ma non spiega quale vetrina possiede un record, quale regola dell’acquirente ne modifica il comportamento o quale identificatore deve restare disponibile per un altro sistema.
L’obiettivo è trasformare tali relazioni in evidenze controllate della sorgente. Per ogni area principale devono essere definiti l’azione da completare, il responsabile della risposta, l’evidenza da fornire e la condizione che rende l’area pronta. In questo modo lo stato della sorgente resta esplicito prima dell’avvio della configurazione della migrazione.
Stabilire gli accessi e definire il confine operativo di AmeriCommerce
Inizia documentando l’account AmeriCommerce esatto e ogni Store incluso nell’ambito. Registra accessi amministrativi, identificatori Store, domini attivi, valute, lingue, contesto fiscale, proprietà del tema corrente e responsabili di catalogo, Customers, Orders, marketing e integrazioni. Quando più Store condividono dati o usano active catalog diversi, la preparazione deve distinguere impostazioni e record globali da quelli specifici dello Store.
Le esportazioni AmeriCommerce possono essere filtrate per Store e configurate con colonne selezionate. Salva i criteri usati per ogni esportazione, così che ogni file possa essere ricondotto a Store, data e set di campi specifici. Non presumere che un’unica esportazione combinata conservi automaticamente la proprietà dello Store.
| Azione | Responsabile | Evidenza | Condizione di preparazione |
|---|---|---|---|
| Elencare ogni Store e dominio nell’ambito | Amministratore commerce | Elenco Store, identificatori, domini, stato, finalità aziendale | Ogni Store incluso ha un ruolo e un responsabile definiti. |
| Confermare l’accesso supportato alla sorgente | Responsabile accessi | Registro accessi amministrativi, permessi di esportazione, contatto tecnico | I record richiesti possono essere raccolti dall’account corretto. |
| Documentare comportamento condiviso e specifico per Store | Responsabile piattaforma | Nota comparativa su cataloghi, prezzi, contenuti e impostazioni | I dati condivisi sono distinguibili da quelli specifici dello Store. |
| Bloccare i criteri di esportazione | Responsabile dati | Nome export, filtro Store, data, colonne selezionate, hash del file | Ogni file sorgente può essere riprodotto e spiegato. |
| Avviare un registro delle modifiche alla sorgente | Responsabile progetto | Registro datato di modifiche a catalogo, Customers, Orders, URL e integrazioni | Le variazioni successive alla raccolta delle evidenze non verranno perse. |
Preparare Products, varianti, Groups, kit e relazioni di prezzo
I Products AmeriCommerce possono utilizzare varianti, inventario delle varianti, Product Groups, kit, prezzi avanzati, regole di quantità, prezzi per Customer Type e campi personalizzati. Durante la preparazione queste strutture non devono essere appiattite in una singola riga Product. Il team deve identificare quali record rappresentano scelte vendibili, quali raggruppamenti di presentazione e quali dipendono da una relazione di prezzo o inventario.
Crea un inventario Product che includa Product ID, item number o SKU, stato, visibilità per Store, collocazione nell’active catalog, Categories, manufacturer, prezzo base, tax class, quantità, peso, immagini, contenuti, varianti, relazioni Product Group, componenti kit, regole di prezzo e identificatori esterni. Scegli esempi per ogni modello Product materialmente diverso.
| Modello di origine | Azione di preparazione | Evidenza | Condizione di preparazione |
|---|---|---|---|
| Varianti Product | Registrare Variant Groups, valori, ordine di visualizzazione, obbligatorietà, effetti sul prezzo e assegnazione Product | Esportazione varianti e pagine Product rappresentative | Vocabolario delle scelte e proprietà Product completi. |
| Inventario delle varianti | Registrare SKU, quantità, prezzo, immagine, peso e stato a livello di combinazione dove utilizzato | Matrice combinazioni e campione stock | Le combinazioni vendibili gestite indipendentemente sono visibili. |
| Product Groups | Registrare Products parent/child, tipo di gruppo, vendibilità, prezzi, inventario e comportamento di spedizione | Export relazioni e screenshot | Il raggruppamento non viene confuso con una semplice variante. |
| Kit o offerte assemblate | Registrare componenti Product, quantità, comportamento del prezzo, ipotesi di stock e note di evasione | Elenco kit ed esempi componenti | Significato dei componenti e proprietà operativa documentati. |
| Prezzi avanzati o per Customer Type | Registrare pubblico, soglia quantità, date, formula/importo e Products interessati | Matrice delle regole di prezzo | I prezzi condizionali sono espliciti anziché dedotti dalle etichette. |
| Campi Product personalizzati | Classificare ogni campo come descrittivo, operativo, appartenente a integrazione o obsoleto | Dizionario campi con valori campione | I campi critici hanno una destinazione e un responsabile. |
Non unire nomi di opzioni o regole di prezzo simili solo per semplificare la sorgente. Due etichette apparentemente equivalenti possono differire per Store, Customer Type, proprietà dello stock o uso in sistemi esterni.
Documentare vetrine, active catalog, Categories e modalità di scoperta
AmeriCommerce può limitare il catalogo visibile per Store tramite impostazioni di active catalog. I Customer Types possono inoltre influenzare visibilità dei Products, contenuti, redirect, sconti e comportamento della spedizione. La preparazione richiede quindi più di un semplice albero Category: serve una mappa di visibilità che mostri quali acquirenti possono trovare quali Products in quale Store.
Prepara la gerarchia Category con ID, parent, stato, associazione Store, stato active catalog, assegnazioni Product, contenuti, immagini, ordine e URL importanti. Registra menu di navigazione, pagina di destinazione, percorsi manufacturer, modalità di scoperta basate sugli attributi e link interni separatamente dai record Category che li supportano.
| Area di scoperta | Responsabile | Evidenza | Condizione di preparazione |
|---|---|---|---|
| Active catalog per Store | Amministratore piattaforma | Screenshot o export specifici dello Store | Il confine Category visibile per ogni Store è documentato. |
| Gerarchia Category | Responsabile catalogo | Export parent-child ed elenco Categories mantenute | Ogni Category mantenuta ha parent e finalità noti. |
| Collocazione Product | Responsabile merchandising | Evidenza Product-to-Category e assegnazione Store | Collocazione condivisa e restrizioni Store sono visibili. |
| Visibilità per Customer Type | Responsabile B2B/account | Esempi di Products e Categories riservati | Le regole di accesso sono associate a record reali. |
| Menu e pagina di destinazione | Responsabile vetrina | Mappa di navigazione, screenshot e percorsi collegati | I percorsi di presentazione sono separati dalla struttura del catalogo. |
| URL prioritari | Responsabile SEO | Elenco percorsi Product, Category, contenuti e campagne | I percorsi ad alto valore hanno una destinazione documentata. |
Preparare Customers, Customer Types, account e indirizzi
I Customer Types AmeriCommerce possono influenzare prezzi, sconti, redirect dopo il login, premi, contenuti personalizzati, metodi di spedizione e Products nascosti. Un Customer Type va quindi preparato come relazione tra regole aziendali, non come semplice nome di gruppo. Registra quali Customers attivi appartengono a ciascun tipo e cosa cambia per quel tipo.
Prepara i Customers con ID, nomi, email, stato di login, indirizzi di fatturazione e spedizione, dettagli aziendali, Customer Type, stato fiscale, newsletter o comunicazioni, campi personalizzati, responsabilità commerciale/account e identificatori esterni. Identifica email duplicate, indirizzi aziendali condivisi, account inattivi e record il cui Customer Type non riflette più l’uso aziendale corrente.
| Area Customer | Azione di preparazione | Evidenza | Condizione di preparazione |
|---|---|---|---|
| Identità | Risolvere o documentare email duplicate e condivise | Registro eccezioni Customer | Le eccezioni di identità hanno responsabile e trattamento definiti. |
| Customer Types | Registrare appartenenza e ogni regola di prezzo, visibilità, redirect, spedizione o contenuto influenzata | Matrice regole Customer Type | Ogni tipo ha un significato aziendale documentato. |
| Indirizzi | Separare indirizzi Customer riutilizzabili dagli snapshot dell’Order | Esempi di indirizzi Customer e Order | I dati account correnti non vengono confusi con la cronologia transazionale. |
| Contesto fiscale/esenzioni | Registrare stato, responsabile dell’evidenza e Customers interessati | Elenco campione stato fiscale | Il trattamento fiscale speciale non è ridotto a una sola etichetta. |
| Campi personalizzati e ID esterni | Identificare sistema proprietario e uso downstream | Dizionario campi e riferimenti integrazione | Gli identificatori operativi restano tracciabili. |
Preparare Orders, stati, totali e contesto storico
La preparazione degli Orders deve preservare le evidenze necessarie ad assistenza Customer, finanza, evasione e team account. Seleziona Orders da ogni Store e includi esempi con varianti, Product Groups o kit, prezzi per Customer Type, sconti, differenze fiscali, spedizioni divise o insolite, rimborsi, cancellazioni, aggiustamenti manuali, note e riferimenti esterni.
Salva i criteri dell’esportazione Order e includi i campi necessari a interpretare righe, indirizzi, stati, etichette di pagamento e spedizione, imposte, sconti, commissioni e totali. Le etichette storiche devono essere documentate come contesto della sorgente, non trattate come istruzioni per configurare pagamenti o spedizioni attivi nella destinazione.
| Area Order | Azione | Evidenza | Condizione di preparazione |
|---|---|---|---|
| Proprietà Store | Includere l’identificatore Store nell’evidenza Order | Elenco campione Orders cross-Store | Ogni campione è riconducibile allo Store corretto. |
| Cronologia stati | Registrare etichette, sequenza, significato per lo staff e visibilità Customer | Dizionario stati e Orders rappresentativi | Gli stati storici sono interpretabili in modo coerente. |
| Dettaglio righe | Includere varianti selezionate, contesto kit/gruppo, quantità, SKU e prezzo | Campioni righe Order | La configurazione acquistata rimane comprensibile. |
| Totali e aggiustamenti | Identificare imposte, spedizione, sconto, commissioni, credito, rimborso e righe manuali | Inventario componenti totali | Gli aggiustamenti materiali hanno un significato noto nella sorgente. |
| Riferimenti esterni | Registrare ID ERP, contabilità, CRM, evasione o marketplace | Orders sensibili alle integrazioni | I requisiti di lookup downstream sono documentati. |
Non modificare gli Orders storici solo per renderli uniformi. Registra separatamente le anomalie quando spiegano la transazione originale.
Inventariare contenuti, integrazioni, automazioni e dati personalizzati
Prepara contenuti e dipendenze come inventari separati. Le evidenze dei contenuti devono includere pagine, blog o contenuti educativi, moduli, immagini, download, metadati, aspettative per gli URL canonici, link interni e redirect. Le evidenze delle dipendenze devono includere ERP, contabilità, CRM, imposte, spedizioni, inventario, evasione, marketplace, analisi, email e sistemi di informazioni Product.
Per ogni integrazione o processo automatizzato registra proprietario del sistema, direzione del flusso dati, pianificazione o trigger, identificatori utilizzati, campi letti o scritti e comportamento atteso durante il periodo di migrazione. Campi o script personalizzati vanno classificati per finalità aziendale, non raccolti senza interpretazione.
| Dipendenza | Responsabile | Evidenza | Condizione di preparazione |
|---|---|---|---|
| ERP o contabilità | Responsabile finanza/sistemi | Identificatori di articoli, Customers, Orders, fatture e imposte | Le chiavi di lookup richieste sono note. |
| Inventario o evasione | Responsabile operazioni | Codici magazzino, supplier ID, autorità sullo stock, riferimenti spedizione | Proprietà di stock ed evasione sono esplicite. |
| CRM o processo commerciale | Responsabile sistemi vendite | Campi azienda, contatto, account manager e contratto | Le relazioni account sono documentate. |
| Marketing e analisi | Responsabile marketing | Segmenti, percorsi campagna, riferimenti di tracking, campi consenso | I dati marketing hanno una decisione di inclusione chiara. |
| Logica personalizzata della sorgente | Sviluppatore o agenzia | Script, campi personalizzati, tabelle nascoste, job pianificati, procedure manuali | Il comportamento non standard ha responsabile e destinazione definiti. |
Preparare esportazioni, media, backup e controllo delle modifiche
Crea un archivio di evidenze datato, non una raccolta disordinata di file. Conserva esportazioni Product, Customer, Order, Category, contenuti, prezzi, campi personalizzati e integrazioni insieme a media, screenshot, criteri di esportazione e note esplicative. Mantieni invariati i file originali e svolgi pulizia o analisi su copie di lavoro.
| Set di evidenze | Contenuto richiesto | Condizione di preparazione |
|---|---|---|
| Esportazioni dati | File sorgente, criteri export, filtri Store, data, mappatura campi, checksum | I file sono completi e attribuibili. |
| Archivio media | Asset Product, Category, contenuti, documenti e download | I file originali possono essere collegati ai record sorgente. |
| Evidenza di configurazione | Screenshot/report di Store, active catalog, Customer Type, prezzi, stati e imposte | Le regole non presenti nelle normali esportazioni sono documentate. |
| Nota di backup e ripristino | Backup piattaforma disponibili, export scaricati, archivio media, contatti account | Le evidenze della sorgente possono essere recuperate in caso di dubbi. |
| Registro modifiche | Products, Customers, Orders, URL, regole e integrazioni nuovi o modificati dopo la raccolta | Le modifiche successive possono essere riconciliate. |
Selezionare record rappresentativi per il test di migrazione
Scegli i record di test in modo deliberato. Il campione deve includere record ordinari e strutture con maggiore probabilità di rivelare problemi di ambito o mappatura. Per AmeriCommerce significa normalmente includere record provenienti da Store, active catalog, Customer Types, modelli Product e contesti di integrazione differenti.
| Gruppo campione | Includere | Scopo della preparazione |
|---|---|---|
| Products | Product semplice, Product con varianti, Product con inventario variante, Product Group, kit, Product ristretto, Product con prezzi avanzati | Esporre relazioni diverse di catalogo e prezzo. |
| Customers | Acquirente standard, Customer Type speciale, account tax-exempt, account aziendale/gestito, eccezione email duplicata | Rappresentare differenze di identità e regole dell’acquirente. |
| Orders | Store, stati, sconti, casi fiscali, rimborsi, righe kit/gruppo e riferimenti esterni differenti | Preservare il contesto operativo storico. |
| Contenuti e URL | Percorsi prioritari Product, Category, pagina, campagna e redirect | Preparare decisioni su percorsi e contenuti. |
| Integrazioni | Record Product, Customer e Order contenenti ID esterni | Confermare che le evidenze sorgente richieste siano incluse. |
Per ogni campione scrivi una breve aspettativa della sorgente che descriva relazioni, campi, file collegati e identificatori che lo rendono rappresentativo.
Completare il gate di preparazione per AmeriCommerce
La preparazione è completa quando le evidenze della sorgente possono rispondere alle domande che governano l’ambito della migrazione. Il team deve saper identificare ogni Store, spiegare regole di active catalog e Customer Type, distinguere strutture Product, interpretare Orders storici, localizzare media e contenuti e nominare il responsabile di ogni integrazione materiale.
| Gate finale | Condizione di preparazione |
|---|---|
| Ambito Store | Ogni Store incluso e ogni confine dei dati condivisi è documentato. |
| Catalogo | Strutture Product, regole di prezzo, visibilità e Categories sono rappresentate da evidenze. |
| Customers | Customer Types, eccezioni di identità, indirizzi, contesto fiscale e ID esterni sono compresi. |
| Orders | Proprietà Store, stati, righe, totali e riferimenti esterni sono interpretabili. |
| Contenuti e URL | Pagine prioritarie, media, metadati e decisioni sui percorsi sono registrati. |
| Dipendenze | Integrazioni, automazioni e dati personalizzati hanno responsabili e destinazioni. |
| Input | Esportazioni, media, criteri, checksum, backup e registro modifiche sono disponibili. |
| Campioni | I record rappresentativi coprono modelli di origine ordinari e complessi. |
Conclusione
Preparare una migrazione verso AmeriCommerce significa rendere visibile come Store, active catalog, Customer Types, strutture Product, prezzi, Orders, contenuti e sistemi esterni lavorano insieme. Il pacchetto di preparazione più solido non è quello con il maggior numero di esportazioni, ma quello che preserva proprietà e significato attraverso queste relazioni.
Quando accessi, esportazioni, regole aziendali, campioni rappresentativi e controllo delle modifiche sono completi, la configurazione della migrazione può procedere sulla base di una sorgente documentata anziché di supposizioni.
Domande frequenti
Le esportazioni AmeriCommerce devono essere combinate tra tutti gli Store?
Solo quando la proprietà dello Store rimane esplicita. Mantieni filtro Store, criteri di esportazione e identificatore Store con ogni file, così che record condivisi e specifici possano ancora essere distinti.
Perché i Customer Types devono essere documentati separatamente dai Customers?
Perché possono influenzare prezzi, sconti, contenuti, redirect, spedizioni e visibilità dei Products. L’appartenenza da sola non spiega la regola controllata dal tipo.
Quali Products devono avere priorità nella preparazione?
Includi Products semplici, varianti, Products con inventario variante, Product Groups, kit, Products riservati, casi di prezzi avanzati e record con identificatori esterni.
I Products vecchi o inattivi devono essere eliminati prima della migrazione?
Non automaticamente. Classificali come includere, escludere, archiviare o sottoporre a revisione aziendale. Eliminarli in anticipo può rimuovere evidenze necessarie a comprendere Orders storici o integrazioni.
Cosa deve essere preservato con gli Orders storici?
Proprietà Store, configurazione delle righe, stati, indirizzi, totali, sconti, imposte, etichette di pagamento e spedizione, note e riferimenti esterni necessari ai team operativi.
Come vanno gestite le modifiche alla sorgente dopo la creazione delle esportazioni?
Mantieni un registro datato e identifica il responsabile di ogni area modificata. Il registro deve coprire variazioni a catalogo, Customers, Orders, URL, prezzi e integrazioni che possono cambiare il set di evidenze preparato.