Scegliere l’approccio di migrazione corretto per Phoca Cart richiede di separare i record e-commerce dall’ambiente Joomla che attribuisce loro significato operativo. Phoca Cart può gestire Products, Categories, Manufacturers, attributi, opzioni, specifiche, stock, Customers, Customer Group, Orders, Coupons, premi, valute, lingue, tasse, fatture, metodi di pagamento, metodi di spedizione e attività Point of Sale. È inoltre modulare: plugin, moduli, template, integrazioni di contenuto, livelli di accesso e codice personalizzato possono modificare il funzionamento di un singoil negozio.
Il percorso di servizio deve riflettere dove sono posseduti i dati e il funzionamento richiesti. Standard Service può essere adatto a un percorso di migrazione supportato e lineare. Managed Service aiuta quando il cliente necessita di esecuzione specialistica e validazione coordinata. Gli Add-ons supportano esigenze circoscritte di filtro dei record, trasformazione dei valori dei campi o rimappatura dei campi entro il comportamento supportato. Custom Service è necessario quando il risultato atteso dipende da record di estensioni non supportati, campi personalizzati che richiedono interpretazione non standard o gestione oltre la mappatura supportata, trasformazioni su misura, identificativi esterni o logica di migrazione personalizzata.
All’interno dei Migration Services di Next-Cart, le evidenze relative a Phoca Cart devono distinguere dati e-commerce supportati, necessità di esecuzione guidata da specialisti, dipendenze Joomla e gestione personalizzata delle estensioni.
Partire dall’ambito Phoca Cart e Joomla
Phoca Cart è un’estensione e-commerce per Joomla, non un’applicazione isolata per il sito pubblico. Il piano di migrazione deve quindi identificare quali requisiti appartengono ai record e-commerce principali, quali a contenuti e struttura del sito Joomla, quali alla configurazione Phoca Cart e quali derivano da plugin o sviluppo personalizzato.
| Livello di ambito | Esempi tipici | Implicazione per il percorso di servizio |
|---|---|---|
| Dati e-commerce principali | Products, Categories, Manufacturers, Customers, Orders, Coupons, Reviews, immagini | Possono rientrare in Standard o Managed Service quando supportati e strutturalmente chiari |
| Funzionamento Product | Attributi, opzioni, specifiche, download, stock, Products correlati, prezzi di gruppo | Richiede mappatura rappresentativa ed evidenze da Demo Migration |
| Contesto Joomla | Utenti, livelli di accesso, menu, alias, moduli, lingue, contenuti e URL | Deve essere separato tra dati migrabili, configurazione della destinazione e implementazione del sito |
| Livello estensioni | Plugin di pagamento e spedizione, POS, premi, newsletter, strumenti PDF, moduli personalizzati | Può richiedere Custom Service o implementazione separata nella destinazione |
| Configurazione operativa | Tasse, valute, lingue, pagamento, spedizione, fatture, stati, impostazioni template | Non viene ricreata automaticamente dalla migrazione dello storico dei record |
Anche uno negozio con catalogo ridotto può richiedere un percorso di servizio impegnativo quando campi Joomla personalizzati, opzioni Product, Customer Group, plugin o integrazioni esterne sono essenziali. Uno negozio più grande può invece restare adatto a Standard Service quando i record sono convenzionali e il cliente è in grado di validare autonomamente il risultato.
Quando Standard Service può essere sufficiente
Standard Service è appropriato quando il percorso di migrazione è supportato e i dati richiesti rientrano nel comportamento standard. Con questo servizio Next-Cart, il cliente è responsabile delle scelte di configurazione, dell’esecuzione della migrazione e della validazione.
Un buon candidato per Standard Service presenta in genere:
- Products, Categories, Manufacturers, Customers, Orders e contenuti supportati chiaramente definiti;
- attributi, opzioni e specifiche comprensibili;
- identificativi Product e relazioni con le immagini coerenti;
- Customer Group e indirizzi ordinari;
- Orders storici leggibili senza significati nascosti posseduti da plugin;
- un ambito linguistico e valutario definito;
- un uso limitato di campi personalizzati e dati di estensioni;
- nessuna aspettativa che template Joomla, moduli, plugin o impostazioni del checkout operativo vengano ricostruiti tramite la migrazione;
- un team in grado di valutare i risultati di Demo Migration e Full Migration.
Standard Service va scelto perché i dati sono supportati e il cliente può gestire il lavoro, non perché il negozio appare visivamente semplice. Phoca Cart può nascondere significato rilevante dietro opzioni Product, prezzi per Customer Group, regole premio, plugin di pagamento, plugin di spedizione e configurazione multilingue.
Quando Managed Service è una scelta migliore
Managed Service è appropriato quando la migrazione resta ampiamente supportata ma l’azienda ha bisogno degli specialisti Next-Cart per gestire l’esecuzione e coordinare la validazione. È particolarmente utile quando le responsabilità Joomla ed e-commerce sono distribuite tra team diversi.
Managed Service può essere preferibile quando:
- l’azienda non è sicura di poter gestire autonomamente la migrazione;
- più lingue, valute, Customer Group o strutture Product richiedono una revisione coordinata;
- un volume elevato di Products o Orders crea un carico di validazione significativo;
- la finestra di lancio richiede pianificazione strutturata e gestione delle anomalie;
- responsabili business, amministratori Joomla e partner di implementazione devono approvare aree diverse del risultato;
- i dati della sorgente sono supportati ma abbastanza incoerenti da richiedere una revisione disciplinata;
- Expert Handle è richiesto nell’ambito del servizio concordato.
Managed Service non rende standard i dati di plugin non supportati. Gestisce esecuzione e coordinamento. Se un requisito critico necessita di estrazione o trasformazione non standard, Custom Service deve comunque essere definito per quel requisito.
Dove si inseriscono gli Add-ons
Gli Add-ons sono utili quando la migrazione principale resta supportata ma serve una modifica circoscritta. Possono applicare filtri dei record per Data Type, trasformazioni dei valori dei campi basate su espressioni, rimappatura di campi standard supportati oppure, quando il percorso è idoneo, rimappatura di colonne del database, senza trasformare l’intero progetto Phoca Cart in un progetto personalizzato.
Esempi:
- applicare condizioni supportate sui campi Product, Customer, Order o contenuto tramite Data Filter;
- applicare espressioni per trasformare valori di campi supportati tramite Data Transformation;
- rimappare campi standard supportati della sorgente verso campi supportati e compatibili della destinazione mantenendo invariato il valore tramite Advanced Data Mapping;
- mappare colonne di database supportate della sorgente verso colonne di database Phoca Cart compatibili, mantenendo invariati i valori, tramite Advanced Database Mapping, purché anche la Source Platform sia Open-Source;
- gestire specifici risultati SEO o di contenuto quando supportati;
- validare i set di record filtrati, i valori trasformati e i campi rimappati rispetto ad aspettative definite.
Gli Add-ons non devono essere presentati come sostituti di Custom Service. Rimappare un campo Product standard e supportato della sorgente verso un campo supportato e compatibile della destinazione, mantenendo invariato il valore, può rientrare in Advanced Data Mapping. In una migrazione verso Phoca Cart, la mappatura di colonne database supportate può rientrare in Advanced Database Mapping solo quando anche la Source Platform è Open-Source. Estrarre lo storico dei premi da una tabella plugin personalizzata, ricostruire relazioni POS o trasformare un sistema di attributi su misura non rientra in questo caso.
Il confine dipende dal fatto che il requisito resti o meno entro il comportamento di migrazione supportato. Se sì, può bastare un Add-on. Se richiede interpretazione su misura, logica personalizzata o dati non supportati, il percorso corretto è Custom Service.
Quando serve Custom Service
Custom Service deve essere valutato quando il risultato atteso dipende da dati o logiche fuori dalle strutture standard supportate. Nei progetti Phoca Cart, questa necessità può derivare da personalizzazioni Joomla, record posseduti da estensioni e comportamenti Product o Customer specializzati.
Segnali di escalation comuni:
- campi Product personalizzati, attributi, opzioni o specifiche archiviati fuori dalle strutture standard;
- regole Customer Group personalizzate, storico premi o logica di prezzo;
- record POS o riferimenti inventario esterni;
- dati di pagamento, spedizione, fatturazione o tasse archiviati in tabelle plugin;
- utenti Joomla personalizzati, relazioni di accesso, logica dei menu o associazioni multilingue;
- moduli personalizzati, override del template o integrazioni di contenuto che memorizzano record essenziali per il business;
- identificativi ERP, contabilità, evasione, newsletter, marketplace o CRM esterni;
- trasformazioni su misura tra campi della sorgente e Target Platform;
- una Custom Platform su uno dei due lati del percorso di migrazione;
- requisiti che modificano la logica standard di migrazione.
Custom Service non include automaticamente aggiornamenti Joomla, installazione di Phoca Cart, sviluppo di estensioni o plugin, ricostruzione del template, implementazione POS, configurazione di pagamento e spedizione, distribuzione di integrazioni esterne o costruzione completa del Target Store. Queste responsabilità devono essere incluse esplicitamente nell’ambito concordato.
Come gli Entity Points incidono sulla pianificazione
Gli Entity Points aiutano a dimensionare i record idonei che vengono migrati. Nelle attività successive su Phoca Cart, i record idonei già conteggiati restano conteggiati una sola volta sullo stesso percorso di migrazione; la complessità di Joomla, plugin, campi personalizzati e specifiche viene valutata separatamente. Categories, Manufacturers, Reviews, Coupons, attributi, opzioni, specifiche, Customer Group, premi, CMS Pages, record plugin e identificativi esterni possono aumentare la complessità senza diventare Data Type conteggiati separatamente negli Entity Points.
Gli Entity Points conteggiano nuovi Products, Customers, Orders e Blog Posts idonei quando vengono migrati per la prima volta. Phoca Cart Categories, Manufacturers, Reviews, Coupons, specifiche, record plugin e identificativi esterni possono aumentare il lavoro di revisione senza creare nuovi tipi di record conteggiati, mentre i record già conteggiati restano conteggiati una sola volta sullo stesso percorso.
Questa distinzione mantiene separati volume e complessità:
| Condizione di pianificazione | Effetto sugli Entity Points | Effetto sul percorso di servizio |
|---|---|---|
| Molti Products ordinari | Richiedono capacità adeguata | Possono comunque rientrare in Standard Service |
| Pochi Products con opzioni personalizzate o dati plugin | Volume inferiore | Possono richiedere Custom Service |
| Nuovi Orders creati prima del lancio | Possono consumare Entity Points quando migrano per la prima volta | Richiedono validazione successiva |
| Record esistenti migrati di nuovo sullo stesso percorso | Nessun consumo duplicato solo perché avviene un’altra azione | La configurazione deve comunque restare valida |
Gli Entity Points devono essere pianificati prima della Full Migration, ma non devono mai essere usati come prova che strutture Joomla o Phoca Cart personalizzate siano supportate.
Cosa deve dimostrare la Demo Migration
La Demo Migration deve testare i record difficili, non soltanto quelli più puliti. Un campione utile per Phoca Cart comprende:
- Products semplici e Products con attributi, opzioni, specifiche o download;
- Products che usano prezzi di gruppo, premi, controlli stock o valori multilingue;
- Customers appartenenti a gruppi e contesti di accesso differenti;
- Orders con sconti, Coupons, tasse, pagamento, spedizione, storico degli stati e fatture;
- CMS Pages, Blog Posts, menu, alias e URL prioritari;
- record influenzati da plugin, moduli, POS o sistemi esterni;
- esempi per ogni lingua, valuta o contesto rilevante del sito pubblico.
La Demo Migration deve dimostrare che l’approccio scelto preserva un significato di business utilizzabile. Deve inoltre classificare correttamente le lacune:
- configurazione supportata della destinazione;
- requisito circoscritto da Add-on;
- requisito da Custom Service;
- responsabilità separata di implementazione Joomla o Phoca Cart.
Il progetto non dovrebbe passare alla Full Migration presumendo che un volume maggiore risolva una lacuna strutturale già visibile nel campione.
Additional Migration Options per Phoca Cart
Le Additional Migration Options vanno selezionate in base al fatto che la configurazione accettata sia ancora valida e a ciò che è cambiato dopo l’attività di migrazione precedente.
| Azione corrente | Situazione appropriata | Focus di rivalidazione Phoca Cart |
|---|---|---|
| Continue the Migration with the Last Used Configuration | Ambito, mappature e filtri accettati restano validi mentre occorre elaborare nuova attività nella sorgente. | Nuovi Products, Customers, Orders, Blog Posts, attributi, opzioni, valori linguistici, URL e identificativi di integrazione. |
| Continue the Migration with a New Configuration | Lo stesso percorso di migrazione resta corretto, ma filtri, mappature o impostazioni della destinazione supportati devono cambiare. | Strutture Product, Customer Group, stati degli Orders, selezione contenuti, ambito linguistico, URL ed esclusioni. |
| Perform a New Migration | L’azienda necessita di un risultato di destinazione distinto, non della continuazione della configurazione precedente. | Ambito e-commerce completo, Joomla, contenuti, plugin, SEO e criteri di accettazione. |
Queste azioni non installano plugin, non ricostruiscono template, non configurano pagamento o spedizione, non implementano POS e non distribuiscono automaticamente integrazioni esterne. Operano entro l’ambito del Migration Service concordato e non modificano il percorso Source Platform-to-Target Platform fissato con l’acquisto. Un percorso di piattaforma differente richiede un Migration Service separato.
Separare i record migrati dall’implementazione Phoca Cart
Phoca Cart combina dati, contesto Joomla e configurazione operativa. Prima di concordare costi e responsabilità, l’approccio di migrazione deve identificare quale livello possiede ogni risultato atteso.
| Risultato atteso | Proprietario principale | Implicazione per il percorso di servizio |
|---|---|---|
| Products, Customers, Orders, Blog Posts e record correlati supportati | Migration Service | Valutare supporto, mappatura, Entity Points e criteri di accettazione. |
| Categories, Manufacturers, attributi, opzioni, specifiche e relazioni di contenuto | Migrazione + validazione della destinazione | Confermare come vengono rappresentate le relazioni supportate e quali impostazioni della destinazione restano necessarie. |
| Tasse, valute, pagamento, spedizione, fatture, stati e funzionamento POS | Configurazione Phoca Cart e provider | I valori storici possono restare riferimenti, ma il funzionamento operativo deve essere configurato e testato separatamente. |
| Menu, moduli, lingue, livelli di accesso, alias e template Joomla | Implementazione del sito | Coordinare con i risultati della migrazione senza presumere la ricostruzione completa del sito. |
| Plugin ed estensioni personalizzate | Proprietario dell’estensione o sviluppo | Identificare i dati che richiedono Custom Service e il funzionamento da reimplementare separatamente. |
| Sistemi esterni di contabilità, evasione, newsletter, CRM o marketplace | Responsabile integrazione | Preservare gli identificativi concordati e ridistribuire le connessioni fuori dall’esecuzione ordinaria della migrazione. |
Questa separazione evita di classificare una lacuna di configurazione della destinazione come difetto dei dati. Impedisce anche che dati appartenenti a un’estensione vengano liquidati come semplice implementazione quando devono realmente essere estratti o trasformati tramite Custom Service. I risultati della Demo Migration devono essere classificati rispetto a questa mappa di proprietà prima di finalizzare il percorso di servizio.
Usare scenari pratici per scegliere il percorso di servizio
Scenario 1: catalogo standard e record storici. I Products usano attributi e opzioni ordinari, Customers e Orders sono leggibili e il team della destinazione configurerà Phoca Cart. Standard Service può essere sufficiente quando la Demo Migration conferma i campioni più difficili.
Scenario 2: progetto supportato ma operativamente impegnativo. Il negozio contiene più lingue, Customer Group, molti Orders e una finestra di lancio definita, ma non richiede record di estensioni non supportati. Managed Service può essere più adatto perché esecuzione e validazione sono i rischi principali.
Scenario 3: requisito definito di filtro o rimappatura campi. L’azienda deve escludere Products inattivi tramite condizioni su campi Product, escludere determinati Orders tramite condizioni sui campi Order oppure rimappare campi standard supportati della sorgente verso campi supportati e compatibili della destinazione mantenendo invariati i valori. Data Filter o Advanced Data Mapping possono soddisfare il requisito senza Custom Service. Una mappatura di colonne database idonea può invece usare Advanced Database Mapping, purché anche la Source Platform sia Open-Source.
Scenario 4: record premio, POS o plugin personalizzati. Dati essenziali per il business si trovano in tabelle di estensioni o campi Joomla personalizzati che richiedono un’interpretazione non standard oltre la mappatura supportata. Custom Service deve essere definito per questi record. Installazione del plugin, ricostruzione del POS o configurazione del checkout operativo restano separate salvo inclusione esplicita.
Scenario 5: modifiche di configurazione dopo la Demo Migration. Opzioni Product, ambito linguistico, Customer Group o selezione dei contenuti richiedono una modifica supportata mentre il percorso di migrazione resta lo stesso. Usare Continue the Migration with a New Configuration invece di presumere che la configurazione precedente debba essere riutilizzata.
Scenario 6: serve un risultato migrato realmente distinto sullo stesso percorso acquistato. L’azienda necessita di un risultato indipendente e pulito mentre il percorso Source Platform-to-Target Platform acquistato resta invariato. Usare Perform a New Migration e rivalidare ambito completo, criteri di accettazione e responsabilità della destinazione. Se deve cambiare la Source Platform o la Target Platform, è necessario acquistare un Migration Service separato per il nuovo percorso.
Ogni scenario deve essere supportato da record rappresentativi e da un risultato atteso documentato. In questo modo la scelta finale del servizio è difendibile e l’ampiezza funzionale della piattaforma non diventa una giustificazione vaga per sovradimensionare o sottodimensionare il progetto.
Decisione finale sul percorso di servizio Phoca Cart
| Evidenza | Percorso di servizio probabile |
|---|---|
| Record supportati, strutture Product chiare, contesto Joomla ordinario, operatività gestita dal cliente | Standard Service |
| Ambito supportato con elevato carico di esecuzione, coordinamento o validazione | Managed Service |
| Esigenze circoscritte e supportate di filtro record, trasformazione valori dei campi, rimappatura campi supportati o rimappatura idonea di colonne database su migrazioni in cui Source e Target Platform sono entrambe Open-Source | Standard o Managed Service con Add-ons |
| Tabelle plugin, campi personalizzati che richiedono interpretazione non standard, trasformazioni su misura, POS, identificativi esterni o logica Joomla personalizzata | Custom Service, potenzialmente con Expert Handle e Add-ons concordati |
La decisione deve essere confermata prima della Full Migration e testata attraverso la Demo Migration. L’approccio corretto preserva il significato di business dei record Phoca Cart senza implicare che l’intero sito Joomla e il suo ambiente di estensioni facciano parte della migrazione dati standard. Il piano approvato deve identificare servizio, Add-ons, requisiti Custom Service, Entity Points Plan, responsabili della validazione, configurazione della destinazione, lavoro sulle estensioni e scelta per la migrazione successiva. In questo modo le responsabilità di lancio restano visibili e il lavoro Joomla o sui plugin non ancora risolto non viene confuso con un risultato di migrazione accettato.
Conclusione
La scelta dell’approccio di migrazione verso Phoca Cart dipende dalla separazione tra record e-commerce supportati, contesto Joomla, configurazione della destinazione, dati posseduti dalle estensioni e implementazione personalizzata. Standard Service è adatto ai percorsi supportati e lineari. Managed Service aiuta con esecuzione e validazione. Gli Add-ons gestiscono esigenze supportate e circoscritte. Custom Service copre requisiti su misura e non standard.
Le Additional Migration Options devono poi riflettere se la configurazione accettata resta valida, necessita di modifiche o deve essere sostituita da un nuovo risultato di migrazione.
Domande frequenti
Standard Service può essere sufficiente per Phoca Cart?
Sì. Può essere sufficiente quando il percorso di migrazione è supportato, i record principali sono chiari, le strutture Product sono riconoscibili e il cliente può gestire e validare il servizio in autonomia.
Quando scegliere Managed Service per una migrazione verso Phoca Cart?
Managed Service è utile quando l’ambito è supportato ma l’azienda necessita di esecuzione specialistica, revisione coordinata tra team Joomla ed e-commerce oppure pianificazione disciplinata del lancio.
Gli Add-ons migrano i plugin Phoca Cart?
No. Gli Add-ons coprono requisiti supportati e circoscritti. Tabelle plugin, dati POS, logica premio personalizzata, attributi su misura e record di sistemi esterni richiedono in genere una revisione Custom Service o un’implementazione separata.
Cosa deve dimostrare la Demo Migration per Phoca Cart?
Deve verificare opzioni e attributi Product, Customer Group, Orders, dati multilingue, contenuti, URL e record collegati alle estensioni e mostrare se le lacune appartengono a configurazione, Add-ons, Custom Service o implementazione separata.
Quale Additional Migration Option è adatta a un’attività successiva su Phoca Cart?
Usare Last Used Configuration quando la configurazione accettata resta valida, New Configuration quando devono cambiare impostazioni supportate e New Migration quando serve un risultato distinto con rivalidazione completa.