Se osCMax viene selezionato come piattaforma di destinazione, la preparazione deve trattare il negozio come un’installazione legacy composta da più livelli, non come uno schema di prodotto fisso. Il database può contenere un core derivato da osCommerce, aggiunte del pacchetto osCMax, tabelle e colonne gestite dai contribution, modifiche specifiche dell’azienda, risorse di template, file di lingua e identificatori di sistemi esterni. Due negozi con una vetrina simile possono quindi richiedere evidenze di sorgente diverse.
L’obiettivo della preparazione è identificare quale livello possieda ogni record importante relativo a Products, Customers, Orders, contenuti e operatività. Ogni area deve definire un’azione, un responsabile, un’evidenza e una condizione di prontezza. Quando non è disponibile documentazione autorevole corrente, non bisogna assumere lifecycle, compatibilità o insieme esatto delle funzioni incluse: l’installazione reale costituisce l’evidenza.
Definire storia delle versioni, evoluzione del negozio e accesso alla sorgente
Registrare ogni indicazione disponibile sulla provenienza dell’installazione osCMax: versione visualizzata, pacchetto di release o storia del repository, note di aggiornamento, modifiche allo schema del database, file modificati, contribution installate, pacchetto del template, ambiente di hosting e integrazioni esterne. Quando le informazioni sono in conflitto, documentare l’incertezza invece di scegliere semplicemente l’etichetta apparentemente più recente.
| Azione | Responsabile | Evidenza | Condizione di prontezza |
|---|---|---|---|
| Registrare versione e pacchetto | Responsabile tecnico | Piè di pagina dell’area amministrativa, file del pacchetto, registro delle modifiche, valori versione nel database | Gli indicatori noti e quelli in conflitto sono documentati. |
| Ricostruire aggiornamenti e manutenzione | Sviluppatore, agenzia o azienda | Note di deploy, date dei backup, cronologia patch | Le principali transizioni di schema o codice sono identificabili. |
| Confermare accesso a database e file | Responsabile hosting | Stato degli accessi, nome database, document root, disponibilità degli archivi | L’installazione live prevista può essere esaminata e sottoposta a backup. |
| Identificare template e livelli di lingua | Responsabile della vetrina | Nome del template, directory lingua, override, screenshot | Contenuto e file di presentazione possono essere separati dai record del database. |
| Identificare job pianificati e sistemi esterni | Responsabile integrazioni | Elenco cron, esportazione, import, riferimenti ERP/contabilità/spedizioni | Sono noti i dati che cambiano fuori dall’interfaccia amministrativa. |
Durante la raccolta delle evidenze, bloccare modifiche non documentate al codice e allo schema. Il negozio può continuare a vendere, ma import Product tardivi, nuove contribution, modifiche ai campi o sostituzioni del template devono entrare in un change log.
Separare i record e-commerce core dai dati di pacchetto e contribution
Partire dal core derivato da osCommerce: Products, descrizioni Product, Categories, produttori, attributi, Customers, rubriche indirizzi, Orders, righe Product negli Orders, totali Order, stati, recensioni, offerte speciali e altre relazioni standard presenti nell’installazione. Identificare poi campi e tabelle aggiunti dal pacchetto osCMax, dalle contribution o dallo sviluppo personalizzato.
Un nome di tabella familiare non dimostra che ogni colonna appartenga al core. Creare un inventario di schema e proprietà che registri tabella, campo o entità, relativo ID core, contribution o modifica che l’ha creato quando nota, finalità di business, uso corrente e decisione per la destinazione.
| Livello sorgente | Evidenza da preparare | Condizione di prontezza |
|---|---|---|
| Record core Product e Category | Estratti Product, Category, produttori, attributi, prezzi, stock e immagini | Le relazioni fondamentali del catalogo sono complete. |
| Campi aggiunti dal pacchetto | Diff dello schema, screenshot amministrativi, record rappresentativi | I valori del pacchetto sono distinti dai campi core. |
| Tabella di contribution | Definizione tabella, relazioni tra chiavi, nome modulo, ID campione | Entità di business e record padre sono noti. |
| Modifica diretta del core | Elenco file modificati e campi database coinvolti | Il significato di business è documentato indipendentemente dal vecchio codice. |
| Campo di sistema esterno | Mappa degli identificatori e responsabile del sistema | Le chiavi persistenti fra sistemi restano tracciabili. |
| Tabella o colonna obsoleta | Evidenza dell’ultimo utilizzo e decisione dell’azienda | Il residuo tecnico è marcato per archiviazione o esclusione. |
Non preparare la migrazione partendo soltanto da un elenco generico di tabelle osCommerce. Schema e codice live determinano il negozio reale.
Preparare Products, attributi, stock per combinazione, immagini e prezzi
Le opzioni e gli attributi Product legacy possono essere estesi da contribution che introducono stock per combinazione, SKU indipendenti, immagini aggiuntive, campi Product personalizzati, sconti quantità, prezzi per gruppi Customer, download, bundle o configuratori Product. Documentare il comportamento commerciale di ogni struttura invece di presumere che ogni opzione sia un semplice attributo Product.
| Schema sorgente | Azione | Evidenza | Condizione di prontezza |
|---|---|---|---|
| Attributo standard | Registrare opzione, valore, assegnazione al Product ed effetto su prezzo o peso | Export attributi e ID Product rappresentativi | Il significato della scelta di acquisto è esplicito. |
| SKU o stock a livello di combinazione | Identificare tabella della contribution e chiave della combinazione | Matrice combinazioni con quantità e SKU | Le combinazioni vendibili sono distinguibili dal Product padre. |
| Immagini multiple o specifiche di attributo | Registrare file, sequenza e relazione Product/opzione | Manifest dei media e percorsi file | Asset originali e significato dell’associazione sono disponibili. |
| Campo Product aggiuntivo | Registrare proprietario, tipo, uso nella vetrina e sistema esterno che lo consuma | Riga di schema e Products campione | Ogni valore attivo ha un proprietario nella destinazione. |
| Prezzo per quantità o Customer | Registrare Product, gruppo o soglia, valuta, date e importo | Inventario prezzi | Il prezzi condizionale non viene ridotto al prezzo base. |
| Product scaricabile | Registrare file, relazione di accesso, scadenza o limite se usati | Campioni Product e Orders storici | Le evidenze di consegna digitale sono complete. |
Il responsabile del catalogo deve approvare eventuali pulizie di attributi duplicati, nomi immagini, SKU o prezzi. Ciò che sembra duplicato può riflettere il comportamento di una contribution o una chiave usata da un sistema esterno.
Preparare Customers, rubriche indirizzi, gruppi ed estensioni account
La preparazione dei Customers deve includere identità account, voci della rubrica indirizzi, relazioni con l’indirizzo predefinito, gruppi o classificazioni wholesale, identificativi fiscali, stati di approvazione, record loyalty o credito, valori di referral, campi personalizzati e ID CRM o contabili esterni quando presenti.
Creare un registro delle estensioni Customer. Per ogni campo o tabella aggiunti, registrare la chiave Customer collegata, la finalità di business, se il valore sia corrente o storico, il responsabile privacy e se un altro sistema rimanga autorevole.
| Area Customer | Evidenza | Condizione di prontezza |
|---|---|---|
| Account Customer | Identità, stato, eccezioni email, date e ID esterni | Identità duplicate o in conflitto hanno una decisione definita. |
| Rubrica indirizzi | Righe indirizzo e collegamenti all’indirizzo predefinito | Gli indirizzi riutilizzabili restano separati dagli snapshot Order. |
| Gruppo wholesale o dealer | Assegnazione al gruppo più effetti su prezzo, imposte, accesso o pagamento | Il significato commerciale è documentato oltre la sola etichetta. |
| Contribution loyalty, credito o reward | Saldo, storico transazioni e ID Customer padre | Saldo corrente ed evidenze storiche possono essere separati. |
| Campi profilo personalizzati | Schema, tipo campo, finalità privacy, valori campione | Ogni campo attivo ha un proprietario. |
Preparare Orders, totali Order, storico degli stati e record delle estensioni
Gli Orders contengono spesso le evidenze storiche più importanti di un negozio osCMax. Preparare intestazioni Order, dettagli Customer o guest, snapshot di fatturazione e spedizione, righe Product, valori modello o SKU, attributi selezionati, quantità, prezzi, imposte, sconti, spedizione, etichette di pagamento, stati, commenti e riferimenti esterni.
I moduli dei totali Order richiedono particolare attenzione. Separare subtotale, imposte, spedizione, coupon, gift voucher, supplementi, commissioni per ordini minimi, crediti, sconti e altre righe create da contribution. Conservare etichetta, importo, ordine di visualizzazione e relazione con il totale finale.
| Evidenza Order | Responsabile | Condizione di prontezza |
|---|---|---|
| Righe Product e attributi | Responsabile e-commerce | L’articolo acquistato e i valori selezionati sono comprensibili senza il catalogo live. |
| Snapshot indirizzi | assistenza clienti | Gli indirizzi storici non vengono sovrascritti dai dati Customer correnti. |
| Totali Order | Finanza o e-commerce | Ogni importo rilevante ha un modulo o significato di business noto. |
| Stati e commenti | Team operativo | Sequenza storica degli stati e note sono interpretabili. |
| Riferimenti pagamento e spedizione | Finanza o evasione | Transazione, carrier, tracking ed etichette del metodo sono registrati. |
| Resi, voucher, crediti o estensioni post-vendita | assistenza clienti | Record collegati e saldi residui sono associati all’Order. |
| ID esportazione o riconciliazione | Responsabile integrazioni | Contabilità, ERP, marketplace o magazzino possono individuare la transazione. |
Non usare la configurazione corrente di pagamento o spedizione come sostituto delle etichette e dei riferimenti storici.
Costruire l’inventario di contribution e personalizzazioni
Il registro delle contribution è l’artefatto centrale della preparazione osCMax. Raggruppare le contribution per effetto sul business, non soltanto per nome di installazione.
| Area contribution | Evidenza da preparare | Condizione di prontezza |
|---|---|---|
| Catalogo e prezzi | Tabelle/campi aggiunti, Products rappresentativi, schermate amministrative | I record Product e prezzi attivi hanno proprietari. |
| Customer e accesso | Gruppi, approvazioni, campi fiscali, loyalty, credito, contenuti riservati | Il comportamento dell’account può essere separato in relazioni distinte. |
| Checkout e totali Order | Riepilogo configurazione e Orders rappresentativi | Gli importi storici sono distinguibili dal comportamento futuro. |
| Pagamenti e spedizioni | Riferimenti di transazione o spedizione, campi stato | Le evidenze storiche vengono mantenute senza vecchie credenziali o codice. |
| Reportistica ed esportazioni | Flag esportazione, ID batch, chiavi dei sistemi esterni | I riferimenti operativi ancora necessari sono noti. |
| SEO e contenuti | Tabelle route, metadati, pagine, redirect | Percorsi pubblici e proprietari dei contenuti sono espliciti. |
| Template e interfaccia | File template, box, voci di lingua, screenshot | Il contenuto di business è separato dalla presentazione. |
| Codice personalizzato | Elenco file modificati, variazioni schema, responsabile del flusso | La regola di business è documentata indipendentemente dall’implementazione. |
Classificare ogni elemento come attivo e necessario, attivo ma sostituibile, solo storico, inattivo con dati da conservare, obsoleto oppure sconosciuto. Gli elementi sconosciuti ma critici per il business rimangono bloccanti per la prontezza.
Preparare contenuti, template, file di lingua, media e URL
I contenuti della vetrina osCMax possono risiedere nelle descrizioni Product o Category, in contribution per pagine informative, file statici, box del template, file di lingua, banner, pulsanti, immagini o moduli personalizzati. Inventariare i contenuti in base a proprietario e route.
Preparare:
- pagine attive di policy, informazioni, contatto e servizi;
- descrizioni e immagini di Products e Categories;
- box del template che contengono informazioni di business;
- testo dei file di lingua che deve restare visibile ai clienti;
- menu e destinazioni di navigazione;
- URL importanti di Products, Categories, produttori e contenuti;
- redirect o rewrite rule creati da contribution o configurazione server;
- immagini originali, file scaricabili e media non generati.
Uno screenshot dimostra la presentazione, non il record sottostante. Quando possibile, abbinarlo a percorsi file, chiavi del database o sorgenti di contenuto.
Preparare evidenze su hosting, runtime, sicurezza e backup
Le condizioni dell’hosting legacy possono determinare se dati e file della sorgente siano accessibili. Registrare versioni PHP e database, charset o collation, configurazione del web server, job pianificati, percorsi di storage, permessi e vincoli noti di sicurezza o manutenzione. Questi dettagli servono a interpretare la sorgente, non rappresentano un requisito per riprodurre il vecchio ambiente nella piattaforma di destinazione.
Creare un set di backup ripristinabile che includa database e file rilevanti dello stesso stato del negozio. Includere template, file di lingua, immagini, download, codice delle contribution, riferimenti di configurazione e script personalizzati. Registrare cifratura, compressione, dimensione, timestamp e responsabile dell’accesso.
| Area di backup | Evidenza | Condizione di prontezza |
|---|---|---|
| Database | Dump completo e nota sulla ripristinabilità | Sono presenti tabelle core e contribution. |
| File | Archivio della sorgente o file tree accessibile | Template, contribution, immagini, download e codice personalizzato sono disponibili. |
| Ambiente | Note runtime e server | I problemi di parsing dipendenti dalla versione possono essere previsti. |
| Sicurezza | Responsabile credenziali, limiti di accesso, gestione dati sensibili | L’accesso può essere fornito in sicurezza tramite il processo previsto. |
| Change log | Modifiche tardive successive al backup | Nuovi Orders o cambiamenti strutturali sono visibili. |
Selezionare campioni per il test di migrazione rappresentativo
Preparare un manifest dei campioni con ID sorgente, tabelle collegate, file, contribution proprietaria e significato atteso nella sorgente. Includere record ordinari e casi che più probabilmente espongono differenze di schema.
Includere:
- un Product semplice e uno con attributi standard;
- un Product con stock o SKU a livello di combinazione, quando utilizzati;
- un Product con più immagini o immagini gestite dai contribution, download, prezzi speciali o campi personalizzati;
- Customers con più indirizzi, classificazione wholesale/dealer, campi personalizzati, loyalty, credito o ID esterni;
- Orders guest e registrati con attributi, diverse righe di totale, stati insoliti, riferimenti di pagamento/spedizione, rimborsi, voucher o ID esportazione;
- esempi importanti di contenuti e route;
- un’entità attiva gestita dai contribution, un record di tabella personalizzata e una relazione con un sistema esterno;
- un record proposto per la dismissione, documentando perché non rientra nel perimetro attivo della destinazione.
Applicare il gate finale di prontezza osCMax
| Domanda di prontezza | Esito richiesto |
|---|---|
| La provenienza dell’installazione è documentata? | Indicatori di versione, storia, evidenze del pacchetto e conflitti sono registrati. |
| Schemi core ed estesi sono separati? | Tabelle core, aggiunte del pacchetto, contribution e campi personalizzati hanno proprietari. |
| La complessità del catalogo è rappresentata? | Attributi, stock per combinazione, immagini, prezzi, download e identificatori sono documentati. |
| Customers e Orders sono interpretabili? | Gruppi, indirizzi, totali, stati, record post-vendita e ID esterni sono completi. |
| Le contribution sono classificate? | Elementi attivi, storici, obsoleti e sconosciuti hanno una decisione esplicita. |
| Contenuti e risorse della vetrina sono inventariati? | Pagine, testo di lingua, template, media, URL e redirect sono tracciabili. |
| Il backup è ripristinabile? | Database, file e note sull’ambiente corrispondono allo stesso stato del negozio. |
| Il set di campioni è rappresentativo? | Sono inclusi casi core, contribution, tabelle personalizzate, storico e dismissione. |
La preparazione resta aperta quando una contribution critica per il business, una tabella personalizzata, una riga di totale Order o un identificatore esterno non ha un responsabile.
Conclusione
La preparazione verso osCMax dipende dalle evidenze dell’installazione reale. Record e-commerce core, aggiunte del pacchetto, contribution, tabelle personalizzate, template, file di lingua, totali Order e chiavi dei sistemi esterni devono essere separati prima che la configurazione della migrazione possa rappresentare correttamente il negozio.
Un pacchetto sorgente ripristinabile, un registro della proprietà delle contribution e un manifest di campioni rappresentativi forniscono una base controllata per configurare la migrazione.
Domande frequenti
Perché uno schema osCommerce generico non basta per preparare osCMax?
Le installazioni osCMax includono comunemente aggiunte del pacchetto, contribution, campi personalizzati, file core modificati e tabelle personalizzate. Sono lo schema e il codice live a determinare quali record esistono e quale significato abbiano.
Cosa va registrato per ogni contribution osCMax?
Finalità di business, stato, tipi di dati core coinvolti, tabelle o campi, ID sorgente rappresentativi, dipendenze esterne e classificazione dei record come attivi, storici, sostituibili, obsoleti o sconosciuti.
Perché i totali Order osCMax richiedono un inventario separato?
I moduli dei totali possono creare righe per spedizione, imposte, coupon, voucher, supplementi, sconti, commissioni, crediti e altri valori. Etichetta, importo, sequenza e modulo proprietario spiegano il totale storico.
Moduli e tabelle osCMax obsoleti devono essere inclusi?
Devono essere documentati e poi marcati per archiviazione o esclusione quando nessun flusso attivo o storico ne dipende. I residui tecnici obsoleti non devono essere forzati in campi generici della destinazione.
Cosa deve contenere il backup sorgente osCMax?
Database e file rilevanti dello stesso stato del negozio, inclusi template, contribution, file di lingua, immagini, download, riferimenti di configurazione e script personalizzati, insieme alle note sull’ambiente.
Come scegliere i campioni rappresentativi per osCMax?
Usare Products core e influenzati da contribution, Customers con estensioni account, Orders con più righe di totale, esempi di contenuti e route, record di tabelle personalizzate, identificatori esterni e almeno un caso deliberato di dismissione.