Se J2Commerce viene scelto come piattaforma di destinazione, la preparazione deve collegare i record commerce alle strutture Joomla che li rendono visibili e utilizzabili. I Products possono dipendere da articoli Joomla, Categories, menu, moduli, campi personalizzati, gruppi di utenti, applicazioni, estensioni di pagamento, estensioni di spedizione e layout dei template. I tipi di Product specializzati possono aggiungere varianti, download, abbonamenti, prenotazioni, bundle, acconti o dati inseriti dal Customer che non possono essere compresi dal solo conteggio dei Products.
Il pacchetto di preparazione dovrebbe definire ogni azione, responsabile, elemento di prova e condizione di prontezza prima dell’inizio della migrazione. Deve inoltre separare i record che rientrano nel perimetro di migrazione da configurazioni attive di processo di acquisto, imposte, pagamenti, spedizioni, notifiche, cron ed estensioni che appartengono all’implementazione sulla destinazione.
La preparazione dovrebbe produrre un campione J2Commerce rappresentativo, far emergere eventuali esigenze di mappatura o gestione su misura e separare chiaramente il perimetro di migrazione dall’implementazione Joomla e J2Commerce prima dell’esecuzione su scala più ampia.
Mettere in sicurezza accessi a Joomla, J2Commerce, hosting e database
Confermare l’accesso ad amministrazione Joomla, amministrazione J2Commerce, hosting, database, filesystem, media, attività pianificate e servizi esterni. Registrare versione Joomla, versione J2Commerce, versioni PHP e database, template attivo, lingue abilitate, applicazioni installate, estensioni di pagamento e spedizione ed eventuale codice personalizzato.
| Azione di preparazione | Responsabile | Riscontro | Condizione di prontezza |
|---|---|---|---|
| Confermare l’accesso amministrativo | Amministratore Joomla/J2Commerce | Account funzionanti e riepilogo dei ruoli | Catalogo, Orders, Customers, applicazioni, menu e configurazione possono essere ispezionati. |
| Creare backup ripristinabili | Responsabile infrastruttura | Esportazione database, archivio filesystem, note sui media esterni e responsabile del ripristino | Il sistema di origine può essere recuperato senza dipendere dal negozio attivo. |
| Documentare l’ambiente delle estensioni | Responsabile tecnico | Inventario con versioni di componenti, plugin, moduli, template e applicazioni | Ogni dipendenza commerce è elencata con un responsabile. |
| Registrare processi pianificati ed esterni | Responsabile integrazioni | Cron job, endpoint webhook, collegamenti ERP/PIM/WMS/CRM/pagamenti/spedizioni e ID esterni | Sono identificati integrazioni che devono continuare e sistemi autorevoli per i dati. |
| Conservare gli identificatori di origine | Coordinatore della migrazione | ID Product, Article, Category, utente, Customer, Order, opzione, variante, abbonamento ed esterni | Le relazioni tra record possono essere tracciate dopo l’estrazione. |
Se il negozio nasce da J2Store o ha attraversato un importante cambio di versione, registrarne la storia. Etichette simili possono riferirsi a tabelle o versioni applicative differenti e personalizzazioni più vecchie possono ancora dipendere da campi legacy.
Preparare i Products in base al modo in cui vengono venduti
Non classificare i Products J2Commerce soltanto per nome o quantità. Prepararli in base al funzionamento che deve restare comprensibile: vendita semplice, vendita tramite variante, download, abbonamento, prenotazione, bundle, servizio, acconto, elemento personalizzato o tipo di Product gestito da un’applicazione.
| Modello Product | Riscontri richiesti | Condizione di prontezza |
|---|---|---|
| Product fisico semplice | ID articolo/Product, SKU, prezzo, profilo fiscale, stock, peso, immagini, collegamenti Category e Order di esempio | Un record identifica chiaramente l’elemento vendibile e la sua relazione con il contenuto Joomla. |
| Product con varianti | Definizioni delle opzioni, valori, varianti generate, SKU/prezzo/stock/immagine per variante e ID del Product padre | Ogni combinazione vendibile può essere ricondotta al Product padre e ai valori selezionati. |
| Product scaricabile | Record dei file, regole di accesso, limiti, scadenza, collegamento Product e Order completato di esempio | Proprietà dei file e dati che dimostrano l’accesso basato sull’Order sono completi. |
| Product in abbonamento | Tipo di Product, piano/variante, intervallo di fatturazione, prova, stato, dipendenza dal pagamento, dipendenza cron, collegamento al gruppo utenti Joomla e abbonamento di esempio | Stato ricorrente e relazioni di accesso hanno un responsabile e una decisione sulla destinazione. |
| Product con prenotazione o riservazione | Risorsa, regole di data/ora, capacità, prezzo, input Customer e prenotazione di esempio | Record di disponibilità e cronologia delle prenotazioni sono separati dai normali campi Product. |
| Product bundle o raggruppato | Product padre, Products componenti, quantità, regole di prezzo, relazione di stock e Order di esempio | Identità e proprietà dei componenti sono documentate. |
| Product personalizzato | Definizioni dei campi di input, funzionamento delle opzioni, file forniti dall’acquirente, effetti sul prezzo e riga Order di esempio | I dati inseriti dall’acquirente restano distinguibili dagli attributi Product riutilizzabili. |
Per ogni tipo di Product, registrare quali valori controllano identità, prezzo, stock, imposte, peso, spedizione, accesso, rinnovo o evasione degli ordini. Se un’applicazione o un plugin personalizzato gestisce parte del funzionamento, includerne tabelle, chiavi e dipendenze di configurazione nel pacchetto di riscontri.
Preparare opzioni, varianti, campi personalizzati e relazioni con gli articoli
I Products J2Commerce possono essere collegati ai contenuti degli articoli Joomla e alle strutture di opzioni o varianti J2Commerce. La preparazione deve distinguere i contenuti Product condivisi dai dati delle combinazioni vendibili e dai valori inseriti dal Customer.
| Relazione | Riscontro | Condizione di prontezza |
|---|---|---|
| Articolo Joomla → Product | ID articolo, ID Product, alias, lingua, livello di accesso e campi dei contenuti | Il contenuto Product non viene separato accidentalmente dal record Product. |
| Opzione Product | Nome opzione, tipo, valori, ordinamento, effetto sul prezzo e assegnazione Product | Le definizioni delle scelte riutilizzabili sono documentate. |
| Variante | Product padre, valori opzione selezionati, SKU, stock, prezzo, immagine, stato e ID esterno | Ogni unità realmente vendibile ha un record univoco e tracciabile. |
| Campo personalizzato | Definizione del campo, contesto, valori, finalità aziendale e layout/applicazione che lo utilizza | I dati descrittivi non vengono confusi con una scelta dell’acquirente o con lo stato di un’applicazione. |
| Input Customer | Definizione dell’input e valore di esempio nella riga Order | L’input fornito una sola volta dall’acquirente resta collegato al contesto dell’acquisto. |
Normalizzare le etichette di opzione palesemente duplicate soltanto dopo aver conservato terminologia e relazioni originali. Se “Colour”, “Color” e “Finish” hanno significati aziendali diversi nel sistema di origine, non unirli soltanto perché sembrano simili.
Preparare Categories, menu, URL, media e scoperta nella vetrina online
La scoperta del catalogo J2Commerce può dipendere da Categories Joomla, ordinamento degli articoli, voci di menu, moduli, filtri, ricerca, layout dei template e media Product. Un Product può essere completo nell’amministrazione ma non raggiungibile attraverso l’URL previsto.
Preparare una mappa Product-Category, la gerarchia delle Categories, riscontri sull’ordinamento degli articoli, inventario delle voci di menu, assegnazioni dei moduli, valori dei filtri, URL prioritari, redirect, riferimenti alle immagini e assegnazioni linguistiche. Includere i percorsi per pagine Product, viste Category, pagine account, download, gestione degli abbonamenti, carrello, processo di acquisto e principali landing page delle campagne.
| Area di scoperta | Riscontri da preparare | Condizione di prontezza |
|---|---|---|
| Appartenenza alle Categories | ID Product/Article e gerarchia Category | I Products nel perimetro hanno una collocazione intenzionale per la scoperta. |
| Routing dei menu | Tipo di voce di menu, padre, alias, lingua, livello di accesso e destinazione | I principali percorsi della vetrina online hanno URL di destinazione espliciti. |
| Moduli e filtri | Posizione del modulo, assegnazione ai menu, origine del filtro ed estensione responsabile | Il funzionamento della scoperta è separato dai dati Product. |
| Media Product | Percorsi file, immagini principali/aggiuntive/di variante, testo alternativo e note su storage remoto | Le relazioni dei media sono tracciabili al Product o alla variante corretti. |
| Redirect e metadati | URL di origine, finalità sulla destinazione, metadati, note canoniche e riscontri sull’estensione di routing | Gli URL di maggior valore hanno un trattamento previsto. |
Non presumere che migrare i Products ricrei menu Joomla, posizioni dei moduli, viste dei template o funzionamento di ricerca e filtri. Sono responsabilità separate dell’implementazione di destinazione, ma le loro relazioni nel sistema di origine devono essere documentate.
Preparare Customers, utenti Joomla, gruppi e indirizzi
L’identità Customer in J2Commerce può coinvolgere utenti Joomla, acquirenti ospiti, record indirizzo, gruppi Customer, campi aziendali, identificativi fiscali, relazioni di membership e chiavi CRM o ERP esterne. Preparare questi elementi separatamente.
| Aspetto dell’account | Riscontri | Condizione di prontezza |
|---|---|---|
| Customer registrato | ID utente Joomla, ID Customer, email, stato, gruppi, indirizzi e ID esterni | Casi duplicati e appartenenza a più gruppi hanno un trattamento previsto. |
| Customer ospite | Identità e indirizzi a livello di Order | La cronologia dell’ospite non viene forzata in account utente inventati. |
| Gruppo Customer | Definizione del gruppo e relativo funzionamento di prezzo, imposte, accesso o sconto | Il significato del gruppo è documentato oltre la semplice etichetta. |
| Identità aziendale o fiscale | Campi aziendali, numeri fiscali, stato di validazione e riferimento account esterno | I dati dell’account aziendale hanno un responsabile preciso sulla destinazione. |
| Autenticazione | Password locale, SSO, social login, MFA, flusso di reset e responsabile delle comunicazioni | L’accesso agli account è pianificato senza presumere la portabilità delle password. |
Se un’applicazione di abbonamento o membership modifica i gruppi utenti Joomla dopo l’acquisto, includere stato di attivazione, collegamento Product, gruppo di destinazione, stato dell’abbonamento e Orders di esempio pertinenti. L’assegnazione al gruppo è quindi una relazione gestita dall’applicazione, non semplice metadato Customer.
Preparare Orders, pagamenti, spedizioni, imposte e cronologia post-vendita
Gli Orders storici dovrebbero spiegare cosa è stato acquistato e cosa è accaduto. Preparare intestazioni Order, righe Order, riferimenti Product/variante, opzioni selezionate, valori inseriti dal Customer, indirizzi, prezzi, sconti, imposte, etichette di pagamento, etichette di spedizione, stati, commenti, transazioni, fatture, rimborsi, download, abbonamenti e riferimenti alle prenotazioni quando presenti.
| Riscontro Order | Responsabile | Condizione di prontezza |
|---|---|---|
| Intestazione Order e cronologia stati | Operazioni commerce | Sequenza degli stati e timestamp sono comprensibili. |
| Righe Order | Catalogo e operazioni | Product, variante, SKU, valori selezionati, quantità e prezzo sono conservati come istantanee storiche. |
| Dati di pagamento | Finanza o responsabile pagamenti | Etichetta del metodo e riferimento transazione sono documentati senza trattare le credenziali come dati migrati. |
| Dati di spedizione | Responsabile evasione degli ordini | Etichetta del metodo, costo, tracking e contesto di spedizione sono disponibili dove utilizzati. |
| Dati fiscali e sconti | Finanza o responsabile commerce | Importi ed etichette applicati possono essere riconciliati con i totali. |
| Record post-vendita | Responsabile servizio Customer | Rimborsi, download, modifiche agli abbonamenti, cancellazioni o stato delle prenotazioni sono collegati all’Order. |
Creare un glossario degli stati che spieghi il significato operativo di ogni stato Order, pagamento, spedizione, abbonamento e prenotazione nel sistema di origine. Etichette simili possono rappresentare stati differenti tra estensioni diverse.
Inventariare applicazioni, plugin, tabelle personalizzate e integrazioni
Applicazioni J2Commerce ed estensioni Joomla possono gestire abbonamenti, prenotazioni, bundle, acconti, spedizioni, pagamenti, sconti, sincronizzazione stock, feed Product, fatture, loyalty, recensioni e dati personalizzati del processo di acquisto. Il pacchetto di preparazione deve identificare chi gestisce realmente ciascun record.
Per ogni estensione importante, registrare nome, versione, tabelle, campi, chiavi primarie, chiavi esterne, riferimenti Product/Customer/Order, dipendenze di configurazione, attività pianificate, servizi esterni e responsabile aziendale attuale. Classificare il requisito come record nativo, record gestito da applicazione, record di sistema esterno, configurazione della destinazione, presentazione o candidato alla dismissione.
Gli identificatori esterni richiedono attenzione separata. ID Product ERP, ID Customer CRM, ID di listing marketplace, codici di magazzino, ID transazione di pagamento e riferimenti del gateway di abbonamento possono essere campi piccoli ma chiavi di relazione fondamentali.
La condizione di prontezza è raggiunta quando nessun record commerce necessario viene descritto soltanto come “dati personalizzati” o “dati dell’app”. Ogni insieme di dati attivo deve avere un’entità identificata, un responsabile, riscontri nell’origine e una decisione sulla destinazione.
Separare i record migrati dalla configurazione della destinazione
Il funzionamento corrente di imposte, pagamenti, spedizioni, email, valute, cron, processo di acquisto, cache, template e sicurezza appartiene all’implementazione della destinazione. I record storici possono conservare etichette e importi senza configurare il comportamento attivo.
| Riscontro del sistema di origine da preparare | Responsabilità sulla destinazione da mantenere separata |
|---|---|
| Etichette di pagamento storiche e ID transazione | Account gateway, credenziali, callback, impostazioni antifrode e test dei pagamenti attivi |
| Etichette di spedizione e tracking storici | Account corrieri, tariffe, zone, imballaggio, ritiro e configurazione dell’evasione degli ordini |
| Importi fiscali storici e riferimenti ai profili fiscali | Registrazioni fiscali correnti, aliquote, esenzioni e impostazioni di calcolo |
| Relazioni Product e gruppi Customer | Configurazione attiva di prezzi, accessi e promozioni |
| Cronologia degli abbonamenti e riferimenti di fatturazione | Supporto corrente ai token del gateway, processi di rinnovo, email e automazione degli accessi |
| URL e metadati esistenti | Menu di destinazione, output dei template, ricerca e implementazione dei redirect |
La preparazione è pronta quando i riscontri dell’origine spiegano il significato storico e il responsabile dell’implementazione sulla destinazione accetta la responsabilità della configurazione attiva. Non usare un’esportazione riuscita dall’origine come prova che il processo di acquisto o la fatturazione ricorrente siano configurati.
Selezionare campioni rappresentativi per il test di migrazione
Scegliere esempi che mettano alla prova le relazioni più complesse di J2Commerce. Includere:
- un Product semplice collegato a un articolo Joomla e a una Category;
- un Product con più opzioni, varianti generate e SKU o stock specifici per variante;
- un Product scaricabile con dati che dimostrino l’accesso al file;
- un abbonamento, una prenotazione, un bundle o altro Product specializzato quando utilizzato;
- un Customer con più indirizzi o gruppi;
- un Order ospite e un Order di Customer registrato;
- un Order con riferimenti a sconti, imposte, spedizione e pagamento;
- un Product con campi personalizzati, input Customer o dati gestiti da un’applicazione;
- un percorso Product multilingue o con accesso limitato;
- un Product o Order collegato a un identificatore esterno.
Per ogni campione, registrare ID di origine, motivo della selezione, relazioni che mette alla prova, riscontri necessari per interpretarlo ed eventuale configurazione della destinazione intenzionalmente esclusa dal perimetro di migrazione.
Stabilire il controllo finale di prontezza
| Domanda di prontezza | Condizione di prontezza |
|---|---|
| Il sistema di origine è recuperabile? | Database, filesystem, media e riscontri sulle estensioni sono sottoposti a backup con un responsabile del ripristino. |
| I tipi di Product sono classificati? | Ogni famiglia Product nel perimetro ha un tipo, un funzionamento di vendita, un responsabile e un campione rappresentativo. |
| Le relazioni Joomla sono visibili? | Articoli, Categories, menu, moduli, lingue, livelli di accesso e URL sono mappati per i Products prioritari. |
| Customers e Orders sono interpretabili? | Collegamenti utenti, gruppi, indirizzi, stati, totali e record post-vendita sono documentati. |
| Applicazioni e dati personalizzati hanno un responsabile? | Ogni insieme di dati di estensione attivo ha schema, responsabile, chiave di origine e decisione sulla destinazione. |
| La configurazione è separata? | Le responsabilità per processo di acquisto attivo, imposte, pagamenti, spedizioni, cron e template hanno responsabili sulla destinazione. |
| I campioni sono adeguati? | I campioni di migrazione rappresentativi coprono varianti, Products specializzati, stati Customer/Order, URL e dati delle estensioni. |
Backup non verificati, tipi di Product non classificati, identità delle varianti mancante, dati di abbonamento o prenotazione non documentati o tabelle di estensioni senza responsabile dovrebbero bloccare la parte di perimetro interessata finché i riscontri non sono completi.
Conclusione
Preparare una migrazione verso J2Commerce richiede più di un’esportazione di Products e Orders. Occorre conservare le relazioni tra articoli Joomla, Categories, menu, utenti, Products J2Commerce, opzioni, varianti, Customers, Orders, applicazioni per Products specializzati, file, URL e sistemi esterni.
Un pacchetto di preparazione solido assegna ogni azione a un responsabile, registra i riscontri necessari per comprendere ogni relazione, separa la configurazione attiva della destinazione dai record storici e seleziona campioni rappresentativi che espongono la reale complessità del negozio prima dell’inizio della migrazione.
Domande frequenti
Che cosa deve essere preparato per prima cosa per una migrazione verso J2Commerce?
Mettere in sicurezza l’accesso a Joomla, J2Commerce, hosting, database, filesystem, attività pianificate e sistemi esterni. Poi creare backup immutabili e un inventario datato dell’ambiente e delle estensioni prima di pulire o ristrutturare i record.
Perché gli articoli Joomla sono importanti nella preparazione di J2Commerce?
I Products J2Commerce possono dipendere da contenuti degli articoli Joomla, Categories, menu, lingua, livelli di accesso, moduli e URL. Il solo record Product può non contenere l’intera identità pubblica nella vetrina online né il percorso attraverso cui viene scoperto.
Come devono essere preparate le varianti J2Commerce?
Registrare Product padre, definizioni delle opzioni, valori selezionati, SKU della variante, stock, prezzo, immagini, stato e identificatori esterni. Usare varianti rappresentative che mettano in evidenza le combinazioni con maggior rischio di perdere identità durante la migrazione.
Quali riscontri servono per abbonamenti o prenotazioni J2Commerce?
Preparare tipo di Product, piano o risorsa, pianificazioni, stati, collegamenti Customer e Order, riferimenti di pagamento, regole di accesso, dipendenze dalle attività pianificate e record storici rappresentativi. Trattare la configurazione attiva di rinnovi o disponibilità come responsabilità separata della destinazione.
Le impostazioni di pagamento, spedizione e imposte devono essere incluse come record migrati?
Gli Orders storici dovrebbero conservare etichette dei metodi, importi e riferimenti di transazione o tracking. Gateway attivi, tariffe dei corrieri, zone, credenziali e calcolo delle imposte appartengono alla configurazione della destinazione e devono avere responsabili separati.
Quali record scegliere per un test di migrazione rappresentativo verso J2Commerce?
Scegliere Products semplici e con varianti, tipi di Product specializzati, file scaricabili, Customers complessi, Orders di ospiti e registrati, sconti e imposte, URL multilingue o riservati, campi personalizzati, dati gestiti da applicazioni e identificatori esterni.