È facile sottovalutare un servizio di migrazione Next-Cart quando lo si considera semplicemente come un pagamento seguito da un trasferimento. Il cliente acquista una migrazione che rimane l’unità organizzativa del servizio. Il percorso di migrazione fisso, la durata di un anno, la capacità conteggiata, la responsabilità di esecuzione, gli interventi supportati e gli eventuali requisiti personalizzati concorrono tutti a definire il risultato.
Queste decisioni sono collegate, ma non sono intercambiabili. Uno store di grandi dimensioni può avere dati prevedibili e adattarsi bene a una migrazione gestita dal cliente. Uno store più piccolo può dipendere da campi personalizzati o record di terze parti la cui gestione richiesta esce dall’ambito supportato dalla migrazione o dagli Standard Add-ons. Un Add-on può risolvere un’esigenza circoscritta di mappatura senza cambiare l’intero Migration Service. Gli Entity Points possono coprire il volume dei dati conteggiati senza dimostrare che la rappresentazione sulla piattaforma di destinazione sarà utilizzabile.
Per questo, il modo più utile di comprendere i servizi di migrazione Next-Cart è considerarli come un insieme di livelli coordinati all’interno della migrazione acquistata. Ogni livello risponde a una domanda diversa del progetto. Gli upgrade successivi diventano parte della stessa migrazione invece di creare servizi separati, così la migrazione rimane il contesto stabile per pianificazione, esecuzione e validazione.
Parti dal risultato che la migrazione deve ottenere
Il percorso di migrazione definisce una direzione fissa e unidirezionale dalla piattaforma di origine alla piattaforma di destinazione. Questa direzione non è un semplice dettaglio di instradamento. Stabilisce quali strutture della piattaforma devono essere interpretate, quali requisiti di connessione devono essere preparati e quali limiti della destinazione possono influire sul risultato.
Prima di valutare capacità o prezzo, il risultato atteso deve essere chiaro. Il progetto può richiedere che i prodotti restino acquistabili, che lo storico dei clienti rimanga utile, che gli ordini conservino il contesto necessario all’assistenza, che i contenuti mantengano il proprio valore SEO o che gli identificatori esterni restino collegati a un altro sistema. Questi risultati determinano ciò che la migrazione deve preservare e quali verifiche serviranno in seguito.
Una migrazione acquistata copre un solo percorso dalla piattaforma di origine alla piattaforma di destinazione. Il percorso non può essere modificato dopo l’acquisto. Il servizio rimane disponibile per un anno dalla data dell’acquisto iniziale, nei limiti della capacità selezionata, del Migration Service, degli Add-ons acquistati, dell’ambito personalizzato concordato e delle responsabilità di validazione.
L’upgrade di un componente non crea un nuovo percorso e non fa ripartire la durata annuale. L’upgrade modifica la migrazione esistente, mentre il momento dell’acquisto iniziale continua a definire il periodo del servizio. Una migrazione scaduta deve essere estesa prima che possano proseguire ulteriori attività idonee.
Separa le decisioni che compongono una migrazione acquistata
Una migrazione acquistata riunisce normalmente diverse decisioni di pianificazione. La tabella seguente è più utile dopo aver chiarito il risultato e il percorso di migrazione, perché mostra quale domanda è destinato a risolvere ciascun componente.
| Componente | Domanda di progetto a cui risponde | Che cosa non decide |
|---|---|---|
| Percorso di migrazione | Quale direzione fissa dalla piattaforma di origine alla piattaforma di destinazione è coperta? | Se il modello dati è semplice o se il risultato è accettabile |
| Durata del servizio | Per quanto tempo la migrazione acquistata resta attiva a partire dall’acquisto iniziale? | Se un upgrade modifica il percorso o riavvia la durata |
| Entity Points Plan | Quanta capacità conteggiata per Product, Customer, Order e Blog Posts è disponibile? | Se il progetto richiede Managed Service o Custom Service |
| Migration Service | Chi è responsabile dell’esecuzione e il requisito resta supportato oppure richiede una gestione personalizzata? | Quanta capacità conteggiata è necessaria |
| Add-ons | Un’esigenza circoscritta di filtraggio, mappatura di campi o colonne database, oppure trasformazione dei valori di destinazione può essere gestita tramite una funzionalità supportata? | Se è coperto un lavoro più ampio, non supportato o su misura |
| Ambito personalizzato concordato | Quali dati, logiche, relazioni o output non standard richiedono lavoro su misura? | L’implementazione della piattaforma di destinazione, salvo inclusione esplicita |
La confusione nasce spesso quando si usa una riga per rispondere alla domanda di un’altra. Le dimensioni dello store vengono usate come sostituto della valutazione del servizio. Una stima bassa degli Entity Points viene trattata come prova di semplicità. Ci si aspetta che un Add-on risolva un modello dati personalizzato. Si presume che Managed Service includa ogni requisito non standard. Nessuna di queste conclusioni deriva automaticamente dal componente considerato.
La capacità descrive il volume, non la complessità
Gli Entity Points traducono quattro tipi di dati conteggiati in capacità ponderata:
- Product;
- Customer;
- Order;
- Blog Posts.
L’Entity Points Plan selezionato deve offrire capacità sufficiente per il fabbisogno conteggiato realistico. Questa è una decisione di volume. La complessità può comunque derivare da Products con strutture di opzioni insolite, record di proprietà di applicazioni, attributi Customer personalizzati, identificatori Order esterni, relazioni multilingua o limitazioni lato destinazione.
Considera due store con la stessa stima di Entity Points. Il primo usa record standard della piattaforma e relazioni prevedibili. Il secondo conserva prezzi contrattuali in tabelle personalizzate e dipende da un identificatore esterno per collegare gli Orders a un ERP. La capacità conteggiata può essere identica, ma i requisiti di migrazione non lo sono. La pianificazione della capacità deve quindi avvenire insieme all’analisi strutturale, non al suo posto.
Il calcolo dettagliato dei pesi e le regole di consumo sono trattati in Entity Points. Le capacità dei piani, i prezzi degli upgrade e i prezzi delle estensioni sono trattati in Entity Points Plan e prezzi della migrazione.
Responsabilità e ambito sono due dimensioni diverse
La scelta del Migration Service combina due domande distinte:
- Il risultato atteso rientra nel comportamento di migrazione supportato oppure richiede lavoro personalizzato?
- Chi deve eseguire le azioni di migrazione concordate?
Standard Service e Managed Service gestiscono entrambi requisiti di migrazione supportati. La differenza principale riguarda la responsabilità di esecuzione. Standard Service segue un approccio guidato dal cliente. Managed Service include l’esecuzione da parte di esperti delle azioni di migrazione concordate all’interno dell’ambito supportato.
Custom Service gestisce requisiti su misura o non standard. Può restare gestito dal cliente, oppure includere Expert Handle quando anche l’esecuzione delle azioni concordate deve far parte dell’ambito personalizzato.
Questa distinzione evita un errore comune: considerare Managed Service la risposta a dati non supportati. L’esecuzione da parte di esperti non trasforma una struttura personalizzata in una struttura standard. Allo stesso modo, un requisito personalizzato non implica automaticamente la necessità di esecuzione da parte di esperti.
Standard, Managed e Custom Migration Services sviluppa queste definizioni. Scegliere il Migration Service giusto spiega come prendere la decisione sulla base delle evidenze del progetto.
Considera la migrazione come il record principale del servizio
La migrazione acquistata e i pagamenti collegati rispondono a domande diverse. La migrazione rappresenta lo stato corrente del servizio: percorso fisso, Migration Service selezionato, Entity Points Plan, Add-ons, lavoro personalizzato accettato, durata del servizio e storico delle migrazioni. Gli ordini costituiscono invece la registrazione commerciale di come tale stato è stato acquistato, aggiornato o esteso.
L’acquisto iniziale crea la migrazione. Un successivo upgrade del piano, del servizio, di un Add-on o del lavoro personalizzato diventa parte della stessa migrazione una volta acquistato. Questa distinzione spiega perché una migrazione può avere diversi ordini correlati senza trasformarsi in più servizi di migrazione indipendenti.
Chiarisce anche i prezzi successivi. Un upgrade viene calcolato rispetto al valore già pagato per la migrazione, quindi il cliente paga la differenza aggiuntiva invece di riacquistare l’intero pacchetto. L’estensione di una migrazione scaduta è diversa: l’estensione ripristina il servizio a partire dallo stato più recente mantenuto dalla migrazione, compresi i componenti applicabili già integrati.
Dal punto di vista della pianificazione del servizio, la distinzione è importante perché la continuità segue la migrazione acquistata, mentre ogni pagamento resta riconducibile alla modifica commerciale che registra.
Usa gli Add-ons per esigenze circoscritte
Gli Add-ons sono particolarmente utili quando il percorso di migrazione è supportato ma una parte ben definita del risultato richiede maggiore controllo. I quattro Standard Add-ons gestiscono tipi diversi di requisiti circoscritti:
- Data Filter seleziona 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 relative colonne database verso campi o colonne di destinazione compatibili, compresi campi specifici della piattaforma e campi personalizzati, soltanto quando sia la piattaforma di origine sia quella di destinazione sono Open-Source.
- Data Transformation trasforma i valori di campi selezionati sulla destinazione mentre i record vengono migrati dallo store di origine allo store di destinazione.
Il confine è importante. Gli Standard Add-ons sono compatibili con tutti e tre i Migration Services quando un Add-on disponibile soddisfa già il requisito. Se è necessario modificare l’Add-on stesso, il requisito diventa un Tailored Add-on nell’ambito di Custom Service. Se nessuno Standard Add-on è adatto, può essere necessaria la valutazione di un Custom Add-on o di un Custom Service più ampio.
La decisione deve partire dal risultato richiesto, non dal nome dell’Add-on. “Migrare soltanto gli Orders successivi a una data approvata” descrive un risultato filtrabile. “Preservare un motore proprietario di determinazione dei prezzi” descrive invece un problema personalizzato più ampio, per il quale devono essere prima definiti significato, relazioni e funzionamento sulla destinazione.
Trasforma i risultati iniziali in elementi utili per decidere
La Demo Migration può fornire risultati rappresentativi nelle fasi iniziali, prima di attività di migrazione più ampie. Il suo valore dipende meno dal semplice vedere comparire dei record e più dalla scelta di campioni che facciano emergere differenze significative.
Un buon campione può includere un Product con varianti e attributi particolari, un Order con uno storico di stato insolito, un Customer usato in un reale processo di segmentazione oppure contenuti con un importante valore URL. I record semplici possono dimostrare che il percorso di base funziona; quelli difficili mostrano se le ipotesi di migrazione sono abbastanza solide.
La Demo Migration ha limiti definiti e non consente Add-ons né Customization. Il risultato può evidenziare una probabile esigenza di funzionalità supportate aggiuntive o lavoro personalizzato, ma non può dimostrare come funzionerà quella configurazione successiva. Demo Migration spiega come scegliere i dati da verificare e come interpretare i limiti del test.
Separa l’esecuzione dall’accettazione
L’esecuzione produce un risultato di migrazione. La validazione stabilisce se quel risultato è utilizzabile per l’azienda.
La revisione finale deve andare oltre la semplice presenza dei record. Deve confermare che i Products importanti conservino il significato necessario all’acquisto, che Customers e Orders restino utili, che contenuti e URL supportino il percorso previsto, che le relazioni continuino a collegare i record corretti e che ogni output prodotto da Add-on o lavoro personalizzato corrisponda all’ambito accettato.
Il cliente rimane responsabile della verifica finale con ogni Migration Service. Questo non significa trasferire al cliente la responsabilità dell’esecuzione svolta dagli esperti. È un tipo diverso di responsabilità: soltanto l’azienda può confermare che lo store di destinazione supporti i risultati commerciali, operativi, SEO e di conformità previsti.
Configurazione della piattaforma di destinazione, lavoro sul tema, installazione di applicazioni, implementazione delle integrazioni e altre attività di implementazione devono essere identificate separatamente, salvo esplicita inclusione nell’ambito concordato. Un record migrato correttamente non configura da solo il sistema che dovrà utilizzarlo.
Usa la sezione come sistema decisionale
Gli articoli dedicati ai servizi rispondono a domande diverse:
| Decisione da risolvere | Articolo |
|---|---|
| Come procede la migrazione dalla preparazione a un risultato validato? | Come funziona il processo di migrazione |
| Che cosa possono dimostrare i risultati rappresentativi iniziali? | Demo Migration |
| Come vengono calcolati e consumati i volumi conteggiati? | Entity Points |
| Quale piano e quale prezzo si applicano? | Entity Points Plan e prezzi della migrazione |
| Un requisito circoscritto e supportato può essere gestito da un Add-on? | Add-ons |
| In che cosa differiscono i tre Migration Services? | Standard, Managed e Custom Migration Services |
| Quali requisiti su misura rientrano in Custom Service? | Che cosa gestisce Custom Service |
| Quale Migration Service è adatto ai risultati emersi dal progetto? | Scegliere il Migration Service giusto |
| Quale azione successiva corrisponde alla continuità, a una configurazione modificata o a un nuovo risultato? | Additional Migration Options |
Questo percorso di lettura non è una sequenza obbligatoria. È un modo per isolare la decisione che rimane incerta senza confondere capacità, responsabilità del servizio, ambito personalizzato e validazione in un’unica domanda.
Conclusione
Una migrazione Next-Cart si comprende meglio come un servizio acquistato e persistente, non come un singolo trasferimento o pagamento. Il percorso fisso e la durata di un anno ne definiscono il perimetro. Gli Entity Points forniscono la capacità conteggiata. Il Migration Service definisce l’ambito supportato o personalizzato e la responsabilità di esecuzione. Gli Add-ons risolvono requisiti supportati e circoscritti. Custom Service gestisce esigenze non standard. Gli ordini correlati registrano acquisti, upgrade ed estensioni senza frammentare la migrazione stessa. La validazione determina se il risultato è adatto all’uso aziendale.
Mantenere separati questi livelli consente stime più chiare, scelte di servizio più difendibili e migliori basi per l’accettazione. Evita inoltre un errore comune di pianificazione: presumere che un singolo componente, come le dimensioni dello store, il prezzo o un Add-on, possa spiegare l’intera migrazione.
Domande frequenti
Che cosa definisce il percorso di migrazione?
Definisce la direzione fissa e unidirezionale dalla piattaforma di origine alla piattaforma di destinazione coperta dalla migrazione acquistata.
Un upgrade crea una nuova migrazione o fa ripartire la durata del servizio?
No. Un upgrade acquistato viene integrato nella stessa migrazione. Il percorso fisso non cambia e la durata di un anno continua a decorrere dall’acquisto iniziale.
Perché una sola migrazione può avere più ordini correlati?
L’ordine iniziale crea la migrazione. Ordini successivi possono registrare upgrade o un’estensione, mentre la migrazione rimane il servizio gestito.
Un Entity Points Plan più grande richiede Managed Service o Custom Service?
No. Gli Entity Points determinano la capacità conteggiata. La scelta del Migration Service dipende dall’ambito supportato, dalla responsabilità di esecuzione, dalle esigenze relative agli Add-ons e dai requisiti personalizzati.
Un Add-on può essere usato con Standard Service?
Sì. Uno Standard Add-on può accompagnare Standard, Managed o Custom Service quando il suo comportamento disponibile soddisfa il requisito circoscritto.
Custom Service include sempre Expert Handle?
No. Custom Service può rimanere gestito dal cliente. Expert Handle è incluso soltanto quando l’esecuzione da parte di esperti delle azioni di migrazione concordate fa parte dell’ambito personalizzato accettato.
Perché la validazione del cliente è necessaria dopo un’esecuzione gestita da esperti?
L’esecuzione conferma che le attività di migrazione sono state svolte nell’ambito concordato. La validazione del cliente conferma che Products, Customers, Orders, contenuti, relazioni e risultati aziendali ottenuti siano accettabili per lo store di destinazione.