Scegliere l’approccio di migrazione giusto per EShop by Ossolution Team dipende da quanto significato aziendale deve sopravvivere oltre ai normali record Product, Customer e Order. EShop è un’estensione shopping cart per Joomla, quindi l’approccio deve considerare struttura del catalogo, opzioni Product, attributi, campi personalizzati, dati del processo di acquisto, gruppi Customer, storico Orders, Tax, spedizioni, contesto di pagamento, contenuti multilingua, presentazione Joomla, moduli, template, plugin e implementazioni personalizzate.
Un approccio più leggero può funzionare quando i dati della piattaforma di origine sono puliti, il percorso di migrazione selezionato supporta i record necessari e l’azienda può gestire con sicurezza la verifica sulla destinazione. Serve invece un approccio più strutturato quando lo store presenta regole di catalogo complesse, campi del processo di acquisto personalizzati, dati di proprietà delle integrazioni, ristrutturazione multilingua, dipendenze dall’implementazione Joomla oppure funzionamenti su misura che non possono essere spiegati attraverso i soli record standard.
L’approccio giusto non è automaticamente quello più complesso. È quello che corrisponde al reale impegno necessario per tradurre lo store di origine in un ambiente EShop utilizzabile.
Nel contesto dei Next-Cart Migration Services, le evidenze raccolte per EShop dovrebbero identificare l’ambito di migrazione supportato, la responsabilità di esecuzione richiesta e qualsiasi dipendenza Joomla o di estensioni che richieda una gestione su misura.
Cosa deve decidere l’approccio giusto per EShop
Prima dell’esecuzione, l’approccio di migrazione per EShop dovrebbe rispondere a tre domande: i dati rientrano nelle capacità supportate del servizio, chi deve gestire esecuzione e validazione e quali requisiti necessitano di Add-ons o Custom Service. Queste decisioni vanno prese prima dell’approvazione finale perché i progetti EShop combinano spesso normali dati e-commerce con responsabilità di implementazione specifiche di Joomla.
| Area decisionale | Cosa valutare | Perché è importante per EShop |
|---|---|---|
| Idoneità dei dati supportati | Products, Categories, Manufacturers, Customers, Orders, Reviews, Coupons, opzioni, attributi, campi e dati dello store inclusi nel percorso selezionato | L’esecuzione standard è più affidabile quando i dati necessari hanno un significato chiaro nella piattaforma di origine e una destinazione supportata. |
| Responsabilità di esecuzione | Se l’azienda gestirà direttamente il processo o desidera un’esecuzione guidata da Next-Cart | Progetti EShop più ampi o sensibili possono beneficiare di Managed Service anche quando i dati sono standard. |
| Supporto opzionale | Se servono condizioni sui tipi di dati, espressioni sui valori o destinazioni diverse per campi della piattaforma di origine | Data Filter, Advanced Data Mapping o Data Transformation possono coprire esigenze definite senza trasformare l’intero progetto in un incarico personalizzato. |
| Verifica dei requisiti personalizzati | Dati Custom Platform, dati di estensioni non supportati, identificatori di terze parti, campi del processo di acquisto su misura e logiche personalizzate | Queste aree possono richiedere Custom Service anziché assunzioni da servizio standard. |
| Confine dell’implementazione di destinazione | Menu Joomla, moduli, template, plugin di pagamento e spedizione, configurazione Tax, email e redirect | Alcune responsabilità appartengono alla configurazione e implementazione della destinazione, non al risultato della migrazione. |
Questa distinzione evita l’errore comune di scegliere l’approccio soltanto in base al volume. Una piccola migrazione EShop può richiedere Custom Service se include campi del processo di acquisto su misura o dati di plugin non supportati. Una migrazione ampia può restare su un percorso standard quando i dati sono puliti, supportati e facili da validare.
Quando Standard Service può essere adatto a EShop
Standard Service può essere adatto quando lo store di origine presenta una struttura di catalogo chiara, record supportati e un team interno in grado di utilizzare il flusso Next-Cart e validarne il risultato. È più indicato quando Products, Categories, Manufacturers, Customers, Orders, Reviews, Coupons e comuni campi di catalogo possono essere migrati senza interpretazione su misura.
Per EShop, l’idoneità a Standard Service dipende anche dalla chiarezza di opzioni e attributi Product. Le opzioni dovrebbero rappresentare scelte dell’acquirente. Gli attributi dovrebbero rappresentare informazioni o specifiche Product. Se i valori di origine sono puliti e le destinazioni sono chiare, il progetto può non aver bisogno di un percorso più complesso.
| Segnale di idoneità a Standard Service | Cosa significa normalmente | Punto di validazione specifico per EShop |
|---|---|---|
| Dati di catalogo puliti | Products, Categories, Manufacturers, immagini, descrizioni, prezzi e stock sono coerenti. | Le pagine Product possono essere verificate senza pesante pulizia o interpretazione dei dati. |
| Opzioni Product comprensibili | Scelte come taglia, colore, confezione o formato hanno un significato chiaro. | I valori delle opzioni devono restare acquistabili e leggibili nelle righe Order. |
| Attributi e specifiche chiari | I valori tecnici sono descrittivi anziché governare l’acquisto. | Posizionamento di attributi o campi personalizzati può essere verificato senza logica personalizzata. |
| Storico Customer e Order ordinario | Customers, indirizzi, righe Order, stati, Coupons, voucher, Tax, spedizioni ed etichette di pagamento sono leggibili. | I dati storici restano utili per assistenza e reportistica. |
| Validazione gestita dall’azienda realistica | Il team può controllare campioni, confrontare record e gestire le attività di configurazione successive. | L’esecuzione standard non elimina la necessità di verifica sulla destinazione. |
Standard Service non dovrebbe essere scelto soltanto perché lo store è piccolo. Va scelto perché i dati di origine sono chiari, la struttura di destinazione è adatta e nessun funzionamento personalizzato non supportato è essenziale da preservare.
Quando Managed Service è più sicuro
Managed Service è più sicuro quando la migrazione può ancora usare capacità standard, ma l’azienda desidera esecuzione guidata da Next-Cart e revisione coordinata. Può essere appropriato per progetti EShop con cataloghi più ampi, finestre di lancio strette, più stakeholder, storico Orders dettagliato, contenuti multilingua o bisogno di maggiore supervisione sull’esecuzione.
Managed Service non risolve automaticamente dati personalizzati o logiche non supportate. Migliora la responsabilità di esecuzione quando il percorso di migrazione è comunque adatto. Se il progetto richiede interpretazione su misura, trasformazione di campi personalizzati oltre l’ambito supportato da Data Transformation, gestione di estensioni non supportate o adeguamento della logica di migrazione, va valutato Custom Service.
| Segnale per Managed Service | Perché conta | Confine da mantenere chiaro |
|---|---|---|
| Catalogo Product ampio | Più campioni, Categories, relazioni Manufacturer e lavoro di validazione. | Un volume elevato da solo non implica gestione personalizzata. |
| Storico Orders dettagliato | Gli Orders possono includere opzioni, voucher, Coupons, Tax, spedizioni, etichette di pagamento, commenti e storico stati. | La leggibilità storica dipende comunque dai campi disponibili nella piattaforma di origine e di destinazione. |
| Vetrina multilingua | Products, Categories, alias, moduli, metadati e relazioni linguistiche richiedono revisione coordinata. | La configurazione lingue Joomla può richiedere implementazione lato destinazione oltre la migrazione. |
| Pressione sul lancio | L’azienda necessita di più coordinamento e meno rischio nell’esecuzione autonoma. | Configurazione di destinazione e approvazione aziendale richiedono comunque partecipazione dell’azienda. |
| Più responsabili interni | Marketing, operazioni, supporto, finanza e team tecnici possono validare dati diversi. | L’esecuzione gestita non sostituisce la responsabilità sulle decisioni aziendali. |
Managed Service è spesso una scelta pratica quando la migrazione non è tecnicamente personalizzata ma è operativamente sensibile. Il progetto può beneficiare di esecuzione Next-Cart, revisione strutturata e coordinamento più chiaro senza modificare la capacità dati sottostante.
Dove gli Add-ons supportano una migrazione EShop
Gli Add-ons possono supportare una migrazione EShop quando l’esigenza rientra in una capacità opzionale definita. Sono particolarmente utili quando servono filtro dei record per tipo di dati tramite condizioni, trasformazioni dei valori tramite espressioni oppure rimappatura di campi di origine. Gli Add-ons non dovrebbero essere usati come spiegazione generica per funzionamenti personalizzati.
Durante la preparazione di EShop emergono spesso esigenze compatibili con Add-ons. L’azienda può voler escludere record obsoleti tramite condizioni su campi supportati, trasformare valori di campi supportati tramite espressioni oppure inviare campi noti della piattaforma di origine verso campi di destinazione compatibili.
| Esigenza | Add-on pertinente | Confine da controllare |
|---|---|---|
| Escludere Products archiviati, Orders di test, vecchi Customers o record inattivi | Data Filter può applicare condizioni basate sui campi a ogni tipo di dati pertinente. | Il filtraggio non trasforma un modello aziendale personalizzato. |
| Trasformare etichette, stati o altri valori di campi supportati | Data Transformation può applicare un’espressione definita durante la migrazione. | Interpretazione su misura o logiche non supportate possono richiedere Custom Service. |
| Inviare campi noti della piattaforma di origine verso campi EShop differenti | Advanced Data Mapping può essere adatto quando significato di origine e destinazione è chiaro. | Campi non supportati o funzionamenti della destinazione possono richiedere Custom Service. |
| Preservare specifici record opzionali | La verifica degli Add-ons può essere utile quando il tipo di record è supportato come percorso di servizio opzionale. | I dati di estensioni non supportati non devono essere descritti come normale lavoro Add-on. |
| Ridurre il rumore prima del lancio | Data Filter può escludere record che soddisfano condizioni approvate specifiche del tipo di dati. | Le decisioni di rimozione dati dovrebbero essere approvate prima dell’esecuzione. |
Gli Add-ons funzionano meglio quando l’azienda sa formulare il requisito con precisione. Una richiesta vaga come “portare tutto esattamente com’era” non è un requisito Add-on: segnala che il modello dati e le dipendenze personalizzate richiedono un’analisi più approfondita.
Quando valutare Custom Service
Custom Service va valutato quando la migrazione EShop dipende da dati o funzionamenti che non possono essere gestiti in sicurezza attraverso capacità standard e Add-ons disponibili. Rientrano in questa situazione dati Custom Platform, dati di estensioni non supportati, campi personalizzati che richiedono interpretazione non standard oltre la mappatura supportata, record di proprietà dei plugin, identificatori di terze parti, logiche processo di acquisto su misura, dati di proprietà delle integrazioni, Tailored Add-ons, Custom Add-ons e adeguamenti personalizzati della logica di migrazione.
La base Joomla di EShop può rendere più frequenti le esigenze personalizzate perché gli store più vecchi possono aver usato estensioni, override dei template, moduli, plugin di contenuto, tabelle database personalizzate o sistemi esterni per modellare il funzionamento della vetrina. La presenza di dati personalizzati non rende automaticamente impossibile la migrazione, ma deve essere classificata prima di approvare l’ambito.
| Motivo per valutare Custom Service | Perché Standard Service o Add-ons possono non essere sufficienti | Evidenze da preparare |
|---|---|---|
| Campi del processo di acquisto personalizzati con regole aziendali | Visualizzazione, validazione, output email, output fattura o significato nell’Order possono essere su misura. | Elenco campi, Orders di esempio, screenshot e aspettative sulla destinazione. |
| Dati di estensioni non supportati | I record possono non appartenere alle strutture standard Product, Customer, Order o Category. | Nomi delle estensioni, campioni database, esempi export e note sulla proprietà. |
| Funzionamento di pagamento o spedizione posseduto da plugin | Le etichette storiche possono migrare, mentre il funzionamento attivo può dipendere da plugin o codice personalizzato. | Elenco plugin, esempi metodi, campioni Order e requisiti futuri. |
| Identificatori delle integrazioni | ID ERP, contabilità, CRM, evasione, inventario o affiliate possono dover essere preservati. | Elenco campi di origine, valori di esempio, destinazione prevista e responsabile integrazione. |
| Campi o schede Product personalizzati con significato operativo | I valori possono influire su evasione, compliance, selezione o reportistica. | Esempi Product e spiegazione aziendale per ogni campo. |
| Lavoro Tailored o Custom Add-on | Un Standard Add-on richiede modifiche specifiche del progetto oppure serve funzionalità Add-on su misura. | Verifica e preventivo tramite Custom Service, con output richiesto e criteri di accettazione definiti esplicitamente. |
Custom Service dovrebbe essere discusso presto quando lo store di origine contiene dipendenze nascoste. Attendere fino a dopo Demo Migration può rendere la verifica più difficile perché il campione potrebbe già omettere i record che spiegano il requisito reale.
Lavoro sui template Joomla, installazione di estensioni, configurazione di plugin di pagamento o spedizione e redesign del sito non sono automaticamente inclusi salvo accordo esplicito.
Come Demo Migration dovrebbe verificare l’approccio
Demo Migration dovrebbe verificare se l’approccio selezionato è sufficientemente solido. Per EShop, un campione utile non dimostra soltanto che Products, Customers e Orders possono comparire. Dimostra che i significati operativi più importanti dello store possono essere verificati all’interno di EShop e Joomla.
Il campione dovrebbe includere record ordinari e record portatori di rischio: Products con opzioni, Products con attributi, Products con Manufacturers, Products scaricabili, Products con allegati, Products con campi personalizzati il cui trattamento richiesto supera l’ambito della mappatura supportata, Customers appartenenti a gruppi diversi, Orders con Coupons o voucher, Orders con contesto Tax e spedizione, esempi di metodi di pagamento, record multilingua e qualsiasi dato che possa richiedere Add-ons o Custom Service.
| Area Demo Migration | Cosa verificare | Decisione supportata sull’approccio |
|---|---|---|
| Opzioni Product | Scelte obbligatorie, scelte che cambiano prezzo, SKU o immagine e output nelle righe Order. | Se la gestione standard preserva la scelta dell’acquirente. |
| Attributi e campi Product | Specifiche, campi personalizzati oltre la mappatura supportata, schede, allegati e informazioni Product aggiuntive. | Se serve mappatura o valutazione Custom Service. |
| Customers e gruppi | Identità Customer, indirizzi, relazione con Joomla User, gruppi Customer e storico account. | Se la continuità Customer è comprensibile. |
| Orders e storico commerciale | Righe Order, stati, Coupons, voucher, Tax, spedizioni, etichette pagamento, commenti e campi personalizzati. | Se i dati storici restano utili operativamente. |
| Presentazione Joomla | Menu, alias, moduli, template, pagine multilingua, metadati e percorsi sensibili per la SEO. | Se le responsabilità di implementazione sulla destinazione sono separate dall’ambito di migrazione. |
| Dati personalizzati o non supportati | Identificatori di terze parti, record di proprietà dei plugin, campi su misura e dati di vecchie estensioni. | Se Custom Service deve essere valutato prima di procedere. |
La revisione della Demo Migration dovrebbe produrre una decisione sul percorso di servizio prima della Full Migration. Se il campione è pulito, l’esecuzione standard può essere appropriata. Se è pulito ma operativamente sensibile, Managed Service può essere più sicuro. Se emergono esigenze opzionali specifiche e supportate, gli Add-ons possono essere utili. Se il significato essenziale dipende da dati personalizzati o non supportati, va valutato Custom Service.
Entity Points e pianificazione dell’ambito EShop
Gli Entity Points misurano la capacità conteggiata della migrazione. Nelle attività EShop successive, i record idonei già conteggiati restano conteggiati una sola volta sullo stesso percorso di migrazione; la complessità di estensioni Joomla, campi del processo di acquisto e plugin viene valutata separatamente. Categories, Manufacturers, Reviews, Coupons, utenti Joomla, opzioni EShop, attributi, campi personalizzati e dati di proprietà delle estensioni possono incidere su ambito e validazione, ma non devono essere trattati come tipi di dati aggiuntivi conteggiati dalla formula degli Entity Points.
| Domanda di pianificazione | Implicazione per EShop |
|---|---|
| Quanti Products, Customers, Orders e Blog Posts idonei sono previsti? | Usare questo volume per scegliere l’Entity Points Plan. |
| Quali record idonei sono già stati conteggiati nella migrazione acquistata e nel percorso fisso? | Non consumano di nuovo Entity Points soltanto perché viene eseguita un’altra azione di migrazione. |
| Quali record idonei sono stati creati successivamente? | Possono consumare Entity Points quando vengono migrati per la prima volta. |
| I Products contengono opzioni, attributi, allegati o campi personalizzati complessi? | Questi elementi incidono su mappatura, supportabilità e validazione, non sulla formula di conteggio. |
| Lo store dipende da estensioni Joomla o identificatori esterni? | Possono richiedere Custom Service anche quando il volume conteggiato è modesto. |
Gli Entity Points non dovrebbero determinare da soli il percorso di servizio. La scelta corretta dipende dal significato dei dati, dalla responsabilità di esecuzione e dal fatto che l’output richiesto rientri nel funzionamento supportato.
Azioni successive di migrazione per EShop
Le azioni successive dovrebbero essere selezionate in base a ciò che è cambiato tra la precedente attività di migrazione e il risultato di destinazione desiderato. Nei progetti EShop serve particolare attenzione a opzioni Product, attributi, relazioni Manufacturer, gruppi Customer, Orders, contenuti Joomla, URL e campi di proprietà delle estensioni.
| Azione corrente | Quando usarla | Nuova validazione specifica per EShop |
|---|---|---|
| Continue the Migration with the Last Used Configuration | Quando nuovi record idonei devono essere aggiunti usando la stessa configurazione approvata. | Controllare nuovi Products, Customers, Orders e Blog Posts insieme a opzioni, Categories, Manufacturers, immagini e URL prioritari correlati. |
| Continue the Migration with a New Configuration | Quando devono cambiare mappature supportate, filtri o scelte di configurazione. | Ricontrollare opzioni Product, attributi, campi personalizzati, gruppi Customer, campi Order interessati e ogni mappatura di destinazione modificata. |
| Perform a New Migration | Quando il risultato precedente sulla destinazione deve essere sostituito perché struttura, ambito o baseline di accettazione sono cambiati in modo rilevante. | Rivalidare l’intero campione rappresentativo, incluse relazioni di catalogo, Customers, Orders, contenuti multilingua, route Joomla e confini dei dati personalizzati. |
Queste azioni non configurano pagamenti, spedizioni, Tax, email, moduli Joomla, template o funzionamento delle estensioni attivi. Inoltre non rendono supportati i record che non lo sono. Usare gli Add-ons per esigenze supportate e circoscritte e Custom Service per la gestione non standard.
Confrontare i quattro percorsi di servizio per EShop
I quattro percorsi differiscono per ambito supportato, responsabilità di esecuzione e quantità di interpretazione necessaria. Non costituiscono una scala di qualità. La scelta migliore è il percorso meno complesso che riesce comunque a produrre un risultato che l’azienda può validare con sicurezza.
| Percorso | Più adatto a | Confine principale |
|---|---|---|
| Standard Service | Dati puliti e supportati, con esecuzione e validazione guidate con sicurezza dal Customer | Non esegue implementazione Joomla né gestione di dati non supportati |
| Managed Service | Migrazione supportata con elevato carico di coordinamento o validazione | Non trasforma dati personalizzati delle estensioni in ambito standard |
| Add-ons | Esigenze circoscritte di filtraggio record, trasformazione dei valori o rimappatura dei campi | Non sostituisce Custom Service né sviluppo sulla destinazione |
| Custom Service | Dati di estensioni non supportati, campi personalizzati il cui trattamento supera la mappatura supportata, ID esterni, trasformazioni su misura o logica di migrazione personalizzata | Ambito finale e prezzo dipendono dal lavoro personalizzato concordato |
Il confronto va applicato dopo aver compreso le evidenze EShop. Scegliere un percorso più coinvolgente non può compensare una rappresentazione di destinazione indefinita, la proprietà non chiara di un’estensione o uno standard di accettazione che nessun revisore può applicare.
Segnali che l’approccio scelto è troppo leggero
Un approccio EShop è troppo leggero quando il piano presume che l’estensione di destinazione riproduca automaticamente funzionamenti che dipendono in realtà da logica personalizzata della piattaforma di origine, configurazione di destinazione, implementazione Joomla o record non supportati. I segnali emergono normalmente durante la preparazione o la revisione della Demo Migration.
| Segnale di attenzione | Cosa suggerisce | Risposta più forte |
|---|---|---|
| I Products compaiono ma le scelte di acquisto sono incomplete | Opzioni, valori delle varianti o selezioni Product personalizzate non sono stati interpretati correttamente. | Verificare se un campo di origine supportato richiede Advanced Data Mapping o se il funzionamento della piattaforma di origine richiede Custom Service. |
| Gli attributi risultano confusi o mal collocati | Specifiche, filtri, campi personalizzati e scelte processo di acquisto possono essere stati mescolati. | Riclassificare i campi prima dell’esecuzione finale. |
| Gli Orders esistono ma non sono utili per l’assistenza | Righe Order, valori opzione, totali, stati, contesto pagamento, contesto spedizione o commenti mancano di significato. | Ampliare i campioni Order e rivedere la gestione dei campi. |
| I gruppi Customer perdono lo scopo aziendale | L’assegnazione può influire su prezzi, Tax, accesso, reportistica o assistenza Customer. | Confermare il significato del gruppo e la configurazione di destinazione. |
| Ci si aspetta che il processo di acquisto attivo funzioni automaticamente | Pagamenti, spedizioni, Tax, email e processo di acquisto necessitano di configurazione e test sulla destinazione. | Assegnare la responsabilità della configurazione lato destinazione. |
| La presentazione Joomla viene ignorata | Menu, moduli, template, alias, metadati e redirect possono non essere pronti. | Separare la validazione della migrazione dal lavoro di implementazione Joomla. |
| I campi personalizzati vengono trattati come normali record | Il significato può dipendere da vecchie app, estensioni, plugin o codice personalizzato. | Verificare prima la mappatura supportata; valutare Custom Service solo quando interpretazione o gestione richieste superano tale ambito. |
Un approccio più forte non significa sempre Custom Service. A volte la risposta corretta è una preparazione migliore, un campione Demo Migration più rappresentativo, Managed Service o Add-ons. L’importante è classificare correttamente il problema prima che l’azienda si affidi al risultato per il lancio.
Conclusione
L’approccio giusto per una migrazione EShop dipende dal significato reale dei dati dello store, non soltanto dal volume dei record. Standard Service può essere adatto a dati puliti e supportati quando l’azienda può gestire autonomamente esecuzione e validazione. Managed Service è più sicuro quando la migrazione è standard per capacità ma sensibile sul piano operativo. Data Filter, Advanced Data Mapping o Data Transformation possono supportare un controllo definito e circoscritto. Custom Service va valutato quando il progetto dipende da dati Custom Platform, dati di estensioni non supportati, campi su misura, record di proprietà dei plugin, identificatori di integrazione, Tailored Add-ons, Custom Add-ons o logica di migrazione personalizzata.
Demo Migration dovrebbe dimostrare la validità dell’approccio prima dell’esecuzione. Il campione dovrebbe verificare opzioni Product, attributi, campi personalizzati, allegati, Manufacturers, Customers, gruppi Customer, Orders, Coupons, voucher, Tax, spedizioni, contesto di pagamento, contenuti multilingua, presentazione Joomla e dati personalizzati. Un buon approccio è quello che fornisce al futuro store EShop struttura, contesto e fiducia nella validazione sufficienti per operare dopo il lancio.
Domande frequenti
Quali evidenze bisogna preparare per valutare Custom Service in una migrazione EShop?
Preparare esempi EShop che espongano campi del processo di acquisto con regole aziendali, record di estensioni non supportati e contesto di pagamento o spedizione di proprietà dei plugin. Documentare come ogni valore influisce sull’azienda, dove dovrebbe essere rappresentato e come l’output concordato di Custom Service sarà validato separatamente dalla configurazione Joomla.
Quando Managed Service è più adatto per EShop?
Managed Service è più adatto quando i dati rientrano ancora nelle capacità standard ma il progetto richiede esecuzione guidata da Next-Cart, validazione coordinata, gestione di un ambito più ampio, revisione multilingua o maggiore controllo sul lancio.
Gli Add-ons sostituiscono Custom Service?
No. Gli Standard Add-ons supportano condizioni definite sui tipi di dati, espressioni sui valori o destinazioni di campi della piattaforma di origine. Custom Service è necessario quando il requisito coinvolge dati Custom Platform, dati di estensioni non supportati, interpretazione su misura, Tailored Add-ons, Custom Add-ons o logica di migrazione personalizzata.
Cosa dovrebbe verificare Demo Migration prima di scegliere l’approccio finale?
Demo Migration dovrebbe verificare Products, opzioni, attributi, campi personalizzati, allegati, Customers, gruppi Customer, Orders, Coupons, voucher, Tax, spedizioni, contesto di pagamento, record multilingua, dipendenze di presentazione Joomla e qualsiasi dato personalizzato o non supportato.
Il funzionamento attivo di pagamenti, spedizioni e Tax può essere migrato automaticamente?
Il contesto storico di pagamenti, spedizioni e Tax può restare utile nei vecchi Orders, ma il funzionamento futuro richiede normalmente configurazione lato destinazione, configurazione dei plugin e test in EShop.