Se osCommerce viene scelto come piattaforma di destinazione, la preparazione deve iniziare dalla generazione della piattaforma di origine, perché osCommerce v4 attuale e installazioni legacy di lunga durata possono usare strutture di catalogo, estensioni, contenuti e database profondamente differenti. Uno store descritto genericamente come osCommerce può essere v4 attuale, una release 2.x più vecchia, un fork oppure una codebase fortemente modificata con estensioni della community e cambiamenti diretti allo schema.
L’obiettivo della preparazione è identificare il modello reale dell’origine prima di decidere qualsiasi corrispondenza tra campi. Ogni area dovrebbe indicare azione, responsabile, evidenza e condizione di prontezza. Relazioni v4 attuali, come sales channel, gruppi Customer, attributi, proprietà e record CMS, non devono essere date per presenti nello stesso modo in un’origine legacy. Allo stesso tempo, una tabella di estensione legacy non deve essere trattata come dato nativo v4 solo perché una funzione moderna porta un nome simile.
Stabilire generazione dell’origine, accessi e responsabilità tecnica
Registrare nome della piattaforma di origine, versione, branch o fork, prefisso del database, ambiente hosting, front end o vetrine attive, lingue, valute, estensioni, file modificati, tabelle personalizzate e sincronizzazioni esterne. Quando uno store più vecchio è passato attraverso più aggiornamenti, conservare note degli sviluppatori o evidenze dello schema che spieghino quali tabelle continuano a governare il comportamento attuale.
Preparare gli accessi all’origine richiesti dal percorso di migrazione scelto. Il responsabile tecnico deve confermare che la connessione raggiunga il database e l’albero file corretti e che i backup disponibili appartengano allo stesso stato dello store.
| Azione | Responsabile | Evidenza | Condizione di prontezza |
|---|---|---|---|
| Identificare generazione e linea del codice dell’origine | Responsabile tecnico | Evidenza della versione, repository o nota del pacchetto, storia del fork | L’origine è classificata come v4 attuale, osCommerce legacy, fork o derivato personalizzato. |
| Confermare accesso a database e file | Responsabile hosting o database | Nome/prefisso database, stato della connessione, nota sulla document root | La connessione richiesta raggiunge l’installazione prevista. |
| Inventariare estensioni e modifiche al core | Sviluppatore o agenzia | Elenco estensioni, registro dei file modificati, elenco tabelle personalizzate | Record nativi, di proprietà delle estensioni e personalizzati possono essere separati. |
| Registrare front end, lingue, valute e contesto fiscale | Responsabile e-commerce | Evidenze delle impostazioni e matrice del perimetro | Il contesto generale dello store che modifica il significato di Product o Order è documentato. |
| Identificare sistemi esterni e importazioni | Responsabile integrazioni | Elenco ERP/PIM/WMS/CRM, pianificazione dei flussi dati, campi chiave | I valori mantenuti fuori da osCommerce hanno un sistema autorevole identificato. |
Una volta raccolto il set di evidenze, bloccare le modifiche strutturali non documentate. L’attività commerciale ordinaria può continuare, ma nuove estensioni, modifiche allo schema, cambiamenti del modello Product o riscritture delle route devono entrare nel registro delle modifiche del progetto.
Preparare Products, Categories, brand, fornitori e perimetro dei front end
osCommerce v4 attuale può associare Products a Categories, brand, fornitori, sales channel o front end, gruppi Customer, descrizioni multilingue, modalità di stock, immagini, identificatori, prezzi, campi SEO e relazioni di merchandising. Gli store legacy possono invece utilizzare tabelle core più semplici e demandare molte di queste funzioni alle estensioni.
Creare un inventario Product che registri ID Product nell’origine, SKU o model, altri identificatori, stato, prezzo base, classe fiscale, funzionamento dello stock, peso, stato virtuale/scaricabile, assegnazioni alle Categories, brand o produttore, fornitore, immagini, valori linguistici, perimetro dei sales channel, perimetro dei gruppi Customer e relazioni attive di promozione o prezzo quantità.
| Schema nell’origine | Azione di preparazione | Evidenza | Condizione di prontezza |
|---|---|---|---|
| Product assegnato a più Categories | Registrare tutte le relazioni con le Categories e il contesto di merchandising principale | Esportazione delle relazioni Product-Category | La collocazione condivisa è visibile senza duplicare Products. |
| Product disponibile soltanto in alcuni front end | Registrare assegnazioni e restrizioni per canale/front end | Matrice del perimetro per Product e Category | La disponibilità per canale è esplicita. |
| Relazione con brand o fornitore | Separare identità pubblica del brand da responsabilità di approvvigionamento | Collegamenti tra brand, fornitore e Product | Etichette simili non vengono fuse in un unico campo non correlato. |
| Stato stock reale, illimitato, nascosto o preorder | Registrare quantità, modalità di stock e comportamento out-of-stock | Impostazioni Product rappresentative | Il significato della disponibilità non viene ridotto a una quantità numerica. |
| Product virtuale o scaricabile | Registrare file, scadenza, limiti di download, significato della spedizione e percorso nell’origine | Manifest Product/file | Relazioni di consegna digitale e file originali sono disponibili. |
| Prezzo per gruppo o quantità | Registrare Product, gruppo Customer, soglia, valuta e importo | Inventario delle relazioni di prezzo | I prezzi condizionali non vengono sostituiti dal prezzo base. |
Per gli store legacy, indicare quali valori provengono dalle tabelle Product core e quali da colonne di estensione o tabelle separate. Il responsabile aziendale deve approvare qualsiasi pulizia che modifichi identità Product o perimetro dei canali.
Separare attributi, proprietà e relazioni dei Products configurabili
v4 attuale distingue gli attributi dalle proprietà. Gli attributi possono rappresentare valori selezionabili, template riutilizzabili, effetti su prezzo o peso, file virtuali e relazioni di inventario. Le proprietà descrivono caratteristiche strutturate utilizzate per visualizzazione, filtri, ricerca, confronto, intervalli, icone o gruppi Product. Gli attributi di osCommerce legacy possono unire diversi di questi significati.
Preparare evidenze che classifichino ogni valore dell’origine per funzione, non per nome.
| Significato commerciale | Azione di preparazione | Evidenza | Condizione di prontezza |
|---|---|---|---|
| Scelta selezionabile dell’acquirente | Registrare attributo, valori, template, assegnazione al Product ed effetti su prezzo/peso | Esportazione di attributi e assegnazioni | La scelta d’acquisto e il suo effetto commerciale sono espliciti. |
| Combinazione con SKU o stock indipendente | Identificare record di combinazione configurabile o di proprietà dell’estensione | Tabella delle combinazioni e chiavi Product | L’identità vendibile indipendente resta conservata nel modello di origine. |
| Specifica tecnica | Registrare categoria di proprietà, proprietà, tipo, unità, valori e collegamenti Product | Inventario delle proprietà | I dati descrittivi restano separati dalle scelte dell’acquirente. |
| Valore di filtro o confronto | Registrare comportamento di visualizzazione/filtro/ricerca e tassonomia | Mappa dei campi usati per ricerca e reperibilità | I valori necessari per trovare i Products sono identificati. |
| Input di testo o personalizzazione | Identificare il proprietario del campo e righe Order rappresentative | Esempi di Product e Order | L’input specifico dell’acquisto non viene trattato come metadato riutilizzabile. |
| Attributo scaricabile | Registrare file, limiti, Product e relazione con l’attributo | Manifest di file e attributi | File ed evidenza del diritto di download sono completi. |
Non trasferire automaticamente ogni attributo legacy in un attributo v4 attuale. Alcuni appartengono a proprietà, relazioni di Product configurabile, campi personalizzati o strutture di proprietà delle estensioni.
Documentare gruppi Customer, account, indirizzi e contesto commerciale
I gruppi Customer dell’attuale v4 possono controllare visibilità di Product e Category, applicabilità delle imposte, sconti cumulativi e valori predefiniti per ospiti o utenti appena registrati. Le estensioni possono aggiungere record per vendita all’ingrosso, B2B, credito, fidelizzazione o approvazione. Gli store legacy possono rappresentare queste relazioni in modo differente.
Preparare evidenze Customer che separino identità, record della rubrica indirizzi, stato di ospite, appartenenza ai gruppi Customer, stato fiscale o commerciale, Reviews, identificatori esterni e saldi o permessi di proprietà delle estensioni.
| Area del record | Responsabile | Evidenza | Condizione di prontezza |
|---|---|---|---|
| Identità Customer | Responsabile assistenza Customer o CRM | Elenco duplicati ed eccezioni | Ogni account mantenuto ha una decisione chiara sull’identità. |
| Gruppi Customer | Responsabile e-commerce | Matrice tra gruppo Customer, visibilità, imposte e sconti | Il significato del gruppo è documentato oltre la sola etichetta. |
| Indirizzi | Responsabile dati Customer | Indirizzi riutilizzabili ed esempi al momento dell’Order | Record dell’account e snapshot storici sono distinti. |
| Estensioni per vendita all’ingrosso o B2B | Responsabile aziendale e sviluppatore | Record di azienda, ruolo, approvazione, prezzo o credito | Le relazioni commerciali di proprietà delle estensioni hanno una decisione nella destinazione. |
| Reviews e attività | Responsabile dei contenuti o dell’e-commerce | Relazioni rappresentative tra Customer e Product | I record generati dai Customers mantengono il proprietario corretto. |
| Chiavi Customer esterne | Responsabile integrazioni | Mappa identificatori CRM/ERP | I sistemi che continueranno a operare possono ritrovare lo stesso account. |
La portabilità delle password va documentata come caratteristica dell’origine, non presunta dalla sola presenza di un indirizzo email. Registrare lo schema di autenticazione dell’origine e la dipendenza per l’accesso agli account senza trasformare la checklist in un piano di comunicazione ai Customers.
Preparare Orders ed evidenze commerciali storiche
La preparazione degli Orders deve rendere interpretabili le transazioni storiche. Gli Orders v4 attuali possono includere contesto del sales channel, snapshot di Products e attributi, indirizzi, totali, stati, commenti, etichette di pagamento e spedizione, tracking, rimborsi, resi, fatture e riferimenti esterni. I moduli legacy possono aggiungere righe di totale Order separate o tabelle di transazioni.
Selezionare Orders che rappresentino la reale complessità dello store e identificare quali record o estensioni possiedono ciascun valore storico.
| Evidenza Order | Azione di preparazione | Condizione di prontezza |
|---|---|---|
| Righe Product e attributi | Registrare nomi snapshot, SKU, valori selezionati, quantità e prezzi | L’articolo acquistato resta comprensibile indipendentemente dal catalogo attuale. |
| Indirizzi di fatturazione e consegna | Conservare gli snapshot al momento dell’Order separati dagli indirizzi Customer | Gli indirizzi storici della transazione sono completi. |
| Imposte, spedizione, sconti, commissioni e crediti | Inventariare ogni riga materiale del totale Order e il modulo che la possiede | I totali finali possono essere spiegati senza ricostruire codice ritirato. |
| Riferimenti di pagamento e spedizione | Registrare etichette, ID transazione, tracking e proprietà dei moduli | I riferimenti storici sono disponibili senza trattarli come configurazione attuale. |
| Stati e commenti | Registrare significato, sequenza, date e visibilità degli stati | Lo staff può interpretare il processo storico. |
| Rimborsi, resi e ID esterni | Registrare entità correlate e chiavi di riconciliazione | Le relazioni post-vendita e con sistemi esterni restano tracciabili. |
Non ricalcolare i vecchi Orders utilizzando impostazioni Product, gruppo Customer, imposte o spedizione attuali. Il pacchetto di evidenze deve conservare la transazione originale così come registrata.
Inventariare Apps, estensioni legacy, tabelle personalizzate e integrazioni
Apps v4 attuali ed estensioni legacy possono possedere campi catalogo, gruppi Customer, totali Order, dati SEO, riferimenti di pagamento, offerte marketplace, report o corrispondenze con sistemi esterni. Un semplice elenco di estensioni non basta: la preparazione deve identificare quali record crea o modifica ogni componente.
| Schema di dipendenza | Evidenza da preparare | Condizione di prontezza |
|---|---|---|
| App v4 attuale | Nome App, versione, entità interessate, campi/tabelle, ID rappresentativi | I dati dell’App attiva hanno un proprietario esplicito. |
| Estensione legacy | Nome pacchetto, file core modificati, cambiamenti SQL e record correlati | I dati dell’estensione possono essere separati dai record core osCommerce. |
| Tabella o campo personalizzato | Schema, significato commerciale, chiavi del record principale e sistema utilizzatore | Ogni valore personalizzato attivo ha una destinazione definita. |
| Connettore marketplace o sales channel | Scheda, offerta, canale e ID esterni | L’identità Product canonica resta distinta dalla sua rappresentazione nel canale. |
| Integrazione ERP/PIM/WMS/CRM | Sistema autorevole, direzione della sincronizzazione e chiavi stabili | I sistemi che continueranno a operare possono riconnettersi alle entità della destinazione. |
| Componente abbandonato | Evidenza dell’ultimo utilizzo e conferma del responsabile | I residui tecnici obsoleti sono marcati per archivio o esclusione. |
Preparare contenuti CMS, media, SEO ed evidenze delle route
v4 attuale può gestire contenuti CMS, temi, front end, descrizioni Product e Category, media e impostazioni SEO. Gli store legacy possono utilizzare estensioni per pagine informative, file statici, box di template, file lingua o moduli SEO. Preparare i contenuti in base al loro proprietario invece di trattare ogni pagina visibile come un’unica entità CMS.
Costruire un inventario delle route per Products, Categories, brand, CMS Pages, pagine informative, contenuti specifici per front end ed endpoint di estensioni ad alta priorità. Registrare percorso nell’origine, oggetto proprietario, lingua, front end, metadati, eventuale impostazione canonical, importanza commerciale e destinazione prevista.
Eseguire il backup di immagini originali, download, documenti, asset dei temi e file di contenuto. Registrare relazioni di allegato e URL esterni. Un dump del database può conservare i nomi dei file senza contenere i file originali.
Creare il pacchetto di backup e preparazione degli input
Creare un pacchetto ripristinabile legato a un unico stato dell’origine.
| Componente del pacchetto | Responsabile | Evidenza | Condizione di prontezza |
|---|---|---|---|
| Backup database | Amministratore database | Dump con timestamp, prefisso e nota sulla generazione dell’origine | Lo schema completo previsto è incluso. |
| File e media | Responsabile hosting o tecnico | Archivio dei file o albero sorgente accessibile | Media originali, download, estensioni e codice personalizzato sono disponibili. |
| Registro della generazione | Responsabile tecnico | Storia di versione/fork e note sugli aggiornamenti | Strutture legacy e attuali possono essere interpretate correttamente. |
| Registro accessi | Responsabile progetto | Responsabile dell’accesso e stato della connessione | Gli accessi necessari sono disponibili senza pubblicare credenziali. |
| Registro modifiche | Amministratore dello store | Cambiamenti strutturali dopo il cut-off delle evidenze | Le modifiche tardive possono essere incorporate deliberatamente. |
Selezionare campioni rappresentativi per il test di migrazione
Preparare un manifest dei campioni con ID dell’origine, responsabile, motivo commerciale, file correlati e relazioni attese nell’origine. Il set dovrebbe esporre sia strutture v4 attuali sia strutture specifiche legacy dove esistono. Il manifest dei campioni osCommerce è pronto quando ogni aspettativa sull’origine, dipendenza dalla generazione, file collegato e identificatore è completo e assegnato a un revisore.
Includere almeno:
- un Product semplice e un Product con più assegnazioni a Category o front end;
- Products con attributi, proprietà, combinazioni configurabili, download, fornitori e prezzi per gruppo;
- Customers appartenenti a gruppi significativi, transazioni di ospiti e account per vendita all’ingrosso o di proprietà di estensioni;
- Orders con attributi, più componenti del totale, rimborsi, tracking, commenti e riferimenti esterni;
- route prioritarie di CMS, Product, Category, brand e contenuti di proprietà delle estensioni;
- un record di un’App attuale o un’estensione legacy che contenga dati commerciali;
- un record il cui significato differisce tra la generazione dell’origine e l’attuale v4.
Applicare il controllo finale di preparazione per osCommerce
| Domanda di preparazione | Risultato richiesto |
|---|---|
| La generazione dell’origine è confermata? | Versione, branch o fork, database, front end, estensioni e personalizzazioni sono registrati. |
| Il perimetro del catalogo è completo? | Products, Categories, brand, fornitori, canali, stock, prezzi e media hanno proprietari. |
| Attributi e proprietà sono classificati? | Relazioni selezionabili, descrittive, configurabili e personalizzate sono separate. |
| Customers e Orders sono interpretabili? | Gruppi, indirizzi, totali, stati e riferimenti esterni sono documentati. |
| Apps e dati personalizzati sono classificati? | I record attivi di proprietà delle estensioni hanno decisioni esplicite nella destinazione. |
| Contenuti e route sono inventariati? | CMS, contenuti legacy, media e URL importanti sono collegati agli oggetti proprietari. |
| Backup, accessi e campioni sono pronti? | Il pacchetto dell’origine è ripristinabile e gli ID rappresentativi sono elencati. |
La preparazione rimane aperta quando una tabella legacy critica, un’assegnazione di canale, una regola di gruppo Customer, un modulo di totale Order o un identificatore esterno non dispone ancora di un proprietario e di una destinazione definiti.
Conclusione
Preparare una migrazione verso osCommerce significa ricostruire la linea evolutiva della piattaforma tanto quanto inventariare i dati. Products, front end, gruppi Customer, attributi, proprietà, contenuti CMS e Apps dell’attuale v4 devono essere distinti da tabelle legacy, estensioni della community e codice modificato.
Un pacchetto di origine controllato rende espliciti questi confini e fornisce record rappresentativi per configurare e verificare la migrazione.
Domande frequenti
Perché versione o fork dell’origine osCommerce devono essere confermati per primi?
osCommerce v4 attuale e installazioni legacy possono archiviare e interpretare in modo diverso dati di catalogo, Customer, Order, contenuti ed estensioni. La generazione della piattaforma determina quali relazioni e tabelle possiedono davvero i record dell’origine.
Qual è la differenza di preparazione tra attributi e proprietà?
Gli attributi rappresentano normalmente valori Product selezionabili o configurabili e possono influire su prezzo, peso, inventario o download. Le proprietà descrivono caratteristiche strutturate utilizzate per visualizzazione, filtri, ricerca o confronto.
Come vanno documentate le assegnazioni a sales channel o front end?
Registrare quali Products, Categories, contenuti, lingue e URL appartengono a ciascun front end. Record condivisi e record specifici del canale devono essere visibili in una matrice del perimetro.
Le tabelle delle estensioni legacy devono essere copiate nei campi di osCommerce v4 attuale?
Non automaticamente. Occorre prima identificare estensione, significato commerciale, record principale e sistema che continuerà a utilizzare il dato. Una funzione moderna con un’etichetta simile potrebbe non usare lo stesso schema o funzionamento.
Quali Orders devono entrare nel set di campioni osCommerce?
Includere Orders di ospiti e registrati, più stati, selezioni di attributi, sconti, imposte, spedizione, riferimenti di pagamento, rimborsi, commenti, tracking e totali creati da estensioni o ID esterni.
Il backup del database contiene immagini, download e file delle estensioni di osCommerce?
No. È necessario preparare l’albero file pertinente insieme al database, in modo che media, file scaricabili, temi, Apps, estensioni legacy e codice personalizzato restino disponibili.