I requisiti di migrazione non standard sono difficili per una ragione che i semplici conteggi dei record non mostrano: i dati spesso contengono un significato che non è visibile nel solo nome del campo. Un valore Product personalizzato può influenzare ricerca, prezzi o evasione. Un identificatore Order esterno può collegare lo store alla contabilità. Un record appartenente a un’applicazione può rappresentare un abbonamento, un saldo loyalty, un venditore marketplace o un processo operativo.
Spostare il valore senza comprenderne il ruolo può produrre uno store di destinazione che sembra completo ma non supporta più l’azienda. Nei Migration Services Next-Cart, Custom Service affronta questo divario trasformando un requisito non standard in un risultato di migrazione concordato, con dati di origine definiti, rappresentazione nella destinazione, lavoro su misura e criteri di accettazione.
L’obiettivo non è etichettare l’intero progetto come personalizzato. È individuare le aree specifiche in cui comportamento supportato e Standard Add-ons non sono sufficienti e definire che cosa debba significare un risultato migrato utilizzabile.
Individua perché il requisito non è standard
Un requisito può richiedere Custom Service per via della sua origine, struttura, logica, relazione o destinazione.
| Fonte della difficoltà | Domanda di fondo |
|---|---|
| Custom Platform | Come possono essere compresi e raggiunti i modelli dati di origine o destinazione? |
| Campi o tabelle personalizzati | Quale significato aziendale hanno i valori e a quali record appartengono? |
| Dati di applicazioni, plugin, moduli o estensioni | I dati sono autorevoli e quale processo futuro ne ha bisogno? |
| Identificatori esterni | Quale relazione con un altro sistema deve rimanere collegata dopo la migrazione? |
| Trasformazione su misura | Come devono essere combinati, separati, normalizzati o ristrutturati valori o record? |
| Relazioni non standard | Come devono essere rappresentate proprietà e riferimenti nella piattaforma di destinazione? |
| Comportamento Add-on modificato o nuovo | Perché lo Standard Add-on disponibile non può produrre il risultato richiesto? |
| Limite della destinazione | Qual è la rappresentazione utilizzabile più vicina e quale implementazione resta separata? |
Queste domande rendono spiegabile l’ambito personalizzato. “Migrare tutti i dati personalizzati” non lo fa. Un requisito utile identifica i record interessati, il loro scopo aziendale futuro, il risultato previsto nello store di destinazione e gli elementi che dimostreranno il successo.
Il lavoro su una Custom Platform parte dal modello dati
Una Custom Platform può essere la piattaforma di origine, la piattaforma di destinazione o entrambe. La difficoltà non consiste soltanto nello stabilire l’accesso. La migrazione deve capire come lo store rappresenta Products, Customers, Orders, contenuti, relazioni e strutture di supporto.
Tra gli elementi utili dell’origine possono rientrare:
- descrizioni dello schema o delle esportazioni;
- Products, Customers, Orders e contenuti rappresentativi;
- chiavi primarie e chiavi esterne;
- relazioni tra Categories e navigazione;
- valori di stato o tipo personalizzati;
- riferimenti a media e file;
- informazioni sui sistemi esterni;
- esempi dei risultati aziendali che devono continuare.
La revisione dovrebbe quindi confrontare il significato nell’origine con le capacità della piattaforma di destinazione. Alcuni record possono avere un equivalente diretto. Altri possono richiedere trasformazione, mappatura di campi, una struttura personalizzata nella destinazione oppure esclusione accompagnata da un’alternativa documentata.
Custom Service non rende possibile ogni rappresentazione nella destinazione. Offre un metodo disciplinato per stabilire che cosa può essere migrato, che cosa deve cambiare e che cosa il cliente deve aspettarsi.
Tratta i dati di terze parti come un problema di proprietà
Gli store dipendono spesso da dati creati da applicazioni, plugin, moduli, estensioni o servizi collegati. La presenza di una tabella o di un campo non dimostra che debbano essere migrati. Alcuni record sono autorevoli. Altri sono cache, log, valori derivati o residui di funzionalità abbandonate.
La revisione personalizzata dovrebbe stabilire:
- quale sistema possiede i dati;
- quale processo aziendale li utilizza;
- se restano autorevoli;
- a quale record migrato appartengono;
- che cosa dovrebbe farne lo store di destinazione o il sistema collegato;
- come verrà validato il risultato.
Questo controllo della proprietà è più affidabile che copiare ogni campo non standard. Dati senza un proprietario futuro possono creare disordine o conflitti. Dati con un ruolo operativo continuo possono essere critici anche quando occupano un solo campo.
Esempi includono:
- identificatori di abbonamento collegati a Products o Customers;
- saldi loyalty collegati all’identità Customer;
- proprietà del venditore marketplace collegata a Products e Orders;
- riferimenti di evasione collegati alle righe Order;
- identificatori PIM collegati ai record Product;
- classificazioni di reporting collegate a Products, Customers o Orders.
Preserva gli identificatori esterni attraverso le loro relazioni
Un identificatore esterno è utile soltanto se sopravvive la relazione a cui serve. Copiare un ID Product ERP in un campo di testo arbitrario può preservare i caratteri ma interrompere il processo che ne dipende.
L’ambito personalizzato dovrebbe definire:
- il sistema proprietario dell’identificatore;
- il record migrato a cui fa riferimento;
- requisiti di unicità e formato;
- se il valore può cambiare;
- la destinazione compatibile nel target;
- il processo di integrazione o reporting che lo utilizzerà;
- gli elementi necessari per confermare la relazione.
Per esempio, preservare un riferimento Order può richiedere più del semplice trasferimento del valore nell’header. Assistenza clienti, evasione o contabilità possono aver bisogno che quel riferimento resti collegato al corretto Order, alle righe e al contesto storico.
L’implementazione dell’integrazione rimane separata salvo inclusione espressa. Custom Service può preservare i dati e le relazioni lato migrazione definiti nell’ambito accettato. Non costruisce né gestisce automaticamente ogni sistema che in seguito utilizzerà quei dati.
Definisci le trasformazioni su misura attraverso il significato
Può essere necessaria una logica di migrazione personalizzata quando il comportamento standard non produce il risultato previsto. Schemi comuni includono:
- combinare più campi di origine in un solo campo di destinazione;
- dividere un valore di origine tra più campi di destinazione;
- normalizzare valori incoerenti;
- convertire stati di origine in stati di destinazione;
- rimodellare record appartenenti ad applicazioni;
- preservare relazioni non standard;
- abbinare record tramite identificatori specifici del progetto;
- applicare regole non disponibili attraverso Standard Add-ons.
La trasformazione dovrebbe essere descritta come una regola con esempi ed eccezioni.
Requisito debole:
Correggere gli stati Order.
Requisito più forte:
Convertire ogni stato Order di origine approvato nello stato di destinazione definito, preservare lo stato originale per audit dove concordato e validare esempi di Orders completati, annullati, rimborsati e parzialmente evasi.
Il requisito più forte spiega la condizione nell’origine, il risultato atteso nella destinazione e la prova. Può essere delimitato, quotato, implementato e accettato.
Capire quando un Add-on richiede una gestione personalizzata
Gli Standard Add-ons risolvono requisiti supportati e delimitati:
- Data Filter sceglie quali record migrare applicando condizioni basate sui campi a ciascun tipo di dati;
- Advanced Data Mapping rimappa campi di origine supportati verso campi di destinazione compatibili;
- Advanced Database Mapping mappa campi supportati e colonne del database sottostante verso campi o colonne compatibili della destinazione soltanto quando sia la piattaforma di origine sia la piattaforma di destinazione sono Open-Source;
- Data Transformation trasforma durante la migrazione i valori di campi di destinazione selezionati.
Custom Service diventa pertinente quando:
- uno Standard Add-on deve essere modificato, diventando un Tailored Add-on;
- nessuno Standard Add-on è adatto, creando la necessità di un Custom Add-on;
- i record o le relazioni sottostanti non sono supportati;
- il requisito necessita di logiche su misura oltre il comportamento disponibile dell’Add-on.
Un Add-on può continuare a far parte di un progetto Custom Service. L’Add-on affronta una funzionalità mirata, mentre Custom Service definisce il risultato non standard più ampio.
Costruisci l’ambito attorno agli elementi necessari per decidere e validare
Una richiesta Custom Service dovrebbe fornire elementi sufficienti per definire sia fattibilità sia accettazione.
| Elemento | Perché è importante |
|---|---|
| Dettagli di piattaforma di origine e destinazione | Stabilisce percorso di migrazione e contesto delle piattaforme |
| Record di origine rappresentativi | Mostra valori, strutture e relazioni reali |
| Proprietario dei dati e scopo aziendale | Spiega perché i dati non standard devono sopravvivere |
| Risultato previsto nello store di destinazione | Definisce la rappresentazione richiesta |
| Regole di trasformazione o abbinamento | Rende verificabile la logica su misura |
| Applicazioni o sistemi esterni correlati | Mette in evidenza dipendenze oltre i record standard della piattaforma |
| Eccezioni e casi di errore | Evita che l’ambito copra soltanto i record ideali |
| Campioni di validazione e responsabile | Definisce come verrà decisa l’accettazione |
| Entity Points Plan e Add-ons acquistati | Separa capacità e miglioramenti esistenti dal nuovo lavoro personalizzato |
Gli elementi forniti dovrebbero includere casi difficili, non soltanto esempi puliti. Una regola personalizzata che funziona per Products ordinari può fallire su Products con identificatori mancanti, valori duplicati o relazioni insolite.
L’ambito accettato dovrebbe dichiarare che cosa verrà estratto, trasformato, collegato o consegnato. Dovrebbe inoltre indicare che cosa è escluso, che cosa dipende dalle capacità della piattaforma di destinazione e quali responsabilità di implementazione restano separate.
Separa la gestione della migrazione dall’implementazione sulla destinazione
Custom Service può definire una gestione della migrazione su misura. Non include automaticamente:
- design del tema o della parte pubblica dello store;
- installazione di applicazioni o estensioni;
- sviluppo e distribuzione delle integrazioni;
- configurazione di pagamenti, spedizioni, imposte o email;
- ricostruzione completa dei processi;
- configurazione operativa;
- ogni comportamento dell’origine che la piattaforma di destinazione non può supportare.
Questa separazione non è soltanto contrattuale. Protegge la decisione sulla migrazione. Un record può essere migrato correttamente mentre il processo di destinazione che lo utilizza non è ancora implementato. Al contrario, un’applicazione può essere installata nella destinazione mentre la migrazione non ha preservato i dati di cui ha bisogno.
L’ambito dovrebbe rendere chiaro il passaggio. Per esempio, un identificatore esterno può essere migrato in un campo concordato della destinazione, mentre un lavoro di integrazione separato collega quel campo all’ERP.
Imposta aspettative realistiche sulle differenze tra piattaforme
Custom Service non può costringere due piattaforme a funzionare in modo identico. Opzioni Product, gruppi Customer, stati Order, gerarchie dei contenuti, URL e dati di applicazioni possono non avere un equivalente diretto nella destinazione.
Il risultato utilizzabile può essere:
- preservazione diretta;
- trasformazione in una struttura supportata dalla destinazione;
- mappatura a livello di campo;
- preservazione parziale del significato aziendale;
- esportazione per uso separato;
- esclusione con un piano sostitutivo documentato.
Il risultato appropriato dipende dallo scopo aziendale e dalle capacità della piattaforma di destinazione. L’imitazione esatta non è sempre l’obiettivo migliore. Una rappresentazione più semplice nella destinazione può essere preferibile quando preserva il risultato richiesto senza trascinare in avanti logiche obsolete dell’origine.
Comprendi separatamente ambito, esecuzione e prezzo
Custom Service definisce il lavoro su misura. Expert Handle definisce se è inclusa anche l’esecuzione da parte di esperti delle attività di migrazione concordate.
Un progetto Custom Service può quindi essere:
- gestito dal cliente, con il lavoro su misura incluso e il cliente che esegue le attività di migrazione; oppure
- eseguito dagli esperti, con Expert Handle incluso nell’ambito accettato.
L’importo Custom Service visualizzato parte dal prezzo Standard Service dell’Entity Points Plan selezionato. Tale importo stabilisce il prezzo minimo della capacità. Il totale finale aggiunge il preventivo concordato per il lavoro di personalizzazione, gli Add-ons acquistati dove applicabili, Expert Handle quando incluso e gli altri costi specifici dell’ambito accettati.
Quando il lavoro personalizzato viene aggiunto a una migrazione già acquistata, il preventivo accettato modifica il valore totale della migrazione. L’importo già pagato viene mantenuto nel calcolo e viene addebitata soltanto la differenza aggiuntiva. Lo stesso principio si applica a Tailored e Custom Add-ons.
Il prezzo finale non può essere definito responsabilmente finché il risultato non standard non è abbastanza chiaro da poter essere delimitato. Accettare e acquistare l’upgrade quotato integra il lavoro nella stessa migrazione; non crea un nuovo percorso né estende la durata di un anno del servizio.
Valida il risultato su misura
Il lavoro personalizzato richiede elementi di accettazione specifici. I controlli generici dei conteggi non sono sufficienti quando il requisito dipende da significato, trasformazione o relazioni.
La validazione dovrebbe confrontare:
- esempio nell’origine;
- regola di trasformazione o gestione concordata;
- rappresentazione nello store di destinazione;
- record collegati o identificatori esterni;
- risultato aziendale atteso;
- gestione delle eccezioni;
- decisione Pass, Watch o Block.
Il cliente rimane responsabile della verifica finale. Questo è particolarmente importante per il lavoro personalizzato, perché lo standard di accettazione dipende spesso da conoscenze aziendali che non possono essere dedotte dal solo schema di origine.
Una decisione Watch dovrebbe individuare l’incertezza residua, la sua conseguenza per il business, gli elementi ancora necessari e la persona responsabile della risoluzione. Senza questa interpretazione, la validazione del lavoro personalizzato diventa un elenco di osservazioni anziché una decisione di accettazione difendibile.
Conclusione
Next-Cart Custom Service gestisce le parti di una migrazione che richiedono interpretazione individuale, logica su misura, Add-ons modificati, analisi di Custom Platform, relazioni non standard o una rappresentazione progettata nella destinazione.
L’ambito personalizzato più solido parte dal significato e dagli elementi disponibili. Individua chi possiede i dati, quale scopo aziendale continua, come lo store di destinazione dovrebbe rappresentare il risultato, quale lavoro di migrazione è necessario, quale implementazione resta separata e come verrà dimostrata l’accettazione.
Custom Service non promette di ricreare ogni comportamento dell’origine. È un metodo strutturato per raggiungere il risultato utilizzabile e verificabile più vicino quando il comportamento supportato e gli Standard Add-ons non sono sufficienti.
Domande frequenti
Custom Service è riservato alle Custom Platforms?
No. Si applica anche a campi personalizzati, dati di terze parti, identificatori esterni, logiche su misura, Tailored Add-ons, Custom Add-ons e altri requisiti non standard.
Ogni campo personalizzato richiede Custom Service?
Non automaticamente. La decisione dipende dal fatto che il campo sia supportato, dal significato aziendale che contiene, da dove debba essere rappresentato e dal fatto che il comportamento di mappatura disponibile sia sufficiente.
In che cosa Custom Service differisce da uno Standard Add-on?
Uno Standard Add-on risolve un’esigenza supportata e delimitata di filtro, trasformazione o mappatura dei campi. Custom Service affronta requisiti modificati, non supportati o su misura che richiedono un ambito personalizzato.
Custom Service include sempre Expert Handle?
No. Il progetto può rimanere gestito dal cliente. Expert Handle viene incluso solo quando l’esecuzione da parte di esperti fa parte dell’ambito personalizzato accettato.
Custom Service può riprodurre esattamente ogni comportamento dell’origine?
No. Il risultato dipende dalla condizione dei dati di origine, dalle capacità della piattaforma di destinazione, dall’ambito accettato e dagli elementi richiesti per l’approvazione del cliente.
Quali elementi servono per una richiesta Custom Service?
Servono record rappresentativi, proprietà e scopo aziendale dei dati, rappresentazione prevista nella destinazione, regole di trasformazione o relazione, eccezioni, sistemi correlati ed esempi di validazione.
L’implementazione sulla piattaforma di destinazione è inclusa automaticamente?
No. Design, installazione di applicazioni, distribuzione delle integrazioni e configurazione operativa restano separati salvo inclusione espressa nell’ambito accettato.
Perché l’importo Custom Service è un prezzo iniziale?
Stabilisce il prezzo minimo Standard Service della capacità per l’Entity Points Plan selezionato. Il totale finale dipende dal lavoro personalizzato concordato, dagli Add-ons, da Expert Handle quando incluso e dagli altri costi specifici dell’ambito accettati. Per il lavoro accettato successivamente, l’importo già pagato rimane riconosciuto e viene addebitata soltanto la differenza aggiuntiva.