Le migrazioni verso Gambio incontrano più spesso problemi quando la completezza dei conteggi viene confusa con la conservazione del funzionamento commerciale. La piattaforma può combinare relazioni di catalogo, regole dei gruppi Customer, contenuti multilingue, Orders, integrazioni e responsabilità operative gestite oppure self-hosted. Ciascun problema riportato di seguito isola un modello di errore ricorrente e definisce le evidenze necessarie per dimostrare che sia stato controllato.
Problema 1: scegliere il modello operativo senza assumersene le conseguenze
Cosa può andare storto
Gambio Cloud e un’installazione Gambio self-hosted possono rappresentare lo stesso catalogo ma assegnare responsabilità molto diverse per hosting, aggiornamenti, accesso al codice, estensioni e integrazioni personalizzate. Una migrazione può conservare Products e Orders e tuttavia fallire sul piano operativo quando l’azienda si aspetta la flessibilità del self-hosting da un ambiente gestito oppure presume una manutenzione gestita pur mantenendo codice personalizzato e dipendenze dal server.
Segnali di allarme iniziali
La destinazione viene descritta soltanto come “Gambio” senza indicare il modello operativo. Cron job esistenti, personalizzazioni a livello di file, script server o processi diretti sul database non hanno un responsabile futuro. Al contrario, una destinazione self-hosted non ha un responsabile definito per aggiornamenti, backup, monitoraggio e compatibilità delle estensioni.
| Segnale | Presupposto nascosto probabile | Conseguenza aziendale |
|---|---|---|
| Devono continuare script PHP personalizzati o job server | La destinazione richiede controllo su codice e infrastruttura | Un ambiente gestito potrebbe non poter riprodurre la dipendenza |
| Non viene assegnato alcun responsabile tecnico | Hosting e manutenzione sono considerati inclusi | Le operazioni self-hosted possono restare senza gestione |
| La scelta della destinazione si basa soltanto sulla compatibilità dei record | La responsabilità operativa è stata esclusa dalla decisione | Lo store può essere popolato ma non gestito in modo sostenibile |
Prevenzione
Registrare il modello operativo di destinazione prima di definire come dovrà continuare il funzionamento personalizzato. Separare i record migrati da hosting, manutenzione, aggiornamenti, installazione delle estensioni, accesso ai file, attività pianificate e integrazioni esterne. Per Gambio self-hosted, assegnare le responsabilità per infrastruttura e aggiornamenti. Per Gambio Cloud, individuare ogni requisito che dipende dall’accesso diretto a codice, server o database e stabilire se esista un percorso supportato equivalente.
Esempio di raccomandazione
Un’azienda utilizza ogni notte uno script server per arricchire i dati Product prima della pubblicazione. La migrazione conserva i campi Product, ma lo script viene trattato come dipendenza operativa separata. Il team lo assegna a un percorso di integrazione supportato oppure sceglie un ambiente nel quale il processo possa essere mantenuto deliberatamente.
Condizione di superamento
Il modello operativo della destinazione è definito, ogni dipendenza da infrastruttura o codice ha un responsabile e nessun processo aziendale critico dipende da un accesso o da una responsabilità di manutenzione che l’ambiente selezionato non offre.
Problema 2: appiattire proprietà, opzioni e differenze tra Products vendibili
Cosa può andare storto
I record Product in Gambio possono contenere normali dati descrittivi insieme a relazioni di opzioni o proprietà che cambiano ciò che l’acquirente seleziona e ciò che l’azienda deve evadere. Trattare ogni opzione dell’origine come attributo testuale può conservare le etichette ma perdere identità della combinazione, effetti sul prezzo, funzionamento dello stock, immagini, peso, tempi di spedizione o modello Product usato dai sistemi collegati.
Segnali di allarme iniziali
I Products semplici risultano corretti, ma quelli con più dimensioni di selezione producono scelte duplicate, combinazioni impossibili, un unico valore di stock condiviso oppure righe Order che non identificano la variante acquistata. Gli SKU o gli identificativi esterni dell’origine esistono a un livello più granulare del Product migrato.
| Modello osservato | Significato a rischio | Errore tipico |
|---|---|---|
| La scelta cambia SKU o stock | Identità della combinazione vendibile | Viene evaso l’articolo sbagliato |
| La scelta cambia soltanto la presentazione | Opzione di visualizzazione o valore descrittivo | Duplicazione non necessaria dei Products |
| La combinazione di proprietà ha prezzo o immagine propri | Dati commerciali specifici della combinazione | Il prezzo nel carrello o l’immagine non corrispondono alla selezione |
Prevenzione
Classificare i valori dell’origine per funzione: informazione descrittiva, selezione dell’acquirente, combinazione vendibile, personalizzazione inserita dall’acquirente o chiave per un sistema esterno. Conservare le relazioni tra Product principale e combinazioni e tutti gli effetti commercialmente rilevanti. Non dedurre l’identità della combinazione soltanto dalle etichette quando esiste uno SKU stabile, un numero modello o un identificativo dell’origine.
Esempio di raccomandazione
Un cavo configurabile utilizza lunghezza e tipo di connettore. Ogni combinazione valida ha un numero modello, una quantità di stock e un prezzo distinti. Mantenere un unico Product principale per il merchandising, ma conservare l’insieme delle combinazioni valide e i relativi identificativi operativi invece di creare scelte libere scollegate dall’inventario.
Condizione di superamento
Ogni Product complesso rappresentativo espone soltanto scelte valide, aggiunge al carrello il prezzo e l’identità articolo previsti, conserva il corretto proprietario dello stock e resta riconducibile all’identificativo utilizzato dai sistemi di evasione o inventario.
Problema 3: conservare le Categories ma compromettere la scoperta dei Products
Cosa può andare storto
Un albero di Categories può risultare completo nei conteggi ma indebolire la scoperta da parte degli acquirenti. I Products possono appartenere a più Categories, i rami profondi possono avere un significato di navigazione e contenuti o URL delle Categories possono contribuire a merchandising e visibilità nella ricerca. Appiattire la gerarchia, conservare una sola assegnazione o ricreare i nomi senza il contesto dei percorsi può rendere i Products difficili da trovare.
Segnali di allarme iniziali
Il numero di Categories coincide, ma Products rappresentativi scompaiono dai percorsi di navigazione previsti. I breadcrumb cambiano in modo inatteso, compaiono Categories duplicate, i rami profondi restano vuoti oppure le rotte delle Categories ad alto valore non hanno una destinazione chiara.
| Verifica | Modello di errore | Perché è importante |
|---|---|---|
| Struttura padre-figlio | I livelli vengono appiattiti o duplicati | Cambia il significato della navigazione |
| Assegnazioni Product | Viene conservata una sola Category | Scompaiono percorsi di merchandising incrociato |
| Percorso e contenuto della Category | Il nome esiste senza una destinazione equivalente | Si indeboliscono SEO e percorsi di ingresso degli acquirenti |
Prevenzione
Mappare separatamente gerarchia e assegnazioni Product. Identificare relazioni principali e aggiuntive con le Categories, nomi localizzati, descrizioni, immagini e percorsi prioritari. Disattivare rami obsoleti soltanto dopo aver definito una destinazione esplicita. Usare Products rappresentativi provenienti dai livelli superiore, intermedio e più profondo per verificare che i percorsi di navigazione previsti restino possibili.
Esempio di raccomandazione
Un Product appartiene a “Outdoor”, “Camping” e a una Category promozionale stagionale. Conservare l’identità stabile del Product e tutte le assegnazioni previste, definendo quale percorso sia principale per i breadcrumb e quale percorso stagionale debba restare attivo oppure reindirizzato.
Condizione di superamento
I Products rappresentativi sono raggiungibili attraverso ogni percorso Category previsto, gerarchia e breadcrumb sono coerenti, i percorsi dismessi hanno destinazioni deliberate e nessun Product viene esposto o nascosto perché un’assegnazione è stata eliminata senza decisione esplicita.
Problema 4: copiare i gruppi Customer senza i relativi permessi e prezzi
Cosa può andare storto
Gambio può collegare accesso ai Products, prezzi o trattamento commerciale ai gruppi Customer. Migrare Customers e nomi dei gruppi senza conservare le relazioni controllate genera account che appaiono classificati ma ricevono visibilità o prezzi predefiniti. Il problema è particolarmente grave per gruppi wholesale, riservati o con condizioni negoziate.
Segnali di allarme iniziali
I gruppi Customer esistono nell’area amministrativa, ma Products mostrano lo stesso prezzo e la stessa disponibilità a ogni acquirente. Campi relativi ai permessi del gruppo, regole di sconto o identificativi Customer esterni mancano oppure vengono ridotti a note.
| Relazione | Segnale di allarme | Effetto possibile |
|---|---|---|
| Customer → gruppo | L’appartenenza diventa soltanto un’etichetta | Il trattamento dell’account torna ai valori predefiniti |
| Gruppo → visibilità Product | Products riservati vengono mostrati ampiamente | Vengono compromessi i confini del catalogo privato |
| Gruppo → prezzo o sconto | Tutti i gruppi ricevono lo stesso risultato | Si perdono gli accordi commerciali |
Prevenzione
Documentare il risultato controllato da ciascun gruppo, non soltanto il nome. Conservare l’appartenenza Customer separatamente da permessi Product, relazioni di prezzo e configurazione della destinazione. Consolidare deliberatamente i gruppi obsoleti e mantenere gli identificativi esterni necessari a ERP, CRM o processi di gestione degli account.
Esempio di raccomandazione
Un gruppo di rivenditori può acquistare Products selezionati a prezzi negoziati. Conservare l’appartenenza al gruppo rivenditori, la relazione di accesso ai Products e la responsabilità sui prezzi. Non approvare il risultato soltanto perché il profilo Customer continua a mostrare “Dealer”.
Condizione di superamento
I Customers rappresentativi entrano nel contesto di gruppo previsto, vedono soltanto Products e condizioni commerciali corretti e conservano gli identificativi necessari ai sistemi collegati di gestione degli account senza ottenere accessi non intenzionali.
Problema 5: ridurre gli Orders a totali e nomi di stato
Cosa può andare storto
L’intestazione di un Order può sopravvivere mentre il significato storico viene perso. Attributi delle righe Product, sconti, imposte, spedizione, riferimenti di pagamento, codici di tracking, commenti e storico degli stati spiegano cosa è stato acquistato e cosa è successo in seguito. Copiare soltanto i totali e uno stato visivamente simile impedisce ad assistenza e finanza di ricostruire la transazione.
Segnali di allarme iniziali
Numero di Orders e totali complessivi sembrano plausibili, ma il personale non riesce a identificare la proprietà Product selezionata, spiegare uno sconto, seguire i riferimenti di spedizione o distinguere contesti di annullamento, reso e rimborso.
| Elemento Order | Modello di perdita | Impatto operativo |
|---|---|---|
| Attributi delle righe | Manca la scelta acquistata | Le decisioni su sostituzioni e assistenza diventano inaffidabili |
| Componenti del totale | Sconto, imposta o spedizione vengono appiattiti | La riconciliazione non spiega più il totale complessivo |
| Storico e tracking | Sopravvive soltanto lo stato attuale | Il personale non può ricostruire la sequenza della transazione |
Prevenzione
Conservare intestazioni Order, righe, attributi selezionati, componenti del totale, indirizzi, date, riferimenti dell’origine, note storiche e relazioni di tracking quando la destinazione può rappresentarli. Quando un flusso operativo dell’origine non ha equivalente, mantenere un contesto storico leggibile invece di inventare uno stato operativo attivo sulla destinazione.
Esempio di raccomandazione
Un Order restituito include due opzioni Product, un coupon, imposta sulla spedizione e un codice di tracking. Lo storico migrato conserva questi componenti e rende leggibile il contesto del reso, mentre il funzionamento attivo dei rimborsi resta un processo lato destinazione invece di essere dedotto dall’etichetta di stato precedente.
Condizione di superamento
Il personale può aprire Orders rappresentativi ordinari e con eccezioni, identificare esattamente cosa è stato acquistato, riconciliare il totale mostrato, comprendere lo stato storico e seguire i riferimenti conservati senza dover tornare allo store di origine.
Problema 6: trattare URL multilingue e metadati come testo decorativo
Cosa può andare storto
Descrizioni di Products e Categories, parole chiave negli URL, metadati, testo alternativo delle immagini e informazioni del processo di acquisto possono cambiare in base alla lingua. Scegliere una lingua come origine universale oppure copiare i testi tradotti senza conservare le relazioni tra percorsi può sovrascrivere significati specifici del mercato, creare percorsi duplicati o lasciare link interni diretti verso URL obsoleti.
Segnali di allarme iniziali
Una lingua è completa mentre un’altra contiene fallback, metadati in lingue diverse, slug mancanti o link interni interrotti. I percorsi Product e Category ad alto valore non dispongono di una mappa di destinazione specifica per lingua.
| Livello dei contenuti | Modello di errore | Effetto sul Customer |
|---|---|---|
| Nomi e descrizioni | Una lingua sovrascrive un’altra | Le pagine localizzate diventano incomplete |
| Parole chiave URL e metadati | I percorsi vengono rigenerati senza mappatura | Si interrompono gli ingressi organici e da segnalibri |
| Link interni e testo delle immagini | Link o testo alternativo conservano percorsi o lingua dell’origine | I contenuti diventano incoerenti o inaccessibili |
Prevenzione
Inventariare le lingue attive e classificare ogni campo traducibile. Mappare i percorsi Product, Category e dei contenuti specifici per lingua verso le destinazioni previste. Conservare identificativi stabili dei contenuti quando disponibili e creare relazioni di redirect per i percorsi prioritari invece di affidarsi alla generazione automatica degli slug.
Esempio di raccomandazione
Una pagina Product tedesca e la relativa versione inglese utilizzano slug e metadati diversi. Conservare entrambi i record linguistici, mappare ogni percorso separatamente e aggiornare i link interni affinché la pagina inglese non punti al vecchio percorso tedesco dell’origine.
Condizione di superamento
Ogni lingua attiva dispone di contenuti Product e Category completi, metadati coerenti, link interni funzionanti e una destinazione definita per ciascun URL prioritario dell’origine, senza sovrascritture tra lingue.
Problema 7: spostare CMS e informazioni del processo di acquisto senza il contesto della vetrina
Cosa può andare storto
CMS Pages, informazioni Product usate nel processo di acquisto, contenuti che rafforzano la fiducia e informazioni legali o di servizio possono essere presenti come record ma assenti nei punti in cui servono agli acquirenti. Posizioni del tema, menu, link nel footer, template Product e superfici del processo di acquisto sono separati dal contenuto stesso.
Segnali di allarme iniziali
Le pagine esistono nell’area amministrativa ma non sono raggiungibili dalla navigazione. Le informazioni specifiche per un Product durante il processo di acquisto mancano dal Product pertinente oppure i contenuti relativi alle politiche appaiono sotto un percorso generico senza il posizionamento previsto.
| Tipo di contenuto | Domanda di responsabilità separata | Errore se ignorata |
|---|---|---|
| CMS Page | Quale menu, footer o percorso la rende accessibile? | La pagina esiste ma non è raggiungibile |
| Informazioni Product per il processo di acquisto | Quali Products e quale fase di acquisto le utilizzano? | Le istruzioni importanti scompaiono |
| Contenuti di fiducia o policy | Quale posizione della vetrina li presenta? | I Customers non trovano le informazioni necessarie |
Prevenzione
Trattare record di contenuto, assegnazione, percorso e presentazione come relazioni separate. Conservare il contenuto e la relativa appartenenza a Product o navigazione, quindi ricostruire deliberatamente il posizionamento sulla destinazione. Riesaminare link interni e riferimenti multimediali come parte dello stesso percorso di contenuto.
Esempio di raccomandazione
Una famiglia di Products include istruzioni per misure personalizzate durante il processo di acquisto. Conservare il contenuto delle istruzioni e la relazione con i Products, quindi verificare che appaia nella fase di acquisto prevista invece di diventare una CMS Page non collegata.
Condizione di superamento
I contenuti prioritari sono corretti, raggiungibili attraverso il percorso previsto della vetrina, collegati ai Products o alle aree di navigazione corrette e privi di link utilizzabili soltanto nell’origine o dipendenze di presentazione non gestite.
Problema 8: conservare Products scaricabili senza il significato dell’evasione digitale
Cosa può andare storto
Un Product scaricabile è più di un riferimento a un file. Diritto di accesso, stato dell’Order, disponibilità del download, scadenza, numero di download, accesso Customer e sicurezza del file possono determinare se l’acquisto sia utilizzabile. Copiare soltanto Product e nome del file può esporre file prima del dovuto oppure rendere inaccessibili acquisti legittimi.
Segnali di allarme iniziali
I Products scaricabili appaiono nel catalogo, ma i Customers storici non hanno un contesto di accesso, i percorsi dei file puntano allo storage dell’origine oppure tutti gli stati Order concedono lo stesso diritto.
| Componente digitale | Rischio se appiattito | Risultato |
|---|---|---|
| Relazione con il file | Il percorso dell’origine viene copiato come testo | La risorsa non può essere erogata |
| Regola di diritto all’accesso | Si perdono stato Order e appartenenza Customer | L’accesso viene concesso o negato in modo errato |
| Scadenza o numero di download | Scompaiono i valori di controllo | La policy sui Products digitali cambia senza evidenza |
Prevenzione
Identificare ogni risorsa digitale, relazione con Product, condizione di accesso, esigenza di accesso storico e confine di sicurezza. Spostare le risorse attraverso un percorso di storage approvato e conservare soltanto lo storico degli accessi che la destinazione può rappresentare in modo sicuro. Separare le evidenze storiche dalle regole di accesso attive.
Esempio di raccomandazione
Un Product software consente tre download dopo il pagamento e scade dopo un periodo definito. Conservare Product e record storico dell’acquisto, quindi configurare esplicitamente il modello di accesso della destinazione invece di presumere che vecchio percorso file e stato Order ricreino l’accesso.
Condizione di superamento
I Customers autorizzati possono accedere alle risorse corrette secondo le condizioni previste, gli utenti non autorizzati non possono farlo, gli acquisti storici restano comprensibili e nessun percorso file dell’origine viene trattato come meccanismo di erogazione funzionante.
Problema 9: presumere che collegamenti di pagamento, spedizione e marketplace seguano i record
Cosa può andare storto
Products, Customers e Orders possono migrare senza ricreare credenziali di pagamento attive, servizi di spedizione, inserzioni marketplace, sottoscrizioni webhook o stato di sincronizzazione. I riferimenti storici possono essere utili, ma non attivano il servizio collegato in Gambio.
Segnali di allarme iniziali
Il progetto indica un gateway, un corriere, un marketplace o un ERP come “incluso” soltanto perché sono presenti Orders o ID Product correlati. Nessun responsabile ha confermato credenziali, accesso all’account, supporto dell’estensione sulla destinazione, contratti dei campi o flussi degli eventi.
| Dipendenza | Dati che possono restare | Funzionamento che richiede responsabilità separata |
|---|---|---|
| Fornitore di pagamento | Nome del metodo e riferimento della transazione | Credenziali, callback, regolamento, rimborsi |
| Corriere | Etichetta del servizio e numero di tracking | Tariffe, etichette, eventi di tracking |
| Marketplace o ERP | ID esterni e riferimenti storici | Inserzioni, sincronizzazione, regole di conflitto |
Prevenzione
Creare un registro delle dipendenze che identifichi il sistema di registrazione corrente, gli identificativi scambiati, le credenziali, la direzione degli eventi, la gestione degli errori e il responsabile sulla destinazione. Conservare gli ID esterni soltanto quando continuano a collegare i record. Riconfigurare o ricostruire il funzionamento attivo separatamente dallo storico migrato.
Esempio di raccomandazione
Gli Orders storici conservano un ID Order del marketplace e un riferimento di pagamento. Il connettore marketplace viene poi configurato con credenziali e regole di mappatura proprie; la presenza di quegli ID storici non viene considerata prova che la sincronizzazione sia attiva.
Condizione di superamento
Ogni collegamento necessario ha un responsabile, credenziali funzionanti, identificativi e percorsi degli eventi definiti e nessun funzionamento aziendale attivo viene dedotto soltanto dai record migrati o dalle etichette storiche.
Problema 10: trasferire personalizzazioni self-hosted come dati non esaminati
Cosa può andare storto
Gli store Gambio self-hosted possono contenere template modificati, moduli personalizzati, campi aggiuntivi nel database, attività pianificate o integrazioni dirette. Le esportazioni standard possono omettere i relativi dati, mentre copiare tabelle personalizzate senza comprendere il codice che le utilizza può conservare frammenti inutilizzabili o creare responsabilità in conflitto sulla destinazione.
Segnali di allarme iniziali
L’origine contiene colonne sconosciute, tabelle personalizzate, file modificati o report che dipendono da valori assenti dai normali record Product, Customer o Order. Nessuno sa indicare quale processo li legga o li scriva.
| Evidenza della personalizzazione | Domanda da risolvere | Presupposto non sicuro |
|---|---|---|
| Campo o tabella personalizzati | Quale processo aziendale li utilizza? | Ogni valore memorizzato deve essere copiato |
| Template/modulo modificato | Il funzionamento appartiene ancora alla destinazione? | Il codice può essere spostato insieme ai record |
| Integrazione pianificata | Quali ID ed eventi di modifica richiede? | Il job continuerà senza cambiamenti |
Prevenzione
Ricostruire per ogni personalizzazione il percorso dal valore memorizzato all’utilizzo aziendale. Classificarla come dato che deve continuare, configurazione della destinazione, stato di integrazione, logica di presentazione, riferimento storico o funzionamento obsoleto. Conservare le chiavi stabili quando servono a un sistema che continuerà a operare ed escludere residui tecnici orfani invece di copiarli senza responsabile.
Esempio di raccomandazione
Un campo Product personalizzato controlla l’imballaggio di magazzino ed è letto da un’esportazione ERP. Conservare il valore e la chiave Product esterna in un campo gestito dalla destinazione o in un contratto di integrazione. Non copiare la vecchia tabella del modulo se il processo sulla destinazione non la leggerà mai.
Condizione di superamento
Ogni campo, tabella, modulo e processo pianificato personalizzato ha uno scopo documentato e un responsabile sulla destinazione; i valori ancora necessari restano utilizzabili, i residui dismessi vengono esclusi deliberatamente e nessun processo critico dipende da codice dell’origine non identificato.
Priorità di prevenzione trasversali ai problemi
La sequenza di prevenzione più solida parte dalla responsabilità sul modello operativo, quindi passa a identità dei Products vendibili, scoperta, trattamento dei Customers, storico Orders, percorsi dei contenuti, evasione digitale, integrazioni e dati personalizzati. Queste aree devono restare collegate attraverso identificativi stabili e responsabilità esplicite. Un Product non può essere approvato in isolamento quando Category, permesso del gruppo, chiave esterna o diritto di accesso digitale non hanno ancora una relazione definita sulla destinazione.
Le tabelle di supporto evidenziano modelli di allarme, ma la decisione deve restare specifica per il record. Il team deve poter spiegare non soltanto che il dato esiste, ma come lo store di destinazione lo utilizzerà e quale sistema o configurazione separata sarà responsabile del funzionamento che non risiede nel record migrato.
Conclusione
Una migrazione Gambio affidabile conserva le relazioni che rendono i record commercialmente utilizzabili. Distingue la responsabilità Cloud da quella self-hosted, mantiene le scelte Product tracciabili dal punto di vista operativo, preserva scoperta multilingue e percorsi dei contenuti, conserva un contesto Customer e Order significativo e assegna ogni integrazione o personalizzazione a un responsabile reale. Superare i controlli sui totali dei record senza queste relazioni non è sufficiente.
Domande frequenti
Perché Gambio Cloud e Gambio self-hosted devono essere trattati in modo diverso?
Possono contenere record commerciali simili, ma differiscono per hosting, aggiornamenti, accesso al codice, estensioni personalizzate e responsabilità sull’infrastruttura. Queste differenze determinano se le personalizzazioni dell’origine e i processi operativi abbiano un responsabile sostenibile sulla destinazione.
Qual è il campione Product Gambio a rischio più elevato?
Usare un Product le cui scelte cambiano SKU, prezzo, stock, immagine o evasione. Un Product semplice non può mostrare se relazioni tra proprietà e combinazioni restino commercialmente utilizzabili.
I nomi dei gruppi Customer dimostrano che il funzionamento del gruppo è stato conservato?
No. Appartenenza, permessi Product, prezzi, sconti e relazioni fiscali devono ancora produrre l’esperienza Customer prevista. Un’etichetta senza i risultati che dovrebbe controllare è incompleta.
Come vanno riesaminati gli Orders storici Gambio?
Verificare attributi delle righe, componenti del totale, indirizzi, storico degli stati, tracking, commenti e riferimenti esterni. L’Order deve spiegare la transazione senza fingere che uno stato operativo precedente sia attivo sulla destinazione.
I record di pagamento e marketplace ricreano le relative integrazioni?
No. Nomi storici dei metodi e ID esterni possono essere conservati, ma credenziali, estensioni, flussi degli eventi, sincronizzazione e gestione degli errori richiedono responsabilità separata sulla destinazione.
Quando va escluso un campo Gambio personalizzato?
Escluderlo quando nessun processo che continuerà a operare lo legge e non possiede valore storico o di riconciliazione. Conservarlo soltanto quando scopo aziendale e responsabile sulla destinazione sono espliciti.