Se il progetto sceglie WooCommerce come piattaforma di destinazione, la preparazione deve trattare lo store come un’applicazione e-commerce integrata in WordPress. Products e variazioni condividono l’infrastruttura WordPress con i contenuti, ma il loro significato commerciale dipende da WooCommerce e dalle relative estensioni. Gli Orders possono usare High-Performance Order Storage oppure l’archiviazione legacy basata sui post WordPress. I Customers possono essere utenti WordPress registrati oppure identità transazionali di clienti non registrati. Abbonamenti, prenotazioni, bundle, membership, prezzi wholesale, campi personalizzati del processo di acquisto e record marketplace possono risiedere in strutture specifiche delle estensioni.
Il pacchetto di preparazione deve spiegare dove risiede ciascun record commerciale, da quali relazioni Product o transazionali dipende e quale sistema governa il funzionamento futuro. Deve includere backup recuperabili, impostazioni correnti di archiviazione, evidenze sulla compatibilità delle estensioni, record rappresentativi e una condizione di prontezza finale per ogni area e-commerce rilevante. I contenuti CMS di WordPress restano collegati, ma non vengono duplicati nell’ambito WooCommerce.
Stabilire il confine WooCommerce, gli accessi e l’istantanea della sorgente
Iniziare separando i record core WooCommerce dai record CMS WordPress, dai record commerciali gestiti da estensioni e dai sistemi esterni. Confermare URL dello store di origine, installazione WordPress o sito Multisite, versione WooCommerce attiva, tema attivo, estensioni abilitate, codice personalizzato e sistemi attualmente autorevoli per Products, stock, Customers, Orders, prezzi, imposte, spedizioni, pagamenti ed evasione.
| Attività di preparazione | Responsabile | Evidenze da preparare | Condizione di prontezza |
|---|---|---|---|
| Definire il confine commerciale WooCommerce | Proprietario dello store e responsabile tecnico | Elenco delle entità che includa Products, variazioni, Customers, Orders, coupon, recensioni, rimborsi, download, estensioni e sistemi esterni | Ogni record commerciale ha un responsabile core, dell’estensione, esterno, di archivio oppure una decisione di esclusione. |
| Confermare accesso amministrativo e hosting | Amministratore dello store e responsabile hosting | Accesso amministratore WordPress/WooCommerce, accesso database o percorso di export, file di upload/download e accesso amministrativo alle estensioni | Il team può ispezionare i record selezionati e recuperare la sorgente se necessario. |
| Acquisire il WooCommerce System Status Report | Responsabile tecnico | Report datato con informazioni su WooCommerce, WordPress, PHP, database, tema, override dei template, estensioni e ambiente | Contesto software ed estensioni della sorgente registrato prima delle modifiche. |
| Creare un’istantanea completa della sorgente | Responsabile hosting o database | Backup database datato, file wp-content, download Product, media, riferimenti di configurazione e responsabile del ripristino |
Ambito, data, posizione, procedura di ripristino e conservazione del backup sono documentati. |
| Registrare i sistemi esterni autorevoli | Responsabili delle integrazioni | Mappa identificatori ERP, PIM, WMS, CRM, imposte, pagamenti, spedizioni, evasione, marketplace e contabilità | I sistemi che restano autorevoli e le chiavi utilizzate sono espliciti. |
Se lo store di origine continua a cambiare, registrare timestamp dell’istantanea e tipi di record che possono essere creati o modificati successivamente. Questo registro delle modifiche conserva il confine della sorgente e identifica i record per i quali può servire un’istantanea aggiornata.
Inventariare tipi di Product, attributi, variazioni e identità vendibile
Il core WooCommerce supporta Products semplici, raggruppati, esterni/affiliati, variabili, virtuali e scaricabili, mentre le estensioni possono aggiungere abbonamenti, prenotazioni, bundle, Products compositi, membership, depositi, personalizzazioni Product, regole wholesale e proprietà marketplace. Inventariare ogni tipo effettivamente utilizzato e indicare il componente che lo governa.
I Products variabili richiedono particolare attenzione. Attributi globali o specifici del Product possono definire le variazioni e ogni variazione può avere propri SKU, identificatori, stato abilitato, prezzo normale o scontato, costo, stato scaricabile/virtuale, peso, dimensioni, classe di spedizione, classe fiscale, immagine, stock, regola backorder e soglia di stock basso.
| Attività di preparazione | Responsabile | Evidenze da preparare | Condizione di prontezza |
|---|---|---|---|
| Inventariare i tipi di Product | Responsabile catalogo | Conteggi e campioni per tipi semplice, raggruppato, esterno, variabile, virtuale, scaricabile e gestito da estensioni | Ogni tipo attivo ha una rappresentazione sulla destinazione o un’esclusione intenzionale. |
| Mappare identità Product e variazione | Responsabili catalogo e integrazioni | ID Product padre, ID variazione, SKU, GTIN/UPC/EAN/ISBN quando usati, chiavi esterne e report degli identificatori duplicati | Ogni articolo vendibile può essere distinto e riconciliato nei sistemi collegati. |
| Documentare attributi e generazione delle variazioni | Responsabile catalogo | Attributi globali, attributi personalizzati, termini, attributi predefiniti, combinazioni di variazione e pattern “Any attribute” | Vocabolari degli attributi e combinazioni realmente vendibili sono noti prima della mappatura. |
| Acquisire i dati commerciali a livello variazione | Responsabili catalogo e inventario | Prezzo, prezzo scontato, immagine, stock, backorder, peso, dimensioni, imposte, classe di spedizione e download di variazioni rappresentative | I valori commerciali sono assegnati intenzionalmente al Product padre o alla variazione. |
| Registrare la responsabilità dei Products avanzati | Responsabile dell’estensione | Nome/versione estensione, sottotipo Product, tabelle/metadati personalizzati, Products collegati e funzionamento operativo | Dati di abbonamento, prenotazione, bundle, compositi, add-on generici, wholesale o marketplace hanno un responsabile definito. |
Usare famiglie Product rappresentative, non soltanto export aggregati. Includere un Product semplice, un Product variabile con più attributi, un Product virtuale o scaricabile quando applicabile e ogni pattern Product definito da estensioni rilevante.
Preparare inventario, prezzi, tassonomie, media e file Product
La preparazione dei Products dipende anche da classificazione, autorità dello stock, contesto dei prezzi, media e file. Categories, tag, attributi globali, classi di spedizione, classi fiscali, cross-sell, upsell, Products raggruppati e record collegati devono rimanere distinti. L’inventario può essere mantenuto a livello Product, variazione, entrambi oppure da un magazzino esterno o un’estensione.
| Area di preparazione | Evidenze da preparare | Responsabile | Condizione di prontezza |
|---|---|---|---|
| Autorità dell’inventario | Impostazioni stock Product/variazione, backorder, valori di stock basso, ID dei magazzini esterni e responsabile della sincronizzazione | Responsabile inventario | Ogni articolo vendibile ha un unico percorso di stock dichiarato come autorevole. |
| Prezzi e promozioni | Prezzi base/scontati, pianificazioni, prezzi per quantità o gruppo, responsabile dell’estensione e contesto valuta | Responsabile commerciale | I prezzi sono classificati come valori core Product/variazione, regole di estensione o valori di sistemi esterni. |
| Categories e attributi Product | Gerarchia, slug dei termini, assegnazioni Product, uso degli attributi per variazioni o filtri e termini obsoleti | Responsabile catalogo | Le tassonomie restano collegate ai Products previsti senza unire vocabolari non correlati. |
| Media Product | Immagine principale, gallerie, immagini variazione, testo alternativo, ID allegati, asset remoti e report dei file mancanti | Responsabili catalogo e media | Media prioritari di Products e variazioni sono accessibili con relazioni padre note. |
| File scaricabili | URL/percorsi file, regole di accesso, limiti, scadenza, disponibilità nella sorgente e collegamenti Product/variazione | Responsabile Products digitali | Ogni download mantenuto dispone di un file accessibile e di un responsabile Product o variazione definito. |
| Classificazione spedizione e imposte | Classi di spedizione e fiscali, stato virtuale, dimensioni, peso e regole speciali delle estensioni | Responsabile operations | Le evidenze di classificazione sono complete senza trattare la configurazione corrente come dati storici Order. |
L’export CSV dei Products può essere utile come evidenza, ma deve essere accompagnato dagli inventari di tipi Product, estensioni, file e relazioni. Un CSV piatto non può rappresentare completamente ogni struttura Product gestita da estensioni o dipendenza da sistemi esterni.
Preparare Customers, account, indirizzi e ruoli commerciali
I Customers WooCommerce possono essere utenti WordPress registrati oppure acquirenti non registrati memorizzati negli Orders. I Customers registrati possono avere indirizzi di fatturazione e spedizione, metadati account, storico Orders, permessi download e relazioni con estensioni. Ruoli WordPress come Customer o Shop Manager regolano l’accesso, mentre estensioni membership, wholesale, vendor, loyalty o abbonamenti possono aggiungere profili e regole separati.
| Attività di preparazione | Responsabile | Evidenze da preparare | Condizione di prontezza |
|---|---|---|---|
| Separare Customers registrati e acquirenti non registrati | Responsabile Customer service | Conteggi, campioni, qualità email/telefono, ID account e relazioni Order | Gli Orders dei clienti non registrati sono preservati senza inventare account e i Customers registrati restano collegabili. |
| Preparare gli indirizzi Customer | Responsabile Customer service | Campi fatturazione/spedizione, estensioni multi-indirizzo, formati paese/stato e Customers rappresentativi | Gli indirizzi correnti dell’account sono distinti dalle istantanee degli Orders storici. |
| Inventariare ruoli e profili commerciali | Amministratore dello store e responsabili estensioni | Ruoli WordPress, capability personalizzate, profili wholesale/membership/vendor e record collegati | Accesso core e identità commerciale gestita da estensioni hanno responsabili distinti. |
| Registrare le dipendenze di autenticazione | Responsabile identità | Contesto hash password, social login, SSO, MFA e riferimenti a provider di identità esterni | L’identità Customer resta nell’ambito anche quando le credenziali richiedono un percorso di accesso differente. |
| Preparare campi privacy e consenso | Responsabili privacy e marketing | Fonte consenso, timestamp, preferenze, regole di conservazione e ID dei sistemi marketing | Dati sensibili e consenso hanno una decisione approvata di destinazione, archivio, redazione o esclusione. |
Non unire Customers soltanto sulla base dell’email quando nuclei familiari, aziende condivise, marketplace, clienti non registrati o identità storiche creano ambiguità. Preparare evidenze dei possibili duplicati e la regola che governerà ogni consolidamento.
Inventariare Orders, rimborsi, coupon, recensioni e contesto storico
Gli Orders preservano lo storico della transazione attraverso righe Order, riferimenti Product o variazione, attributi selezionati, quantità, prezzi, sconti, imposte, spedizioni, commissioni, riferimenti di pagamento, istantanee di fatturazione e spedizione, stati, note, rimborsi, download e metadati delle estensioni. Preparare campioni che mostrino il contesto completo dell’Order, non soltanto intestazione e totale.
I coupon sono record promozionali separati con tipo e valore dello sconto, restrizioni, limiti d’uso, scadenza e relazioni di utilizzo. Le recensioni Product possono usare commenti WordPress insieme a metadati WooCommerce per rating o verifica dell’acquisto. Rimborsi, resi, abbonamenti, prenotazioni e Orders marketplace possono dipendere da record aggiuntivi delle estensioni.
| Attività di preparazione | Responsabile | Evidenze da preparare | Condizione di prontezza |
|---|---|---|---|
| Inventariare stati e storico Orders | Responsabili operations e Customer service | Conteggi e campioni per pending, processing, completed, canceled, failed, refunded e stati personalizzati | Ogni stato mantenuto ha un significato storico e un responsabile compresi. |
| Preparare campioni Order complessi | Responsabile operations | Orders con variazioni, commissioni, coupon, imposte, evasione parziale o divisa, note, rimborsi, download e campi personalizzati | Il campione rappresenta le relazioni transazionali realmente utilizzate dallo store. |
| Registrare riferimenti pagamento ed evasione | Responsabili finanza ed evasione | ID transazione gateway, ID spedizione/tracking, ID magazzino/export, origine marketplace e chiavi Order esterne | I riferimenti storici restano distinguibili dalla configurazione live corrente. |
| Inventariare rimborsi e record post-vendita | Responsabili finanza e Customer service | Rimborsi parziali/completi, righe interessate, importi, motivi, record di reso e responsabile estensione | Storico rimborsi e resi ha una destinazione o un archivio definito. |
| Preparare i coupon | Responsabile marketing | Regole coupon attive/storiche, limiti d’uso, restrizioni, scadenza, Products/Categories inclusi o esclusi e requisiti sullo storico d’uso | I coupon sono classificati come configurazione attiva, evidenza storica o esclusione. |
| Preparare le recensioni Product | Responsabile contenuti/Customer service | Rating, autore, stato, relazione Product, significato di proprietario verificato, risposte e decisione di moderazione | Le recensioni commerciali sono separate dai normali commenti WordPress. |
Le evidenze degli Orders devono preservare lo stato della transazione storica. Prezzi Product correnti, indirizzi Customer, metodi di spedizione, impostazioni fiscali e configurazione gateway non devono essere usati per ricreare o reinterpretare gli Orders passati.
Registrare la preparazione di HPOS e dell’archiviazione Orders
High-Performance Order Storage utilizza tabelle WooCommerce dedicate invece di affidarsi soltanto a post e metadati WordPress. Gli store esistenti possono usare HPOS, archiviazione legacy dei post WordPress oppure una modalità di compatibilità che sincronizza entrambi i datastore. Estensioni e codice personalizzato che leggono o scrivono direttamente dati Order devono essere identificati perché l’archiviazione autorevole può differire.
| Attività di preparazione | Responsabile | Evidenze da preparare | Condizione di prontezza |
|---|---|---|---|
| Registrare l’archiviazione Order autorevole | Responsabile tecnico | Impostazione WooCommerce per l’archiviazione dei dati Order, stato HPOS, modalità compatibilità ed evidenza datata del System Status | Il team sa se sono autorevoli HPOS o le tabelle dei post WordPress. |
| Registrare lo stato di sincronizzazione | Responsabile tecnico | Conteggio Orders non sincronizzati o evidenza equivalente quando viene usata la modalità compatibilità | Non resta ambiguità sul datastore che contiene il record Order corrente. |
| Inventariare estensioni sensibili a HPOS | Responsabili estensioni | Dichiarazioni di compatibilità, accesso diretto SQL/post-meta noto, report personalizzati, export e codice di modifica Orders | Ogni estensione importante ha una decisione di compatibilità o ristrutturazione. |
| Mappare i metadati Order personalizzati | Responsabili operations ed estensioni | Chiavi, scopo, valori campione, responsabile Order/riga, posizione di archiviazione e uso per ricerca/report | I campi importanti possono essere identificati indipendentemente dall’implementazione di archiviazione della sorgente. |
| Acquisire tabelle Order personalizzate | Responsabili database ed estensioni | Schema tabella, conteggi righe, chiavi padre, stati, date e identificatori esterni | I record Order critici al di fuori del core WooCommerce hanno una decisione di destinazione o archivio. |
HPOS non è soltanto una nota sulla versione. Influisce su dove risiedono Orders e metadati autorevoli e sulla capacità del codice personalizzato di interpretarli. La preparazione deve risolvere archiviazione e responsabilità delle estensioni prima che gli export Order vengano considerati completi.
Preparare campi del processo di acquisto e configurazione operativa
Processo di acquisto, pagamenti, imposte, spedizioni, evasione, email, account e notifiche governano il funzionamento futuro dello store. Devono essere inventariati perché spiegano i dati della sorgente e le dipendenze, ma la configurazione live non deve essere trattata come normali record da migrare.
| Area di preparazione | Evidenze da preparare | Responsabile | Condizione di prontezza |
|---|---|---|---|
| Campi del processo di acquisto | Nome, tipo, posizione, obbligatorietà, responsabile dell’archiviazione, uso storico e responsabile di estensione/codice personalizzato | Responsabile processo di acquisto | Campi storici necessari e campi di configurazione futuri sono separati. |
| Metodi di pagamento | Elenco gateway, riferimenti transazione, responsabilità token/vault, dipendenza abbonamenti ed etichette storiche | Responsabile finanza | Le evidenze di pagamento storico sono nell’ambito senza presumere riutilizzabili credenziali o token live. |
| Spedizione ed evasione | Zone, metodi, classi, integrazioni corrieri/magazzini, campi tracking, estensioni ritiro/consegna e riferimenti Order | Responsabile evasione | Dipendenze di configurazione e dati storici di spedizione sono classificati separatamente. |
| Imposte | Aliquote/classi, servizio fiscale esterno, esenzioni, valori fiscali Orders storici e responsabilità per giurisdizione | Responsabile fiscale | Le evidenze fiscali storiche restano distinte dalla configurazione fiscale corrente. |
| Notifiche e webhook | Template email, trigger di stato, endpoint webhook, processi in coda e listener esterni | Responsabile operations/tecnico | I processi automatici che creano o aggiornano record commerciali sono noti. |
| Impostazioni account e privacy | Acquisto senza account, creazione account, conservazione dati, download e strumenti privacy | Amministratore dello store e responsabile privacy | Funzionamento account e dati Customer mantenuti hanno responsabili documentati. |
L’obiettivo della preparazione è identificare il funzionamento della sorgente, i record che produce e il responsabile di ogni dipendenza che deve continuare.
Inventariare estensioni, codice personalizzato, tabelle e integrazioni esterne
Gli store WooCommerce dipendono spesso da estensioni per abbonamenti, prenotazioni, membership, bundle, Products compositi, personalizzazioni Product, depositi, prezzi wholesale, marketplace, loyalty, punti, resi, fatturazione, imposte, spedizione e pagamenti. Creare un registro delle estensioni invece di basarsi soltanto sulla schermata dei plugin attivi.
| Attività di preparazione | Responsabile | Evidenze da preparare | Condizione di prontezza |
|---|---|---|---|
| Creare un registro delle estensioni | Responsabile tecnico | Nome, versione, scopo, stato attivo, entità possedute, tabelle/metadati, azioni pianificate e servizi esterni | Ogni estensione critica ha un responsabile per dati e funzionamento. |
| Identificare il codice personalizzato | Responsabile sviluppo | Plugin personalizzati, funzioni del tema, snippet, SQL diretto, gestori REST/webhook e template WooCommerce modificati | Il funzionamento personalizzato che crea o interpreta record è documentato. |
| Mappare identificatori esterni | Responsabili integrazioni | Chiavi Product, variazione, Customer, Order, abbonamento, spedizione, fattura e marketplace | Ogni chiave mantenuta è collegata all’entità di destinazione che rappresenta lo stesso oggetto aziendale. |
| Classificare dati generati o temporanei | Responsabile estensione | Cache, log, sessioni, tabelle transitorie, code, indici e record abbandonati | I dati tecnici non autorevoli vengono esclusi intenzionalmente. |
| Registrare dipendenze tra entità | Responsabili business e tecnici | Esempi Product-abbonamento, Customer-membership, Order-prenotazione, vendor-Product e relazioni simili | I record correlati non saranno migrati come tabelle scollegate. |
I file dei plugin non sostituiscono il registro dei dati. Un’estensione può essere inattiva mentre i suoi record restano operativamente importanti, oppure attiva pur non memorizzando dati che appartengono all’ambito di migrazione.
Preparare contenuti WordPress, media, URL e percorsi commerciali
WooCommerce dipende da WordPress per contenuti del sito, media, utenti, menu e percorsi. La checklist WooCommerce deve acquisire le dipendenze rilevanti per il commerce senza duplicare l’intero inventario CMS di WordPress.
| Area di preparazione | Evidenze da preparare | Responsabile | Condizione di prontezza |
|---|---|---|---|
| URL Product e Product Category | Percorsi prioritari, slug, gerarchia Category, breadcrumb, dati canonical e intento della destinazione | Responsabili SEO e catalogo | Ogni percorso commerciale prioritario ha una decisione: mantenere, cambiare, consolidare, ritirare o reindirizzare. |
| Percorsi shop, carrello, processo di acquisto, account ed endpoint | Assegnazioni Page correnti, slug endpoint, ambito lingua/sito e dipendenze plugin | Amministratore dello store e responsabile tecnico | I percorsi applicativi sono distinti dalle normali CMS Pages. |
| Media Product e download | Relazioni allegato/file, asset remoti, gallerie, immagini variazione e accesso ai file | Responsabili catalogo/media | File e riferimenti commerciali prioritari sono disponibili. |
| Contenuti CMS collegati | Guide all’acquisto, Blog Posts, landing Pages, link interni, blocchi/shortcode Product e contenuti di campagna | Responsabile contenuti | I contenuti collegati al commerce hanno una responsabilità WordPress e dipendenze di percorso note. |
| SEO e redirect | Responsabile metadati, fonte sitemap, regole redirect esistenti, input dei dati strutturati e URL ad alto valore | Responsabile SEO | Dati SEO commerciali e continuità dei percorsi hanno responsabili espliciti. |
| Lingue o Multisite | Responsabilità store/sito/lingua, relazioni di traduzione, ambito dominio/percorso e utenti condivisi | Responsabile localizzazione/tecnico | Record Product e contenuti non saranno uniti tra ambiti sito o lingua distinti. |
La preparazione più ampia di Posts, CMS Pages, custom post type, utenti, builder e applicazioni plugin WordPress appartiene all’ambito CMS WordPress. Questa sezione acquisisce soltanto i record WordPress che influenzano materialmente la continuità commerciale WooCommerce.
Selezionare campioni rappresentativi per il test di migrazione
Selezionare campioni che espongano le relazioni commerciali reali dello store. Il registro dei campioni deve riportare ID della sorgente, SKU, URL pubblici, relazioni padre/figlio, responsabili delle estensioni, chiavi esterne e motivo della selezione.
| Campione | Evidenze da preparare | Scopo della preparazione |
|---|---|---|
| Product semplice | Prezzo, stock, classi fiscali/spedizione, media, Categories e chiave esterna | Stabilisce il riferimento di base per il Product core. |
| Product variabile | Attributi globali/personalizzati, variazioni, SKU, prezzi, stock, immagini, backorder e valori predefiniti | Rappresenta struttura padre-variazione e identità vendibile. |
| Product virtuale o scaricabile | File, limite/scadenza accesso, stato spedizione e Orders pertinenti | Rappresenta evasione non fisica e responsabilità dei file. |
| Pattern Product gestito da estensione | Record abbonamento, prenotazione, bundle, compositi, add-on generici, wholesale, marketplace o simili | Espone tabelle delle estensioni e relazioni tra record. |
| Customer registrato e Order di cliente non registrato | Indirizzi, identità account/non registrata, ruoli, collegamenti Order e ID esterni | Rappresenta entrambi i modelli di identità Customer. |
| Order storico complesso | Righe variazione, coupon, commissioni, imposte, spedizione, riferimento pagamento, note, rimborso e campi personalizzati | Rappresenta il contesto commerciale storico. |
| Order sensibile a HPOS | Stato archiviazione, metadati personalizzati, dipendenze delle estensioni e uso nel reporting esterno | Espone ipotesi su archiviazione e compatibilità degli Orders. |
| Campione URL/contenuto commerciale | Product, Category, endpoint, media, SEO, redirect e contenuti CMS collegati | Rappresenta dipendenze dei percorsi WordPress-WooCommerce. |
Il campione deve includere casi limite realmente utilizzati dallo store, non complessità ipotetica. Ogni campione selezionato deve avere evidenze della sorgente, record correlati delle estensioni, file collegati e un revisore indicato.
Completare il controllo finale di preparazione WooCommerce
Consolidare le evidenze in un registro di prontezza prima dell’esecuzione. Ogni dipendenza irrisolta deve avere un responsabile, una decisione richiesta e una conseguenza sull’ambito.
| Area di preparazione | Condizione di prontezza |
|---|---|
| Sorgente e recupero | Accessi, System Status Report, backup completo, inventario software, timestamp dell’istantanea e responsabile del ripristino sono registrati. |
| Products e inventario | Tipi Product, variazioni, attributi, identificatori, autorità dello stock, prezzi, media, file, Categories, imposte e classi di spedizione sono documentati. |
| Customers e identità | Identità registrate/non registrate, indirizzi, ruoli, profili delle estensioni, campi privacy e dipendenze di autenticazione sono classificati. |
| Orders e storico | Stati, righe, totali, imposte, coupon, commissioni, rimborsi, recensioni, riferimenti pagamento/spedizione e ID esterni hanno evidenze della sorgente. |
| HPOS | Archiviazione Order autorevole, stato di sincronizzazione, metadati personalizzati, accesso diretto ai dati e compatibilità delle estensioni sono noti. |
| Operations | Campi del processo di acquisto, pagamenti, spedizioni, imposte, evasione, notifiche e record generati hanno responsabili indicati. |
| Estensioni e integrazioni | Estensioni critiche, codice personalizzato, tabelle personalizzate, sistemi esterni e relazioni tra record sono inventariati. |
| Dipendenze WordPress | Percorsi commerciali, media, SEO, redirect, contenuti CMS collegati, lingua e ambito sito sono documentati. |
| Campioni | Il registro copre ogni pattern rilevante di Product, Customer, Order, HPOS, estensione e percorso. |
L’ambito WooCommerce è pronto quando il team può ricondurre ogni record commerciale selezionato alla relativa archiviazione di origine, al responsabile aziendale, ai record collegati, al sistema di destinazione o mantenuto come autorevole e alle evidenze di supporto.
Conclusione
Preparare una migrazione verso WooCommerce richiede evidenze coordinate su Products, variazioni, attributi, inventario, Customers, Orders, HPOS, coupon, recensioni, rimborsi, campi del processo di acquisto, operations, estensioni, percorsi WordPress e sistemi esterni. Un export Product o un elenco plugin, da soli, non spiegano le relazioni che rendono lo store commercialmente utilizzabile.
Un pacchetto di preparazione solido identifica l’archiviazione autorevole, conserva backup recuperabili, distingue record core e gestiti da estensioni, separa transazioni storiche e configurazione corrente, seleziona campioni rappresentativi e risolve ogni dipendenza rilevante prima dell’inizio dell’esecuzione della migrazione.
Domande frequenti
Cosa bisogna preparare per prima cosa per una migrazione verso WooCommerce?
Definire il confine commerciale WooCommerce e acquisire un’istantanea recuperabile della sorgente. Registrare i sistemi autorevoli per Products, stock, Customers, Orders, prezzi, imposte, spedizioni, pagamenti ed evasione prima di iniziare la mappatura dettagliata.
Perché i Products variabili richiedono una preparazione separata?
Ogni variazione può avere propri SKU, identificatori, prezzo, immagine, stock, impostazione backorder, peso, dimensioni, classe di spedizione, classe fiscale e campi download. Le evidenze limitate al Product padre possono quindi nascondere i record che vengono realmente acquistati ed evasi.
Quali evidenze HPOS devono essere raccolte?
Registrare archiviazione Order autorevole, stato della modalità compatibilità, stato di sincronizzazione, metadati Order personalizzati, accesso diretto al database, tabelle Order personalizzate e compatibilità delle estensioni. Questi elementi mostrano dove risiedono gli Orders correnti e quali componenti dipendono dal modello di archiviazione.
Le estensioni WooCommerce devono essere inventariate anche se inattive?
Sì, quando hanno creato record che restano importanti dal punto di vista commerciale o storico. Lo stato attivo non dimostra da solo se un’estensione possiede Products, profili Customer, Orders, abbonamenti, prenotazioni, record vendor o tabelle personalizzate ancora nell’ambito.
Come si dividono la preparazione WordPress e quella WooCommerce?
La preparazione WordPress governa Posts CMS, CMS Pages, custom post type, tassonomie, utenti, builder, media e confini delle applicazioni plugin in generale. La preparazione WooCommerce governa Products commerciali, variazioni, Customers, Orders, HPOS, coupon, recensioni ed estensioni commerce, documentando soltanto le dipendenze WordPress necessarie a questi record.
Quali record devono essere scelti come campioni rappresentativi del test di migrazione?
Scegliere esempi reali di Products semplici e variabili, Products non fisici, pattern Product gestiti da estensioni, identità registrate e non registrate, Orders complessi, metadati sensibili a HPOS e percorsi commerciali. Ogni campione deve includere i record collegati e il motivo della selezione.