Se OpenCart viene scelto come piattaforma di destinazione, la preparazione deve rendere comprensibile lo Store di origine prima che venga finalizzata qualsiasi configurazione della migrazione. Il sito pubblico può apparire semplice mentre relazioni importanti tra record sono distribuite tra Products, opzioni riutilizzabili, attributi, filtri, Categories, Manufacturers, Customer Groups, Discounts, Specials, più Stores, keyword SEO, estensioni, temi e campi database personalizzati.
L’obiettivo della preparazione è trasformare questa struttura distribuita in evidenze controllate della piattaforma di origine. Ogni area principale deve identificare l’azione da completare, il responsabile in grado di confermarne il significato aziendale, l’evidenza da fornire e la condizione che rende l’area pronta. In questo modo un export Product non viene trattato come descrizione completa dello Store quando scelte d’acquisto, regole di scoperta, contesto storico degli Orders o valori gestiti da estensioni risiedono altrove.
Definire l’accesso alla piattaforma di origine e registrare l’ambiente OpenCart
Inizia dalle evidenze che identificano l’installazione OpenCart effettiva. Registra versione OpenCart, Store attivo o struttura multi-store, posizione del database, document root, percorso Admin, lingue e valute attive, tema corrente e sistema di estensioni o modifiche utilizzato. Stores attivi da molto tempo possono contenere estensioni OpenCart Marketplace, modifiche OCMOD o VQMod, file del tema modificati, tabelle personalizzate o modifiche dirette al core.
La preparazione dell’accesso deve essere sufficientemente specifica per il metodo di connessione previsto dal percorso di migrazione selezionato. Non bisogna presumere che accesso al database, credenziali Admin, accesso hosting, credenziali API o un pacchetto di file siano intercambiabili. Prepara invece l’accesso alla piattaforma di origine e le evidenze di supporto disponibili per lo Store reale, mantenendo disponibile il responsabile dell’accesso per risolvere restrizioni o permessi mancanti.
| Azione | Responsabile | Evidenza | Condizione di prontezza |
|---|---|---|---|
| Registrare la versione OpenCart esatta e gli ID degli Stores attivi | Amministratore dello Store | Screenshot della versione, elenco Stores, nota sull’ambiente | Ogni Store attivo e la versione di origine sono identificati. |
| Confermare l’accesso alla piattaforma di origine | Responsabile hosting o tecnico | Credenziali disponibili, dettagli allowlist, nota sul test di accesso | La connessione richiesta alla piattaforma di origine raggiunge l’installazione prevista. |
| Identificare tema e livelli di modifica | Sviluppatore o agenzia | Nome tema, elenchi OCMOD/VQMod, inventario dei file modificati | Record nativi e comportamento dipendente dal codice possono essere distinti. |
| Registrare lingue, valute, impostazioni fiscali e unità | Responsabile commerciale | Export impostazioni o screenshot | I valori a livello Store che influenzano significato di Product e Order sono documentati. |
| Identificare importazioni o sincronizzazioni pianificate | Responsabile integrazioni | Pianificazione dei feed, elenco sistemi esterni, evidenza dell’ultima esecuzione | Il team sa quali valori possono cambiare durante la preparazione. |
Definisci un punto di cut-off per modifiche strutturali non controllate. Le normali vendite possono continuare, ma nuove estensioni, modifiche allo schema, ristrutturazioni massive del catalogo o riscritture degli URL devono essere registrate dopo la raccolta delle evidenze di origine.
Preparare Products, opzioni, attributi e filtri come insiemi di evidenze separati
OpenCart distingue i record Product da opzioni, attributi e filtri. Le opzioni raccolgono valori selezionabili o inseriti dal cliente e possono influenzare prezzo, peso, reward points, quantità o stato obbligatorio. Gli attributi descrivono caratteristiche Product. I filtri supportano la scoperta tramite relazioni con Product e Category. Combinare queste strutture in un unico foglio può nascondere se un valore è una scelta d’acquisto, una specifica o un supporto alla navigazione.
Crea un inventario Product che includa model, SKU o altri identificatori, stato, quantità, stock status, prezzo, tax class, peso, dimensioni, Manufacturer, Categories, immagini, Downloads, Products correlati, Specials, Discounts, rewards, opzioni, attributi e filtri dove utilizzati. L’inventario non deve riprodurre ogni colonna del database, ma deve mostrare le relazioni che distinguono Products semplici e complessi.
| Modello nella piattaforma di origine | Azione di preparazione | Evidenza richiesta | Condizione di prontezza |
|---|---|---|---|
| Opzione obbligatoria o che modifica il prezzo | Registrare tipo di opzione, valori, stato obbligatorio e variazioni | ID Product e assegnazioni opzione rappresentative | L’effetto commerciale dell’opzione è esplicito. |
| Input text, textarea, file, date o time | Separare i valori inseriti dal cliente dai valori opzione riutilizzabili | Elenco Products e righe Order campione che usano l’input | L’input specifico dell’acquisto non viene confuso con una variante. |
| Specifica tecnica | Registrare attribute group, attributo, valore lingua e assegnazione Product | Export attributi o campione strutturato | I dati descrittivi sono separati dalle scelte selezionabili. |
| Filtro del sito pubblico | Registrare filter group, valore, assegnazione Product e assegnazione Category | Mappa dei filtri attivi | Vengono mantenuti soltanto i filtri usati dai percorsi di scoperta correnti. |
| Product con più immagini o Downloads | Registrare sequenza dei media e disponibilità dei file | Elenco media, percorsi e ID Product rappresentativi | File e relative relazioni Product sono disponibili. |
| Specials o Discounts per Customer Group | Registrare Product, Customer Group, importo o percentuale, soglia quantità e date | Inventario delle regole di prezzo | Le evidenze sui prezzi condizionati sono complete e non ridotte al prezzo base. |
Normalizza soltanto difetti chiari della piattaforma di origine. Etichette opzione duplicate, maiuscole/minuscole incoerenti, filtri inutilizzati o identificatori vuoti possono essere segnalati, ma non unire valori solo perché sembrano simili. Il responsabile commerciale deve approvare qualsiasi normalizzazione che modifica il significato visibile al cliente.
Documentare Categories, Manufacturers, Stores e relazioni di scoperta
Le Categories OpenCart possono formare gerarchie, contenere contenuti multilingua, collegarsi ai filtri ed essere assegnate a Stores specifici. I Products possono appartenere a più Categories e Stores. I Manufacturers possono essere semplici campi Product oppure pagine pubbliche del brand. Queste relazioni devono essere registrate separatamente dalla presentazione del menu.
Prepara l’albero Category attivo con ID parent, assegnazioni Store, stato, sort order, immagini, descrizioni, metadata, filtri e URL correnti. Contrassegna Categories obsolete, nascoste, duplicate per finalità di navigazione o conservate soltanto per link storici. Per i Manufacturers, registra quelli che hanno route pubbliche, descrizioni utili, immagini o valore per la ricerca.
Per installazioni multi-store, crea una matrice dello scope degli Stores. Un Product o una Category disponibile nello Store predefinito può non appartenere a ogni Store aggiuntivo. Anche lingue, temi, domini, pagine contenuto e impostazioni possono variare. L’evidenza finale deve mostrare se i record sono condivisi, duplicati o specifici per Store.
| Area di scoperta | Responsabile | Evidenza | Condizione di prontezza |
|---|---|---|---|
| Gerarchia Category | Responsabile catalogo | Export parent-child ed elenco Categories attive | Ogni Category mantenuta ha un parent noto e uno scopo aziendale. |
| Assegnazioni Product-to-Category | Responsabile merchandising | Products rappresentativi in più Categories ed export delle assegnazioni | La collocazione condivisa dei Products è visibile senza creare Products duplicati. |
| Pagine Manufacturer | Responsabile brand o SEO | Elenco Manufacturers, inventario route, note sulla visibilità | I brand pubblici sono distinti dai valori Manufacturer soltanto interni. |
| Assegnazioni Store | Responsabile multi-store | Matrice di scope per Products, Categories, pagine Information e domini | Ogni record ha uno scope Store previsto. |
| Filtri e navigazione | Responsabile merchandising | Mappa filter-to-Category e screenshot del menu | La classificazione del catalogo è separata dalla presentazione del menu. |
Preparare Customers, Customer group, indirizzi e storico Orders
La preparazione dei Customers deve distinguere identità account, record della rubrica indirizzi, appartenenza a Customer Group, stato di approvazione, preferenze marketing, reward points, campi personalizzati e identificatori esterni. Un Customer Group può controllare Discounts, prezzi Product, trattamento fiscale, accesso ai pagamenti o flussi di approvazione; il suo effetto aziendale deve quindi essere documentato, non soltanto il nome del gruppo.
La preparazione degli Orders deve preservare evidenze storiche. Crea un inventario degli stati e seleziona Orders che rappresentino checkout guest e registrato, diversi Customer Groups, selezioni di opzioni, Discounts, Coupons, reward points, imposte, spedizione, etichette di pagamento, rimborsi o resi dove registrati e totali generati da estensioni. Registra quali campi storici sono richiesti per ricerca da parte del personale, cronologia account Customer, riconciliazione contabile o integrazioni esterne.
| Area record | Azione di preparazione | Evidenza | Condizione di prontezza |
|---|---|---|---|
| Account Customer | Identificare email duplicate, stati di approvazione, campi personalizzati e chiavi esterne | Riepilogo Customers ed elenco eccezioni | Le eccezioni di identità hanno un responsabile e una decisione. |
| Customer Groups | Registrare ogni effetto commerciale o di accesso attivo | Matrice gruppo→regola | Il significato del gruppo è documentato oltre l’etichetta. |
| Indirizzi | Separare indirizzi riutilizzabili del Customer dagli snapshot al momento dell’Order | Campioni indirizzi Customer e Order | Dati account correnti ed evidenza storica non vengono confusi. |
| Stati Order | Mappare gli stati al loro significato operativo | Elenco stati con Orders di esempio | Gli stati storici sono interpretabili senza dipendere soltanto da colore o etichetta. |
| Totali Order | Inventariare subtotale, imposte, spedizione, coupon, reward, fee, credito e righe di estensioni | Totali di Orders rappresentativi | Ogni rettifica materiale ha un responsabile di origine noto. |
| Riferimenti esterni | Registrare ID ERP, marketplace, pagamento, spedizione o contabilità | Mappa identificatori | I sistemi continuativi possono trovare lo stesso Customer o Order. |
Non modificare Orders storici solo per renderli apparentemente coerenti. Un’etichetta o importo insolito può essere un’evidenza importante della transazione originale. Registra separatamente le anomalie note.
Inventariare estensioni, modifiche, temi e dati personalizzati
Le estensioni OpenCart possono aggiungere campi, tabelle, comportamento delle opzioni, totali Order, feed, inserzioni marketplace, passaggi checkout, record di pagamento, riferimenti di spedizione, report, logica SEO o flussi amministrativi. I temi possono inoltre leggere campi personalizzati o modificare la visualizzazione di opzioni, filtri e contenuti. Un elenco dei nomi delle estensioni non è sufficiente: la preparazione deve registrare i record aziendali di cui ogni estensione è responsabile.
Crea un registro delle estensioni con stato, vendor, versione, scopo, posizione dei dati dove nota, entità interessate, campi o tabelle personalizzate, dipendenze esterne e responsabile in grado di confermare se il comportamento è ancora necessario. Separa i dati aziendali attivi dalla configurazione e dai residui tecnici obsoleti.
| Effetto dell’estensione | Evidenza da preparare | Decisione di prontezza |
|---|---|---|
| Campi Product o opzione | Nomi campi, Products campione, posizione della tabella o dell’export | Ogni valore attivo ha un responsabile nella destinazione o un’esclusione deliberata. |
| Totali Order o logica checkout | Orders di esempio, etichette totali, riepilogo configurazione modulo | I valori storici sono separabili dalla futura configurazione checkout. |
| Integrazione marketplace o feed | ID dell’inserzione, Categories del canale, chiavi di sincronizzazione | Identità Product canonica e record del canale sono distinti. |
| Modifica SEO o URL | Esempi di route correnti, tabelle redirect, configurazione rewrite | I percorsi importanti della piattaforma di origine possono essere ricostruiti. |
| Contenuto dipendente dal tema | Screenshot, percorsi template, assegnazioni block o modulo | Il contenuto è separato dal codice di presentazione. |
| Estensione abbandonata | Evidenza dell’ultimo utilizzo e conferma del responsabile dati | I record obsoleti sono contrassegnati per archivio o esclusione. |
Preparare contenuti, keyword SEO, media ed evidenze delle route
OpenCart può assegnare keyword SEO a Products, Categories, Manufacturers e pagine Information. Prepara un inventario delle route che registri oggetto di origine, scope di Store e lingua, percorso corrente, keyword SEO, importanza per traffico o business e decisione prevista. Segnala keyword duplicate, keyword vuote su record importanti, route create da estensioni e percorsi dipendenti dalla configurazione di rewrite del server.
La preparazione dei contenuti deve includere pagine Information, descrizioni Product e Category, contenuti Manufacturer, banner, layout, moduli e file media ancora importanti. Registra se ogni elemento è un record contenuto migrabile, un’attività di configurazione del Target Store, una risorsa del tema, una risorsa esterna o materiale obsoleto.
Esegui un backup delle immagini originali e dei Downloads con i relativi percorsi. Un export del database può contenere nomi file senza includere i file stessi. Identifica file mancanti, URL esterni, differenze di maiuscole/minuscole nei percorsi e thumbnail generati che non devono diventare originali nella sorgente.
Costruire il pacchetto di backup e prontezza degli input
Crea un pacchetto di origine ripristinabile prima di pulizia strutturale o esecuzione della migrazione. Per uno Store OpenCart self-hosted, questo comprende normalmente backup del database, albero dei file pertinente, dettagli dell’ambiente, riferimenti alla configurazione ed evidenza che il backup corrisponde allo stesso stato dello Store.
| Componente del pacchetto | Responsabile | Evidenza | Condizione di prontezza |
|---|---|---|---|
| Backup database | Amministratore hosting o database | Dump con timestamp e nota sulla possibilità di ripristino | Il dump è completo e collegato al database corretto. |
| File e media | Responsabile hosting o tecnico | Archivio o albero file accessibile | Immagini originali, Downloads, estensioni e file tema sono disponibili. |
| Registro ambiente | Responsabile tecnico | Note su PHP, database, web server ed estensioni | Il comportamento dipendente dalla versione può essere interpretato. |
| Registro accessi | Responsabile progetto | Responsabile delle credenziali e stato dell’accesso | L’accesso richiesto è disponibile senza condividere credenziali nei documenti di pianificazione. |
| Change log | Amministratore dello Store | Modifiche successive al cut-off delle evidenze | Le modifiche strutturali tardive possono essere incorporate deliberatamente. |
Selezionare campioni rappresentativi per il test di migrazione
Il set di campioni deve esporre le relazioni che definiscono lo Store OpenCart. Prepara un manifest compatto con ID di origine, motivo aziendale, file collegati e struttura di origine prevista per ogni campione. Il manifest è pronto quando ogni record selezionato dispone di evidenze complete e di un revisore nominato.
Includi almeno:
- un Product semplice e un Product inattivo o archiviato;
- Products con opzioni obbligatorie, che modificano il prezzo, text, file, date o sensibili allo stock dove presenti;
- Products con attributi, filtri, più Categories, Manufacturers, più immagini, Downloads, Specials e Discounts per Customer Group;
- Customers appartenenti a Customer Groups significativi, un Order guest e un Order di Customer registrato;
- Orders con valori opzione, Coupons, rewards, imposte, spedizione, riferimenti di pagamento, totali insoliti e ID esterni;
- una route importante per ciascun tipo di oggetto pubblico;
- un record attivo gestito da un’estensione e un esempio di contenuto dipendente dal tema.
Applicare il gate finale di prontezza per OpenCart
OpenCart è pronto per il passaggio successivo della migrazione quando la piattaforma di origine può essere descritta senza dipendere da ipotesi non documentate.
| Domanda di prontezza | Risultato richiesto |
|---|---|
| L’installazione esatta e lo scope degli Stores sono noti? | Versione, Stores, lingue, valute, tema e livelli di modifica sono registrati. |
| Le relazioni Product sono complete? | Opzioni, attributi, filtri, Categories, media, regole di prezzo e identificatori sono rappresentati. |
| Customers e Orders sono interpretabili? | Logica dei gruppi, indirizzi, stati, totali e riferimenti esterni hanno responsabili. |
| Estensioni e dati personalizzati sono classificati? | Ogni dipendenza attiva ha uno scopo aziendale e una decisione per la destinazione. |
| Contenuti e URL sono inventariati? | Route importanti, pagine Information, media e dipendenze rewrite sono documentati. |
| Backup e accesso sono pronti? | Il pacchetto di origine è ripristinabile e la connessione richiesta è disponibile. |
| Il set campione è rappresentativo? | Record complessi e ordinari sono elencati con ID di origine e relazioni previste. |
Le questioni irrisolte devono entrare in un decision log con responsabile e data prevista. La preparazione non è completa quando un campo critico, una tabella di estensione, un’assegnazione Store o un identificatore esterno è ancora descritto soltanto come “unknown”.
Conclusione
La preparazione di OpenCart è più solida quando tratta lo Store come un insieme collegato di catalogo e record operativi invece che come un export Product piatto. Opzioni, attributi, filtri, Categories, Stores, Customer Groups, totali Order, estensioni, temi, media e keyword SEO richiedono ciascuno un responsabile chiaro e un insieme di evidenze.
Un pacchetto di origine controllato, un manifest di campioni rappresentativi e un gate di prontezza esplicito forniscono una base affidabile per configurare la migrazione.
Domande frequenti
Perché opzioni, attributi e filtri OpenCart devono essere preparati separatamente?
Svolgono funzioni diverse. Le opzioni raccolgono scelte d’acquisto o input del cliente, gli attributi descrivono Products e i filtri supportano la scoperta del catalogo. Combinarli può creare strutture di variante errate oppure eliminare specifiche e relazioni di navigazione utili.
Cosa deve essere registrato per un’installazione OpenCart multi-store?
Registra ogni ID Store, dominio, lingua, valuta, tema, impostazioni, assegnazioni Product e Category, pagine Information e URL importanti. I record condivisi e quelli specifici per Store devono essere distinguibili.
Un backup del database include immagini e Downloads di OpenCart?
No. Il database memorizza comunemente riferimenti ai file, mentre immagini originali, Downloads, risorse del tema e file delle estensioni restano nel file system. Prepara sia evidenze del database sia dei file.
Come devono essere preparati i dati OpenCart gestiti dalle estensioni?
Registra estensione, entità interessate, campi o tabelle personalizzate, record di origine rappresentativi, dipendenze esterne e scopo aziendale continuativo. I valori attivi richiedono un responsabile esplicito; i record obsoleti possono essere contrassegnati per archivio o esclusione.
Quali record OpenCart appartengono al set di campioni rappresentativi?
Usa Products ordinari e complessi, diversi tipi di opzione, attributi e filtri, relazioni con più Categories, Customer Groups, Orders significativi, route importanti e record attivi gestiti da estensioni. Il manifest deve includere ID di origine e relazioni previste.
Le keyword SEO duplicate devono essere cambiate durante la preparazione?
Segnalale prima e assegna un responsabile. Modificale soltanto attraverso una decisione URL approvata che registri destinazione prevista e relazione di redirect, perché una keyword apparentemente duplicata può comunque avere rilevanza per traffico o integrazioni.