Una migrazione verso Gambio dovrebbe essere accettata soltanto quando lo store migrato può essere utilizzato con fiducia nell’ambiente Gambio selezionato come destinazione. Il numero di record non è sufficiente. I Products possono esistere senza il corretto funzionamento delle opzioni, le Categories possono essere importate senza sostenere la navigazione, le CMS Pages possono essere presenti senza mantenere elementi di fiducia o continuità SEO e gli Orders storici possono risultare leggibili senza conservare il contesto commerciale che l’azienda si aspetta.
La validazione è particolarmente importante perché Gambio può corrispondere a due diversi modelli operativi. Gambio Cloud riduce la responsabilità per hosting, installazione, aggiornamenti e gestione del supporto, mentre Gambio self-hosted offre maggiore flessibilità e potenziale di personalizzazione ma assegna all’azienda o al team tecnico la responsabilità di hosting, manutenzione e aggiornamenti. Un piano di validazione che ignora questa differenza può approvare una migrazione apparentemente completa ma non coerente con il modo in cui lo store dovrà essere gestito dopo il lancio.
L’obiettivo della validazione non è esaminare ogni record singolarmente. Deve invece dimostrare che i record rappresentativi funzionano correttamente, che i presupposti specifici della piattaforma siano visibili prima del lancio e che gli eventuali aspetti ancora aperti vengano classificati prima dell’esecuzione più ampia della migrazione. Per Gambio significa verificare prima il modello operativo, poi il funzionamento del catalogo, il significato di Customers e Orders, la continuità della vetrina, i confini delle integrazioni e le decisioni sull’ambito.
Cosa deve dimostrare la validazione per Gambio
La validazione per Gambio deve dimostrare che i record migrati mantengano il loro significato dopo l’ingresso nella piattaforma di destinazione. Un Product non è soltanto nome e prezzo. Può includere immagini, opzioni, funzionamento dello stock, gestione dei Products scaricabili, collocazione nelle Categories, implicazioni fiscali e di spedizione e modalità di manutenzione nell’area amministrativa. Anche un record Customer non è soltanto un indirizzo email: può includere indirizzi, storico Orders, significato del gruppo Customer, contesto del consenso e interpretazione commerciale.
La validazione deve inoltre dimostrare che l’ambiente operativo selezionato supporti le aspettative dell’azienda. Chi passa a Gambio Cloud deve verificare che i dati migrati siano compatibili con il modello di configurazione e supporto disponibile nell’ambiente Cloud. Chi passa a Gambio self-hosted deve invece verificare che preparazione del server, gestione degli aggiornamenti, funzionamento personalizzato e responsabilità tecniche non restino presupposti nascosti da affrontare dopo il lancio.
L’approccio più solido separa tre livelli: record migrati, configurazione dello store di destinazione e funzionamento non appartenente alla migrazione. I record migrati sono i dati compresi nell’ambito di migrazione accettato. La configurazione dello store di destinazione comprende le impostazioni necessarie in Gambio affinché quei dati funzionino correttamente. Il funzionamento esterno alla migrazione include codice personalizzato, configurazione dei marketplace, configurazione dei fornitori di pagamento, modifiche a livello server e logiche di servizi esterni che possono richiedere attività separate.
| Livello di validazione | Cosa deve essere dimostrato | Motivo specifico per Gambio |
|---|---|---|
| Record migrati | Products, Categories, Customers, Orders, immagini, CMS Pages e altri dati selezionati arrivano con una struttura utilizzabile. | Il funzionamento del catalogo e dei contenuti Gambio dipende da più della semplice presenza dei record. |
| Configurazione della destinazione | Funzionamento dello stock, visualizzazione delle opzioni, impostazioni del processo di acquisto, pagamenti, spedizioni, imposte e contenuti legali o di fiducia sono configurati per l’uso. | Queste aree richiedono spesso configurazione dello store dopo la migrazione dei dati. |
| Modello operativo | Le responsabilità Cloud o self-hosted sono chiare prima del lancio. | Hosting, aggiornamenti, supporto, personalizzazione e manutenzione comportano responsabilità diverse. |
| Funzionamento esterno | Collegamenti ai marketplace, fornitori di pagamento, funzioni personalizzate e logiche di integrazione non sono trattati come record migrati. | Queste esigenze possono richiedere configurazione, lavoro di partner o revisione della gestione non standard. |
Prima dell’esecuzione più ampia della migrazione occorre utilizzare un test rappresentativo per verificare questi livelli. Se il campione contiene soltanto Products semplici, Customers ordinari e Orders lineari, non mostrerà se lo store reale è pronto. Il campione di validazione deve includere complessità rappresentative: opzioni, più immagini, Categories profonde, Products sensibili allo stock, Products scaricabili, pagine di contenuto, Orders più vecchi, gruppi Customer, Products collegati ai marketplace e record legati a funzionamento personalizzato.
Validare il modello operativo di Gambio
La prima priorità di validazione è il modello operativo. Sia Gambio Cloud sia Gambio self-hosted possono essere destinazioni valide, ma richiedono prove diverse. La validazione Cloud deve confermare che lo store possa funzionare in un ambiente gestito in cui hosting, installazione, aggiornamenti e supporto rientrano nel pacchetto. La validazione self-hosted deve confermare che l’azienda disponga della responsabilità tecnica necessaria per mantenere lo store dopo la migrazione.
Questo conta perché risultati identici a livello di record possono produrre rischi di lancio molto diversi. Un Product con funzionamento personalizzato può apparire correttamente in entrambi gli ambienti, ma la sua gestione futura dipende dal fatto che l’azienda privilegi la semplicità del Cloud o la flessibilità del self-hosting. Una pagina di contenuto della vetrina può migrare, ma la responsabilità per adeguamento del layout, aggiornamento dei testi legali o funzionamento del template può cambiare. Un Order con riferimenti di pagamento può restare leggibile, ma il fornitore di pagamento richiede comunque configurazione lato destinazione.
La validazione deve quindi includere una verifica della preparazione dell’ambiente. L’azienda deve confermare se il futuro store sarà Cloud o self-hosted, chi sarà responsabile degli aggiornamenti, chi manterrà lo store, chi gestirà i problemi tecnici e quali personalizzazioni dello store precedente dovranno essere dismesse, configurate, ricostruite o riesaminate separatamente. Questa verifica non sostituisce la configurazione tecnica; impedisce però di giudicare il risultato della migrazione rispetto a un’aspettativa sbagliata.
| Decisione Gambio | Domanda di validazione | Segnale di preparazione al lancio |
|---|---|---|
| Gambio Cloud | Lo store migrato è compatibile con il modello operativo orientato al Cloud? | Nessun requisito critico dipende da personalizzazioni lato server non supportate. |
| Gambio self-hosted | È stata assegnata la responsabilità tecnica? | Hosting, manutenzione, aggiornamenti, sicurezza e funzionamento personalizzato hanno responsabili definiti. |
| Aspettativa di supporto dello store | L’azienda si aspetta supporto su dati, impostazioni o sviluppo personalizzato? | Le domande sono separate tra problemi di migrazione, attività di configurazione e requisiti personalizzati. |
| Pianificazione degli aggiornamenti | Lo store può rimanere manutenibile dopo il lancio? | Nessuna struttura migrata dipende da funzionamento obsoleto o non documentato dello store precedente. |
La condizione di superamento è semplice: il team di validazione deve poter spiegare cosa ricade sotto la responsabilità di Gambio, cosa resta in capo all’azienda o al team tecnico e cosa copre l’ambito di migrazione accettato. Se questi confini non sono chiari, la migrazione può anche essere tecnicamente corretta, ma non è pronta per il lancio.
Validare struttura del catalogo e funzionamento dei Products
La validazione del catalogo deve confermare che i Products restino utilizzabili, manutenibili e comprensibili in Gambio. La piattaforma può gestire molti articoli, immagini, Categories, livelli di Category, opzioni Product, articoli scaricabili e stock. Queste funzioni hanno valore soltanto se il catalogo migrato viene verificato rispetto al modo in cui l’azienda vende realmente.
Il campione deve includere Products semplici e complessi. I Products semplici confermano il funzionamento di base della migrazione. Quelli complessi rivelano se logica delle opzioni, gestione delle immagini, regole di stock, impostazioni dei Products scaricabili e collocazione nelle Categories si trasferiscono correttamente. Se lo store di origine utilizzava Products configurabili, prezzi specifici per variante, bundle, stock specifico per opzione, attributi personalizzati o campi di catalogo orientati ai marketplace, questi record devono entrare nel test rappresentativo.
Un Product va controllato da tre prospettive. Dal punto di vista amministrativo, l’azienda deve poterlo mantenere dopo la migrazione. Dal punto di vista dell’acquirente, il Product deve poter essere trovato, compreso, selezionato e acquistato. Dal punto di vista operativo, stock, contenuti scaricabili, prezzi, spedizione e contesto dell’Order devono funzionare come previsto.
| Area del catalogo | Cosa validare | Segnale di errore |
|---|---|---|
| Identità del Product | Nome, SKU o numero articolo, prezzo, immagini, descrizione, stato e assegnazione alle Categories. | Il Product esiste ma non può essere gestito o riconosciuto con sicurezza. |
| Opzioni e selezioni | Taglia, colore o altre scelte appaiono chiaramente agli acquirenti. | Le opzioni vengono mostrate come attributi piatti oppure perdono significato su prezzo, selezione o acquisto. |
| Funzionamento dello stock | L’inventario viene ridotto o controllato secondo le aspettative dell’azienda. | I valori di stock esistono ma non corrispondono alla logica di acquisto o evasione. |
| Products scaricabili | Gli articoli digitali restano distinguibili dai Products ordinari. | La gestione dei Products digitali viene ridotta a un semplice campo descrittivo. |
| Profondità delle Categories | Categories e sottocategorie mantengono la logica di navigazione. | I Products sono presenti ma la navigazione diventa troppo piatta, duplicata o confusa. |
La validazione non deve terminare con il confronto del numero di Products. Deve produrre evidenze che i Products possano essere gestiti, trovati, selezionati, acquistati ed evasi. Se i Products complessi non superano questa verifica, il problema deve essere classificato prima dell’esecuzione più ampia come problema di mappatura, configurazione della destinazione, necessità di un adeguamento di migrazione approvato, requisito di gestione non standard oppure attività di implementazione separata.
Validare Customers, Orders e significato commerciale
La validazione di Customers e Orders deve dimostrare che lo storico commerciale resti leggibile e utile. In Gambio, un account Customer migrato non deve conservare soltanto l’identità. Deve mantenere abbastanza contesto su account, indirizzi e gruppo Customer da permettere all’azienda di interpretarlo correttamente dopo il lancio. Un Order migrato non deve conservare soltanto i totali. Deve mantenere righe, sconti, imposte, spedizione, contesto del pagamento, stato dell’Order e le note o i riferimenti storici necessari per assistenza e riconciliazione.
La scelta del campione richiede attenzione. Deve includere Customers ricorrenti, Customers con più indirizzi, Customers appartenenti a gruppi diversi, non registrati se rilevanti, Orders con sconti, variazioni fiscali, Orders rimborsati o annullati, Orders sensibili alla spedizione e Orders contenenti Products con opzioni o articoli scaricabili. Se vengono controllati soltanto Orders recenti e lineari, lo storico più vecchio o atipico può fallire dopo il lancio.
La domanda centrale è se l’azienda possa rispondere alle comuni domande operative dopo la migrazione. Che cosa ha acquistato questo Customer? Quali opzioni sono state selezionate? Quale contesto fiscale e di spedizione era applicabile? L’Order aveva uno sconto? Il Product era fisico o scaricabile? Lo storico Orders è sufficiente per l’assistenza? Se per rispondere è necessaria un’interpretazione manuale fuori da Gambio, l’Order può essere presente ma non pienamente utilizzabile.
| Record commerciale | Obiettivo della validazione | Condizione di superamento |
|---|---|---|
| Account Customer | Identità, indirizzi, significato del gruppo Customer e collegamento agli Orders. | Il personale riconosce il Customer e può consultarne uno storico utile. |
| Order storico | Products, opzioni, totali, sconti, imposte, spedizione, contesto del pagamento e stato. | Il personale interpreta l’Order senza dipendere dalla piattaforma precedente. |
| Storico sconti o coupon | Il contesto promozionale resta comprensibile. | Gli sconti non appaiono come differenze di totale prive di spiegazione. |
| Contesto fiscale e di spedizione | La logica commerciale storica resta leggibile. | I totali degli Orders possono essere riconciliati e spiegati. |
| Orders con Products misti | Articoli fisici, con opzioni e scaricabili restano distinguibili. | Il personale comprende cosa è stato venduto ed evaso. |
La validazione deve distinguere la leggibilità storica dalla configurazione attiva. Gli Orders storici migrati non configurano automaticamente il nuovo processo di acquisto, pagamenti, spedizioni, imposte, sconti o evasione degli ordini in Gambio. Se l’azienda si aspetta che il funzionamento attivo corrisponda allo store precedente, tali aspettative devono essere verificate come configurazione della destinazione o implementazione separata, non approvate soltanto perché lo storico Orders è stato migrato.
Validare contenuti della vetrina, navigazione e continuità nella ricerca
La validazione Gambio deve includere i contenuti della vetrina perché influenzano fiducia, certezza legale, visibilità nella ricerca e conversione. CMS Pages, pagine editoriali, descrizioni delle Categories, etichette di navigazione, descrizioni Product, metadati, immagini e link interni possono determinare quanto completo risulti il nuovo store dopo la migrazione.
Questo è particolarmente importante per aziende provenienti da store in cui pagine legali, landing page, guide all’acquisto, contenuti della homepage, testi di Category o elementi che rafforzano la fiducia sono strettamente legati al layout della vetrina. Gambio consente regolazioni del design e gestione dei contenuti dall’area amministrativa, ma i contenuti migrati devono comunque essere verificati per collocazione, formattazione, funzionamento dei link e leggibilità per il Customer.
La continuità nella ricerca deve essere verificata a livello di URL e contenuto. URL dei Products, URL delle Categories, URL delle pagine di contenuto, metadati, link interni e redirect devono essere riesaminati rispetto all’ambito di migrazione. Se gli URL cambiano, il team di validazione deve stabilire se servono pianificazione dei redirect, revisione dei metadati o adeguamenti manuali dei contenuti. Uno store visivamente completo può comunque perdere valore nella ricerca organica se contenuti e URL non vengono controllati.
| Area della vetrina | Cosa validare | Evidenze da raccogliere |
|---|---|---|
| CMS Pages | Pagine legali, di fiducia, assistenza e informative sono presenti e leggibili. | Elenco pagine, campioni renderizzati e controlli dei link interni. |
| Contenuti Product e Category | Descrizioni, immagini, metadati e testi delle Categories restano utilizzabili. | Campioni di Products e Categories provenienti dalle aree ad alto valore. |
| Navigazione | Categories, menu e link dei contenuti guidano gli acquirenti in modo coerente. | Verifiche dei percorsi di navigazione dalla homepage alle pagine Product. |
| Continuità SEO | URL, metadati, link interni e necessità di redirect sono noti. | Confronto tra URL importanti dello store precedente e nuovi percorsi di destinazione. |
| Contenuti sensibili al layout | I contenuti che dipendevano dal vecchio tema non sono considerati automaticamente renderizzati alla perfezione. | Screenshot o note di revisione per le pagine che richiedono adeguamento. |
La condizione di superamento non è che ogni pagina abbia lo stesso aspetto dello store precedente. Deve invece essere garantito che i contenuti importanti restino reperibili, leggibili e coerenti con le aspettative di lancio. Qualsiasi aggiornamento di design o testi legali fuori dall’ambito della migrazione deve essere classificato prima del lancio.
Validare integrazioni, personalizzazioni e dipendenze esterne
Molti store Gambio dipendono da collegamenti a marketplace, fornitori di pagamento, strumenti di spedizione, sistemi di remarketing, servizi per testi legali, strumenti di analisi, feed di prodotto o funzionalità personalizzate. La validazione deve chiarire quali di queste aspettative riguardino i dati migrati e quali richiedano configurazione lato destinazione o revisione separata.
Il rapporto tra marketplace e pagamenti è una fonte frequente di confusione. I dati Product possono migrare, ma spostare il record Product non implementa automaticamente il collegamento al marketplace. Lo storico Orders può migrare, ma la configurazione del fornitore di pagamento resta un’attività dello store di destinazione. Le pagine di contenuto possono migrare, mentre l’erogazione dei testi legali, il remarketing o il tracciamento esterno possono richiedere configurazione fuori dalla migrazione dei dati.
Le personalizzazioni introducono un ulteriore confine. Gambio self-hosted può offrire maggiore flessibilità per funzioni personalizzate o integrazioni specifiche, ma questo non significa che il funzionamento personalizzato della piattaforma di origine migri automaticamente. Le aziende orientate al Cloud devono essere ancora più attente a non presumere che il funzionamento personalizzato lato server possa essere trasferito come parte della normale migrazione dei dati.
| Tipo di dipendenza | Domanda di validazione | Classificazione probabile |
|---|---|---|
| Collegamento marketplace | I record Product e Order sono separati dalla configurazione del marketplace? | Configurazione della destinazione o implementazione separata. |
| Fornitore di pagamento | I dettagli storici del pagamento sono leggibili e la configurazione attiva è pianificata separatamente? | Configurazione della destinazione. |
| Strumento di spedizione | I record storici di spedizione sono leggibili e i metodi attivi sono configurati? | Configurazione della destinazione o configurazione dell’integrazione. |
| Codice personalizzato | Il funzionamento atteso dipende da logiche della piattaforma di origine o da modifiche lato server? | Revisione della gestione non standard o sviluppo separato. |
| Servizio legale o marketing | Il contenuto migrato è separato dal collegamento al servizio? | Configurazione della destinazione o configurazione del partner. |
Un risultato di validazione solido separa qualità dei dati e funzionamento del sistema. Se un record dipendente da un’integrazione appare corretto ma il servizio esterno non è configurato, la migrazione può essere accurata mentre il lancio resta incompleto. Questa distinzione deve essere visibile prima del lancio, non scoperta dai Customers dopo la messa online.
Usare evidenze del test rappresentativo e dell’esecuzione più ampia per decidere la preparazione al lancio di Gambio
I test rappresentativi devono esporre la struttura reale dello store Gambio, non offrire soltanto un’anteprima visiva. Il campione deve includere un Product semplice, una Product Option, una Product Variant con identificazione, stock, prezzo o immagine a livello di variante, un modello legacy di attributi o proprietà se presente, un Customer appartenente a un gruppo significativo, un Customer non registrato o registrato, un Order complesso, un record Content Manager, un percorso prioritario e un modulo o identificativo esterno.
L’esecuzione più ampia della migrazione deve dimostrare che l’interpretazione accettata resti completa sull’intero ambito approvato. Deve includere combinazioni Product rare, articoli disabilitati o non disponibili, Customers e Orders più vecchi, account non registrati, limitazioni per gruppo Customer, Products scaricabili o di servizio quando usati, contenuti multilingue, record gestiti da moduli e ogni percorso pubblico prioritario. Le evidenze degli Orders storici devono restare separate dalla configurazione attuale di pagamenti, spedizioni, imposte, email, processo di acquisto e integrazioni.
| Fase delle evidenze | Prova Gambio | Segnale di errore |
|---|---|---|
| Test rappresentativo della migrazione | Record rappresentativi confermano opzioni, varianti, gruppi Customer, proprietà dei contenuti, Orders e confine di responsabilità Cloud o self-hosted. | Il campione dimostra soltanto Products semplici e account Customer standard. |
| Esecuzione più ampia della migrazione | Record completi ed eccezionali seguono il modello Gambio approvato per catalogo, Customers, Orders, contenuti e integrazioni. | I conteggi coincidono ma varianti rare, Orders di Customers non registrati, restrizioni di gruppo o record dei moduli restano senza spiegazione. |
| Evidenze per il lancio | Gli scenari dell’area amministrativa e della vetrina sono ripetibili, le responsabilità sono assegnate e ogni risultato irrisolto ha una decisione. | Il risultato dipende dallo store di origine oppure da un modulo, host o responsabile dell’implementazione non definito. |
Le decisioni di lancio devono usare Pass, Watch o Block:
| Stato della decisione | Evidenza Gambio | Significato per il lancio |
|---|---|---|
| Pass | Il record migrato e le relative relazioni Gambio funzionano come previsto nell’ambiente Cloud o self-hosted selezionato. | L’area verificata supporta il lancio. |
| Watch | I dati sono utilizzabili, ma resta un’attività non bloccante documentata su tema, Content Manager, modulo, hosting, merchandising o configurazione. | Il lancio può procedere con un responsabile e una condizione di follow-up. |
| Block | Un Product o una variante rilevante non può essere acquistato, il trattamento del gruppo è errato, un Order è fuorviante, un percorso prioritario non funziona oppure un risultato concordato non è utilizzabile. | L’approvazione del lancio viene sospesa per l’area interessata. |
Ogni decisione deve indicare il Product, la variante, il Customer, l’Order, l’elemento di contenuto, il record del modulo, l’URL e lo scenario esatto usato come evidenza.
Rivalidare le azioni Gambio successive e i risultati concordati
Le azioni di migrazione successive cambiano il confine delle evidenze:
| Azione successiva | Confine di rivalidazione Gambio |
|---|---|
| Continuare con la configurazione accettata | Verificare che Products, opzioni, varianti, Customers, Orders, Blog Posts, record Content Manager, URL e riferimenti dei moduli successivi seguano le mappature approvate. |
| Continuare con configurazione rivista | Ricontrollare ogni filtro, mappatura, selezione del tipo di dati, decisione su opzioni o varianti, regola del gruppo Customer, destinazione dei contenuti e identificativo esterno modificati. |
| Produrre un nuovo risultato di migrazione distinto | Creare una nuova baseline di evidenze e ripetere test rappresentativi e decisioni sull’esecuzione più ampia della migrazione per il risultato distinto. |
I risultati acquistati della migrazione approvata devono essere verificati rispetto ai filtri, alle mappature o ai risultati di configurazione concordati. I risultati di migrazione non standard concordati devono essere verificati rispetto a campi personalizzati accettati, trasformazioni di attributi o proprietà legacy, record gestiti da moduli, identificativi esterni o relazioni su misura. Installazione dei moduli Gambio, hosting, implementazione del tema, configurazione attiva di pagamenti e spedizioni e distribuzione delle integrazioni restano separate salvo inclusione esplicita.
Conclusione
La validazione Gambio deve dimostrare più del trasferimento dei record. Deve provare che lo store migrato possa operare nell’ambiente Gambio selezionato con un catalogo utilizzabile, uno storico commerciale leggibile, contenuti della vetrina coerenti, confini di integrazione chiari e responsabilità di lancio note.
Il percorso di validazione più affidabile parte dal modello operativo, poi verifica funzionamento del catalogo, Customers e Orders, continuità dei contenuti e SEO, dipendenze esterne ed evidenze del test rappresentativo. Quando questi controlli sono completati con campioni rappresentativi e una classificazione chiara dei problemi, l’azienda può decidere se l’ambito dell’esecuzione più ampia è pronto o se sia necessario affrontare prima mappature, configurazione, adeguamenti di migrazione approvati, gestione non standard o attività di implementazione separate.
Domande frequenti
Il confronto del numero di Products è sufficiente per validare Gambio?
No. I conteggi non dimostrano il funzionamento di Product Option e Product Variant, l’interpretazione di attributi o proprietà legacy, il trattamento dei gruppi Customer, la leggibilità degli Orders, il posizionamento dei contenuti, la proprietà dei moduli o i percorsi della vetrina.
Gambio Cloud e Gambio self-hosted devono essere validati in modo diverso?
Sì. Le evidenze sui dati commerciali sono simili, ma la responsabilità operativa cambia. Per il self-hosted occorre inoltre assegnare la responsabilità per hosting, manutenzione tecnica, moduli locali, override e codice personalizzato, mentre la validazione Cloud deve rispettare i confini dell’ambiente gestito.
Quali record Gambio devono rientrare nelle evidenze del test rappresentativo?
Usare un campione difficile: opzioni, una Product Variant con valori indipendenti, strutture di catalogo legacy quando presenti, gruppi Customer, Customers registrati e non registrati, Orders complessi, record Content Manager, URL prioritari e identificativi di moduli o sistemi esterni.
Come vanno validati gli Orders storici Gambio?
Verificare righe, valori Product selezionati, contesto Customer o non registrato, indirizzi, totali, sconti, imposte, etichette di pagamento e spedizione, stati, documenti, resi o recessi quando inclusi e riferimenti esterni. Non dedurre la configurazione attiva dalle etichette storiche.
Quando un risultato Gambio va classificato come Block?
Usare Block quando il problema impedisce materialmente l’acquisto, applica un trattamento errato al gruppo Customer, rende fuorviante lo storico Orders, interrompe un percorso prioritario oppure rende inutilizzabile un adeguamento di migrazione approvato o un risultato di migrazione non standard.
Cosa deve essere rivalidato dopo un’azione di migrazione Gambio successiva?
Ricontrollare ogni Product, opzione, variante, Customer, Order, Blog Post, record di contenuto, URL, campo del modulo e identificativo esterno interessato. Una configurazione modificata o un nuovo risultato di migrazione distinto richiedono evidenze più ampie rispetto a una continuazione invariata.