La scelta tra i Migration Services Next-Cart viene spesso ridotta a una scala semplice: Standard per un progetto piccolo, Managed per uno più grande e Custom per quello più complesso. Questa scorciatoia non è affidabile. La dimensione dello store descrive il volume, non la struttura del requisito. Il prezzo riflette capacità e lavoro incluso, non un livello automatico di qualità.
I tre Migration Services Next-Cart diventano più chiari quando la decisione viene separata in due dimensioni. La prima riguarda l’ambito: il risultato atteso rientra nel comportamento supportato della migrazione oppure richiede una gestione su misura? La seconda riguarda l’esecuzione: le attività di migrazione concordate saranno eseguite dal cliente oppure deve essere inclusa l’esecuzione affidata agli esperti?
Standard, Managed e Custom Service occupano posizioni diverse lungo queste due dimensioni. Comprendere questa relazione evita di collocare requisiti non supportati in Managed Service e impedisce che migrazioni prevedibili vengano indirizzate a Custom Service soltanto perché lo store è grande.
Parti dall’ambito, poi assegna la responsabilità di esecuzione
Ambito supportato significa che il percorso di migrazione, le strutture dei dati, la configurazione disponibile e gli Standard Add-ons possono produrre il risultato previsto senza logiche di migrazione specifiche per il progetto. Ambito su misura significa che una parte del requisito necessita di analisi, modifica, trasformazione o gestione individuale oltre quel comportamento supportato.
La responsabilità di esecuzione risponde a una domanda diversa. Una migrazione supportata può essere gestita dal cliente oppure eseguita dagli esperti. Anche una migrazione personalizzata può essere gestita dal cliente oppure includere Expert Handle. Chi esegue le attività non modifica il fatto che il requisito sui dati sia supportato o meno.
Questo quadro produce quattro posizioni pratiche:
| Posizione di ambito ed esecuzione | Migration Service | Motivo centrale |
|---|---|---|
| Ambito supportato con esecuzione gestita dal cliente | Standard Service | Le funzionalità disponibili sono sufficienti e il cliente può coordinare le attività |
| Ambito supportato con esecuzione affidata agli esperti | Managed Service | Le funzionalità disponibili sono sufficienti, ma deve essere inclusa la responsabilità di esecuzione |
| Ambito su misura con esecuzione gestita dal cliente | Custom Service | È necessario lavoro non standard, mentre il cliente può eseguire le attività concordate |
| Ambito su misura con esecuzione affidata agli esperti | Custom Service con Expert Handle | Sono necessari sia lavoro su misura sia esecuzione da parte di esperti |
La tabella non è un modulo di qualificazione. Serve a evitare di mescolare due decisioni che devono essere valutate separatamente.
Standard Service: ambito supportato con responsabilità del cliente
Standard Service è adatto quando il percorso di migrazione è supportato, le strutture importanti dell’origine sono prevedibili e la configurazione disponibile o gli Standard Add-ons possono produrre il risultato richiesto. Il cliente prepara gli accessi necessari, esamina la configurazione, esegue le attività di migrazione, coordina i problemi rilevati e valida lo store di destinazione.
Questo non rende Standard Service un’opzione di base o a bassa capacità. Uno store con molti Products e Orders può comunque essere adatto quando il modello dati è ben compreso e il team interno ha la capacità di gestire l’esecuzione. Gli Entity Points determinano la quantità di dati conteggiati che il piano può supportare; non stabiliscono se Standard Service sia appropriato.
Un caso adatto a Standard Service presenta normalmente:
- un percorso supportato dalla piattaforma di origine alla piattaforma di destinazione;
- responsabilità chiare per dati e relazioni importanti;
- nessun requisito di logica di migrazione su misura;
- esigenze di Add-on delimitate e compatibili con il comportamento disponibile;
- capacità interna di coordinare esecuzione e validazione;
- criteri di accettazione applicabili a risultati rappresentativi.
Il principale compromesso riguarda la responsabilità. L’esecuzione gestita dal cliente offre controllo diretto su tempistiche e decisioni di configurazione, ma richiede anche attenzione sufficiente per interpretare ciò che emerge e intervenire quando le ipotesi si rivelano errate.
Managed Service: ambito supportato con esecuzione affidata agli esperti
Managed Service si applica quando la migrazione resta entro l’ambito supportato ma è richiesta l’esecuzione da parte di esperti delle attività di migrazione concordate. La distinzione del servizio riguarda la responsabilità, non una capacità più ampia sui dati.
Può essere utile quando il team interno è limitato da una scadenza fissa, da altre attività operative, da poca esperienza con le migrazioni o dalla necessità di coordinare l’esecuzione tra diversi stakeholder. I dati possono essere prevedibili; il progetto trae comunque beneficio dallo spostare l’onere operativo dell’esecuzione.
Managed Service non assorbe dati di applicazioni non supportate, tabelle personalizzate, trasformazioni su misura o logiche Add-on modificate. Se questi requisiti esistono, l’ambito deve prima essere trattato come personalizzato. Affidare a esperti l’esecuzione di un requisito non standard non lo trasforma in comportamento supportato.
Il cliente rimane responsabile di fornire informazioni accurate sul progetto e di validare il risultato. L’esecuzione da parte degli esperti può ridurre il carico operativo, ma non può decidere se i record migrati preservino il significato aziendale richiesto dai team merchandising, finanza, assistenza clienti, SEO o compliance.
Managed Service non elimina l’accesso del cliente alla migrazione. Il cliente può comunque esaminare, configurare ed eseguire manualmente le attività disponibili. L’esecuzione affidata agli esperti è una responsabilità inclusa nel servizio, non un controllo esclusivo della migrazione acquistata.
Custom Service: l’ambito su misura è definito dal risultato richiesto
Custom Service diventa pertinente quando il risultato di migrazione atteso non può essere prodotto attraverso il comportamento supportato e gli Standard Add-ons disponibili. La necessità dovrebbe essere definita attraverso i dati o il funzionamento che richiedono una gestione su misura, non attraverso una generica affermazione secondo cui lo store è insolito.
I segnali più comuni includono:
- una Custom Platform come piattaforma di origine o piattaforma di destinazione;
- campi personalizzati, tabelle o strutture database la cui gestione richiesta supera l’ambito supportato della migrazione o degli Standard Add-ons;
- dati appartenenti ad applicazioni, plugin, moduli o estensioni;
- record di terze parti fuori dal modello supportato della piattaforma;
- identificatori esterni che devono preservare la relazione con un altro sistema;
- trasformazioni o ristrutturazioni su misura;
- logiche non standard per Product, Customer, Order, contenuti o relazioni;
- un Add-on disponibile che deve essere modificato;
- un nuovo Add-on specifico per il progetto.
L’ambito personalizzato dovrebbe identificare il significato nell’origine, la rappresentazione prevista nella destinazione, le regole di trasformazione o relazione, i record interessati e gli elementi necessari per l’accettazione. Senza questi elementi, “personalizzato” rimane un’etichetta anziché un requisito di migrazione utilizzabile.
Expert Handle cambia l’esecuzione, non la natura del lavoro personalizzato
Custom Service non include automaticamente Expert Handle.
Custom Service gestito dal cliente
Il lavoro su misura concordato è incluso, mentre il cliente esegue le attività di migrazione disponibili e valida il risultato. Può essere adatto a team che necessitano di funzionalità personalizzate ma mantengono capacità operativa sufficiente per coordinare l’esecuzione.
Custom Service con Expert Handle
Sono inclusi sia il lavoro su misura concordato sia l’esecuzione da parte degli esperti delle attività di migrazione accettate. Il cliente continua a fornire il contesto aziendale necessario e svolge la verifica finale.
L’ambito accettato dovrebbe indicare esplicitamente la responsabilità di esecuzione. In caso contrario, il progetto può definire correttamente l’output personalizzato lasciando però un vuoto evitabile su chi debba eseguire le attività necessarie per produrlo.
Lo stesso principio di accesso vale per Custom Service. Sia che il progetto sia gestito dal cliente sia che includa Expert Handle, il cliente può comunque accedere ed eseguire manualmente le attività di migrazione disponibili. La scelta del servizio definisce responsabilità inclusa e ambito su misura, non blocca l’accesso del cliente alla migrazione.
Gli Add-ons non costituiscono un quarto Migration Service
Gli Standard Add-ons rispondono a esigenze supportate e delimitate. Possono accompagnare Standard, Managed o Custom Service quando il comportamento disponibile corrisponde al requisito.
Per esempio, selezionare Orders che soddisfano una condizione approvata basata su un campo Order può rientrare in Data Filter. Rimappare un campo di origine supportato verso un campo di destinazione compatibile può rientrare in Advanced Data Mapping. Quando sia la piattaforma di origine sia la piattaforma di destinazione sono Open-Source, la mappatura supportata di un campo o di una colonna database può rientrare in Advanced Database Mapping. Trasformare il valore di un campo di destinazione selezionato può rientrare in Data Transformation. È possibile combinare più Standard Add-ons senza rendere la migrazione un Custom Service quando ogni operazione resta entro il proprio limite supportato.
Il confine cambia quando l’Add-on stesso deve essere modificato o quando nessuno Standard Add-on può produrre il risultato richiesto:
- uno Standard Add-on modificato diventa un Tailored Add-on all’interno di Custom Service;
- un Add-on specifico del progetto viene esaminato come Custom Add-on all’interno di Custom Service;
- dati non supportati o relazioni su misura richiedono un’analisi più ampia tramite Custom Service anche se sono coinvolti anche filtri o mappature.
Un Add-on descrive una funzionalità mirata. Il Migration Service descrive il più ampio assetto di ambito e responsabilità.
La validazione del cliente è una responsabilità separata
Ogni Migration Service termina con la validazione da parte del cliente. A volte questo viene interpretato come un limite dell’esecuzione affidata agli esperti. È più corretto considerarlo una divisione delle competenze.
L’esecuzione può essere valutata rispetto alla configurazione accettata e all’ambito del servizio. L’accettazione aziendale richiede invece conoscenze che appartengono al cliente: quali Products devono restare vendibili, come gli Orders devono supportare le attività di assistenza, quali distinzioni tra Customers sono importanti, se i percorsi SEO sono accettabili e se lo store di destinazione è pronto per il passo successivo previsto.
Un registro di accettazione utile identifica:
- il risultato critico sottoposto a revisione;
- record o scenari rappresentativi;
- il revisore responsabile della decisione;
- il risultato atteso;
- eventuali limitazioni accettate;
- la decisione Pass, Watch o Block.
Anche l’implementazione sulla piattaforma di destinazione deve rimanere visibile come livello separato. Ricostruzione del tema, installazione di applicazioni, configurazione di pagamenti o spedizioni, implementazione delle integrazioni e configurazione operativa non sono automaticamente incluse solo perché i dati migrati dovranno poi partecipare a tali funzioni.
Usa gli elementi emersi per effettuare un upgrade del servizio iniziale
Il Migration Service iniziale può dover cambiare quando nuovi elementi modificano un’ipotesi centrale. Demo Migration può mettere in evidenza strutture non supportate. Un inventario dei dati può far emergere identificatori esterni o tabelle personalizzate. Uno Standard Add-on può rivelarsi troppo limitato. La capacità interna può diventare insufficiente per l’esecuzione gestita dal cliente.
Dopo l’acquisto, le modifiche del servizio possono avvenire soltanto verso l’alto:
| Servizio acquistato | Servizio successivo consentito |
|---|---|
| Standard Service | Managed Service o Custom Service |
| Managed Service | Custom Service |
| Custom Service | Nessun downgrade del servizio |
L’upgrade del servizio è appropriato quando cambiano gli elementi disponibili. Passa da Standard a Managed quando l’ambito supportato resta adatto ma deve cambiare la responsabilità di esecuzione. Passa da Standard o Managed a Custom Service quando è necessario lavoro su misura. All’interno di Custom Service, Expert Handle può essere incluso quando l’ambito su misura è corretto ma anche l’esecuzione affidata agli esperti deve entrare nel lavoro accettato.
La migrazione non può passare da Managed a Standard né da Custom a Managed o Standard. Questa asimmetria rende importante la decisione iniziale, pur lasciando possibile una correzione verso l’alto. Uno Standard Add-on delimitato che risolve completamente il requisito non richiede di per sé un upgrade del servizio.
L’upgrade del servizio entra a far parte della stessa migrazione acquistata e viene addebitato secondo il principio della sola differenza. Non crea un nuovo percorso né estende la durata di un anno del servizio. Questo approccio basato sugli elementi emersi è più affidabile che trattare i tre servizi come livelli reversibili di dimensione o qualità crescenti.
Conclusione
I Migration Services Next-Cart si distinguono per ambito e responsabilità di esecuzione. Standard Service è gestito dal cliente entro l’ambito supportato. Managed Service include l’esecuzione affidata agli esperti entro l’ambito supportato. Custom Service affronta requisiti su misura o non standard e può restare gestito dal cliente oppure includere Expert Handle.
Gli Entity Points dovrebbero essere usati per la capacità, gli Add-ons per miglioramenti supportati e delimitati, mentre la validazione del cliente serve per l’accettazione aziendale. Quando queste decisioni vengono separate, la scelta del servizio diventa una decisione ragionata sul progetto anziché una scorciatoia basata su dimensione dello store, prezzo visualizzato o livello di servizio percepito.
Domande frequenti
Standard Service è adatto soltanto a store piccoli?
No. Standard Service può supportare una migrazione grande quando percorso e requisiti restano supportati e il cliente può coordinare esecuzione e validazione.
Qual è la differenza principale tra Standard e Managed Service?
Entrambi affrontano requisiti di migrazione supportati. Standard Service è gestito dal cliente, mentre Managed Service include l’esecuzione da parte di esperti delle attività di migrazione concordate.
Managed Service copre campi personalizzati o record non supportati?
Non automaticamente. Managed Service modifica la responsabilità di esecuzione entro l’ambito supportato. La gestione su misura di requisiti personalizzati o non supportati rientra in Custom Service.
Custom Service include sempre Expert Handle?
No. Custom Service può essere gestito dal cliente. Expert Handle è incluso quando l’esecuzione affidata agli esperti fa parte dell’ambito personalizzato accettato.
Uno Standard Add-on può essere utilizzato con Managed Service?
Sì. Gli Standard Add-ons possono accompagnare Standard, Managed o Custom Service quando il comportamento disponibile corrisponde al requisito.
Chi approva il risultato finale della migrazione?
Il cliente rimane responsabile della verifica finale con qualsiasi Migration Service, perché l’accettazione aziendale dipende dai risultati commerciali, operativi, SEO e di conformità previsti.
I clienti possono ancora eseguire attività di migrazione con Managed o Custom Service?
Sì. Ogni Migration Service rimane accessibile per attività manuali del cliente. Managed Service ed Expert Handle definiscono la responsabilità di esecuzione inclusa; non rimuovono l’accesso del cliente.
Un Migration Service acquistato può essere ridotto?
No. Standard può essere aggiornato a Managed o Custom e Managed può essere aggiornato a Custom. Un Migration Service acquistato non può passare a un livello inferiore.