Se Bagisto viene scelto come piattaforma di destinazione, la preparazione deve documentare sia i record e-commerce sia le strutture dell’applicazione Laravel che li possiedono. I Products possono usare tipi Product differenti, attribute family, canali, lingue, valute, fonti di inventario, Customer Groups, Categories, media, prezzi e URL key. Estensioni e pacchetti personalizzati possono introdurre record marketplace, B2B, booking, abbonamenti, pagamento, spedizione, API o headless al di fuori del normale modello di catalogo.
Ogni attività di preparazione deve identificare responsabile, evidenza e condizione di prontezza. Il pacchetto deve distinguere le evidenze della sorgente dall’implementazione sul target: relazioni Product, Orders storici, CMS Pages, URL, identificatori esterni e record posseduti da pacchetti appartengono alla preparazione della migrazione; pagamento, spedizione, imposte, code, ricerca, tema e processo di acquisto operativi appartengono invece all’implementazione della piattaforma di destinazione.
Mettere in sicurezza accessi a Bagisto, Laravel, database, storage e ripristino
Confermare l’accesso all’area amministrativa Bagisto, all’ambiente hosting o cloud, ai file dell’applicazione Laravel, alla configurazione dell’ambiente, al database, allo storage pubblico e privato, ai media Product, ai file scaricabili, alla configurazione di code e scheduler, ai log, alla gestione dei pacchetti e ai servizi collegati. Non copiare segreti nei documenti editoriali; registrare soltanto chi li controlla e dove sono gestiti.
| Attività di preparazione | Responsabile | Evidenza | Condizione di prontezza |
|---|---|---|---|
| Confermare l’accesso amministrativo | Amministratore Bagisto | Account funzionante e riepilogo dei permessi | Products, attributi, Customers, Orders, canali, inventario e record CMS possono essere ispezionati. |
| Confermare accesso ad applicazione e database | Responsabile tecnico | Riepilogo di hosting, progetto Laravel, database, storage, code, scheduler e accesso alla distribuzione | È possibile identificare la sorgente autorevole completa. |
| Creare backup recuperabili | Responsabile infrastruttura | Dump database, archivio applicazione, archivio storage/media/download e responsabile del ripristino | Lo store di origine può essere recuperato indipendentemente dall’ambiente live. |
| Registrare versioni e pacchetti | Responsabile sviluppo | Inventario di Bagisto, Laravel/PHP, database, tema, pacchetti, moduli e codice personalizzato | Record ed estensioni dipendenti dalla versione sono documentati. |
| Mappare i sistemi esterni | Responsabili delle integrazioni | Endpoint ERP/PIM/WMS/CRM/marketplace/ricerca/pagamento/evasione e mappe degli identificatori | Sistemi che continueranno a operare e autorità di sincronizzazione sono noti. |
Mantenere gli identificatori interni ed esterni per Products, Products figli, attributi, attribute family, Categories, canali, fonti di inventario, Customers, Orders, fatture, spedizioni, rimborsi, record CMS, pacchetti e integrazioni.
Preparare tipi Product e relazioni vendibili
Bagisto supporta diversi tipi Product con record e relazioni commerciali differenti. I simple Products rappresentano normali articoli vendibili. I configurable Products usano attributi selezionabili e Products figli associati. Grouped e bundle Products fanno riferimento ad altri Products. Downloadable e virtual Products hanno un significato diverso per l’evasione, mentre i booking Products possono contenere relazioni di appuntamento, evento, noleggio, tavolo, slot, capacità e data.
| Tipo Product o modello | Evidenza da preparare | Condizione di prontezza |
|---|---|---|
| Simple Product | Product ID, SKU, prezzo, Category fiscale, stock, dimensioni, Category, canale, lingua, media e Order | Un record identifica chiaramente l’articolo venduto ed evaso. |
| Configurable Product | Padre, Products figli associati, attributi configurabili, valori opzione, SKU figli, prezzi, stock e immagini | Ogni figlio vendibile è tracciabile fino al padre e agli attributi selezionati. |
| Grouped Product | Padre, simple Products collegati, quantità predefinite, ordine e Order rappresentativo | Il gruppo è distinto dall’identità dei component Products. |
| Bundle Product | Opzioni bundle, tipi di input, Products collegati, quantità predefinite, obbligatorietà, prezzi e righe Order | Configurazione bundle e relazioni tra componenti sono complete. |
| Downloadable Product | File/link, titolo, prezzo, campione, limiti, collegamento Product e Order completato | L’evidenza dell’accesso digitale è recuperabile. |
| Virtual Product | Identità del servizio, prezzo, disponibilità e contesto Order | Non vengono inventati spedizione o inventario fisico. |
| Booking Product | Tipo booking, date, slot, capacità, sede, valori ticket/noleggio, stato cancellazione e record Order/booking | Relazioni basate su tempo e capacità sono documentate. |
Non presumere che un Product di origine con opzioni debba diventare un Configurable Product. Registrare se ogni scelta crea un figlio vendibile indipendente, un attributo descrittivo, una selezione bundle, una scelta booking o un valore Customer occasionale.
Preparare attributi, attribute family, Categories e media
Gli attributi Bagisto possono usare tipi come text, textarea, price, Boolean, select, multi-select e date-time. Le Attribute Families raggruppano gli attributi per la creazione e la modifica dei Products. Le Categories organizzano i Products, mentre media e URL key restano collegati a specifici Products o Categories.
| Struttura | Evidenza | Responsabile | Condizione di prontezza |
|---|---|---|---|
| Attributo | Codice, tipo, etichette, opzioni, obbligatorietà/univocità, uso nei filtri/confronti e comportamento per lingua/canale | Responsabile catalogo | La funzione aziendale di ogni attributo è nota. |
| Attribute Family | Codice/nome family, attributi raggruppati, assegnazioni Product e dipendenze da pacchetti personalizzati | Responsabile catalogo | I Products possono essere assegnati senza perdere campi necessari. |
| Attributo configurabile | Attributo, valori opzione, Product padre, Products figli ed etichette delle righe Order | Responsabile catalogo | L’identità della variante è distinta dai dati Product descrittivi. |
| Category | Category ID, gerarchia, assegnazioni Product, visibilità per canale/lingua, media, metadati e URL key | Responsabili contenuti/catalogo | Tassonomia e responsabilità della route pubblica sono complete. |
| Media | Responsabile Product/Category, ruolo primario/gallery, percorso file o sorgente remota, ordinamento e contesto alt | Responsabile contenuti | Ogni asset prioritario è disponibile e collegato al record corretto. |
| Campo personalizzato di un pacchetto | Schema, entità responsabile, tipo, relazioni e pacchetto che lo utilizza | Responsabile sviluppo | I dati del pacchetto non vengono scambiati per attributi Bagisto core. |
Creare un registro dei campi che distingua identità vendibile, descrizione Product, filtraggio, amministrazione, chiavi di integrazione e stato posseduto da pacchetti. Etichette simili non devono essere unite se la funzione aziendale non è equivalente.
Preparare canali, lingue, valute e fonti di inventario
I canali Bagisto possono definire hostname, root Category, lingue, valute, tema, fonti di inventario e altro contesto della vetrina. Le fonti di inventario rappresentano sedi stock assegnabili ai canali e le quantità Product possono esistere per fonte.
| Area di contesto | Evidenza da preparare | Condizione di prontezza |
|---|---|---|
| Canale | ID/codice canale, hostname, root Category, lingue, valute, tema, fonti di inventario e responsabile | Ogni contesto rivolto al cliente è elencato una sola volta. |
| Lingua | Codice, campi Product/Category/contenuti tradotti, fallback e assegnazioni canale | I record localizzati restano collegati al canale previsto. |
| Valuta | Codice valuta, uso base/predefinito, assegnazione al canale e responsabilità dei prezzi | I valori commerciali non vengono separati dal contesto valutario. |
| Fonte di inventario | ID/codice, nome, indirizzo, stato, priorità, assegnazioni canale e ID magazzino esterno | Ogni sede stock ha un’identità stabile. |
| Quantità Product | ID Product/figlio, source ID, quantità, significato riservato/disponibile se applicabile e sistema autorevole | Unità vendibile e sede di ogni quantità sono note. |
| Stato Product specifico per canale | Product/figlio, canale, stato, visibilità, differenze di prezzo/contenuto e Category | L’ambito Product è esplicito anziché dedotto globalmente. |
Se ERP, WMS, marketplace o feed fornitore controllano lo stock, identificare il sistema autorevole e la chiave che lo collega al Product Bagisto e alla fonte di inventario.
Preparare Customer Groups, Customers, indirizzi e autenticazione
La preparazione Customers deve includere identità, Customer Group, indirizzi, stato account, consenso, Reviews, informazioni Company o fiscali quando presenti, ID esterni e dipendenze di autenticazione. I pacchetti possono aggiungere marketplace seller, account Company, preventivi, abbonamenti, loyalty o altri profili.
| Area account | Evidenza | Responsabile | Condizione di prontezza |
|---|---|---|---|
| Identità Customer | Customer ID, email, nome, stato, gruppo, contesto lingua/canale e ID esterno | Responsabile dati Customer | Identità duplicate e Guest vengono risolte deliberatamente. |
| Customer Group | ID/codice gruppo, membri, implicazioni di prezzo/accesso e dipendenze da pacchetti | Responsabile commerce | Il significato del gruppo è documentato oltre l’etichetta. |
| Indirizzo | Address ID, collegamento Customer, uso fatturazione/spedizione, riferimenti paese/stato, Company e campi fiscali | Responsabile assistenza Customer | Gli indirizzi salvati sono distinti dagli snapshot storici degli Orders. |
| Guest Customer | Email a livello Order, indirizzi e contesto di assistenza | Responsabile dati Order | Lo storico Guest non richiede la creazione artificiale di un account. |
| Autenticazione | Schema password, social login/SSO, MFA, percorso di reset e responsabile comunicazioni | Responsabile sicurezza | L’accesso account è pianificato senza presumere la portabilità delle credenziali. |
| Profilo di estensione | Customer/user ID, entità pacchetto, ruolo, stato e record commerciali collegati | Responsabile pacchetto | I dati account specializzati hanno una destinazione o un responsabile mantenuto. |
Includere Customers di gruppi differenti, acquirenti Guest, più indirizzi, account inattivi e tipi account definiti dalle estensioni quando influenzano Orders o accesso.
Preparare Orders, fatture, spedizioni, rimborsi e transazioni
Preparare gli Orders come evidenza commerciale storica. Includere header, Customers o Guest, indirizzi, righe Product e figli, opzioni selezionate, quantità, prezzi, sconti, imposte, spedizione, etichette di pagamento, storico stati, fatture, spedizioni, rimborsi, transazioni, note e riferimenti esterni. Pacchetti booking, marketplace, B2B o personalizzati possono aggiungere record collegati.
| Evidenza Order | Responsabile | Condizione di prontezza |
|---|---|---|
| Header e righe Order | Responsabile dati Order | ID Product/figlio, etichette snapshot, valori selezionati, quantità, prezzi e contesto Customer sono completi. |
| Totali e rettifiche | Responsabile finanza | Subtotale, sconto, imposte, spedizione, commissioni, rimborsi e totale finale si riconciliano. |
| Fattura e spedizione | Responsabili finanza/evasione | Numeri documento, righe spedite, quantità, vettore/tracking, date e file sono recuperabili. |
| Rimborso | Responsabili finanza/assistenza | Importi, righe interessate, motivazioni, stati e transaction ID collegati sono documentati. |
| Transazione | Responsabile finanza | Etichetta metodo di pagamento, riferimento transazione, importo, stato e chiave provider esterno sono noti. |
| Record Order posseduto da pacchetto | Responsabile pacchetto | Record booking, seller, quote, subscription o flusso personalizzato restano collegati all’Order. |
| ID Order esterno | Responsabile integrazione | La discendenza ERP, marketplace, accounting o evasione resta tracciabile. |
I totali storici devono restare snapshot. Non devono essere ricalcolati usando prezzi correnti, Categories fiscali, Customer Groups, spedizione o configurazione di pagamento attuale.
Preparare CMS Pages, URL, ricerca e contenuti commerciali
I contenuti Bagisto possono includere CMS Pages, descrizioni Product e Category, metadati, URL key, navigazione, blocchi del tema, banner, termini di ricerca, cart rules, catalog rules e contenuti email/notifiche. Le estensioni possono introdurre page builder o sorgenti di contenuto headless.
| Area contenuto | Evidenza da preparare | Condizione di prontezza |
|---|---|---|
| CMS Page | Page ID, titolo, URL key, contesto canale/lingua, stato, contenuto, metadati e posizione di navigazione | Il contenuto CMS resta distinto dalla presentazione del tema. |
| Contenuto Product/Category | Entity ID, lingua/canale, descrizione, metadati, immagini e route prioritaria | Il contenuto del catalogo resta collegato all’entità corretta. |
| Navigazione e blocco tema | Responsabile, gerarchia/posizione, oggetto collegato, media e dipendenza da pacchetto/tema | I percorsi Customer non vengono dedotti soltanto da CMS o Categories. |
| URL prioritario | Responsabile Product/Category/Page, lingua/canale, percorso sorgente, backlink o valore traffico e intento della destinazione | Ogni percorso importante ha una decisione: mantenere, cambiare, unire, ritirare o reindirizzare. |
| Ricerca e merchandising | Termini, sinonimi, regole, Categories, stato featured/new e sistema responsabile | Input di ricerca e merchandising sono separati dai dati master Product. |
| Promozione storica | Regola/codice, date, condizioni, Products/Customers interessati e riferimenti Order | L’evidenza storica dello sconto è separata dalla futura configurazione del target. |
Raccogliere i percorsi prioritari da analytics, dati di ricerca, backlink, campagne, comunicazioni Customer e navigazione interna, non soltanto dalla sitemap.
Inventariare pacchetti, tabelle personalizzate, API e dipendenze headless
L’architettura Laravel consente a pacchetti e codice personalizzato di registrare entità, tabelle, eventi, job, API, strutture marketplace/B2B, booking, pagamento, spedizione, ricerca, feed e integrazioni. Creare un registro delle responsabilità prima di decidere quali record rientrano nell’ambito.
| Dipendenza | Evidenza da preparare | Condizione di prontezza |
|---|---|---|
| Pacchetto/modulo | Nome, versione, provider, stato, scopo, responsabile configurazione, migration/tabelle, modelli e record interessati | I dati posseduti dal pacchetto hanno destinazione o responsabile mantenuto. |
| Tabella o modello personalizzato | Schema, chiavi, relazioni, eventi, job e codice che lo utilizza | I record personalizzati possono essere interpretati anziché copiati alla cieca. |
| API o client headless | Endpoint, risorse, responsabile autenticazione, ID, presupposti payload, route e responsabile distribuzione | Dipendenze frontend e integrazioni sono documentate senza esporre segreti. |
| Pacchetto marketplace/B2B | Seller/Company, ruoli, cataloghi, quote, commissioni, payout, approvazioni e Orders collegati | I record commerciali specializzati restano distinti da Customers e Orders core. |
| Servizio ricerca/indice | Campi indicizzati, ID esterni, record di origine, responsabile rebuild e sinonimi/regole | I dati generati dell’indice non vengono scambiati per contenuto autorevole. |
| Coda/processo pianificato | Job, trigger, payload, destinazione, responsabile retry/errori ed entità interessate | L’automazione operativa è separata dai dati statici migrati. |
| Dati generati | Cache, log, sessioni, code, indici, import temporanei e tabelle abbandonate | I dati tecnici non autorevoli vengono esclusi deliberatamente. |
I pacchetti inattivi devono restare nel registro quando i loro dati compaiono ancora in Products, Customers, Orders, booking, record seller o report.
Selezionare campioni rappresentativi per i test di migrazione
Scegliere record che espongano i reali tipi Product, canali, inventario, contesti Customer, Orders, contenuti e pacchetti dello store. Registrare source ID, SKU, URL key, canale/lingua, fonte di inventario, chiavi esterne, record correlati e motivo della selezione.
| Campione | Evidenza da preparare | Finalità della preparazione |
|---|---|---|
| Simple Product | Prezzo, imposte, stock, Category, canale, lingua, media e Order | Stabilisce il riferimento Product ordinario. |
| Famiglia Configurable Product | Padre, figli, attributi configurabili, opzioni, SKU, prezzi, stock per fonte, immagini e Orders | Rappresenta l’identità delle varianti. |
| Bundle/grouped/booking Product | Relazioni di componenti o slot, quantità, prezzi, capacità, dati pacchetto e righe Order | Rappresenta struttura commerciale non semplice. |
| Caso inventario multicanale | Product/figlio, canali, lingue, valute, fonti, quantità e ID magazzino esterni | Rappresenta contesto e responsabilità dello stock. |
| Customer Group o account di estensione | Customer, gruppo/profilo, indirizzi, implicazioni accesso/prezzo e Order pertinente | Rappresenta identità segmentata o definita da pacchetto. |
| Order complesso | Tipo Product, opzioni, sconto, imposte, fattura, spedizione, rimborso, transazione e ID esterni | Rappresenta l’evidenza commerciale storica. |
| Caso CMS/URL | CMS Page o contenuto catalogo, lingua/canale, URL key, metadati, link e intento destinazione | Rappresenta responsabilità di contenuto e route. |
| Record posseduto da pacchetto | Entità core, modello/tabella pacchetto, campi personalizzati, job/eventi e chiave integrazione | Espone l’ambito non core prima dell’esecuzione. |
Il pacchetto di campioni è pronto quando ogni record selezionato ha una scheda di aspettative della sorgente, contesto canale/inventario, file correlati e un revisore nominato.
Completare il controllo finale di preparazione Bagisto
| Area | Condizione di prontezza |
|---|---|
| Accesso e ripristino | Admin, applicazione Laravel, database, storage, media/download, backup e responsabilità del ripristino sono confermati. |
| Catalogo | Tipi Product, figli/componenti, attributi, family, Categories, media, prezzi, stock e identificatori sono tracciabili. |
| Canali e inventario | Canali, lingue, valute, fonti, assegnazioni Product, quantità e autorità esterne sono documentati. |
| Customers e Orders | Account, gruppi, indirizzi, Orders, righe, totali, fatture, spedizioni, rimborsi, transazioni e ID esterni hanno evidenze. |
| Contenuti e URL | CMS Pages, contenuti catalogo, navigazione, percorsi prioritari, metadati, link e decisioni di redirect sono documentati. |
| Dipendenze | Pacchetti, tabelle/modelli personalizzati, API, client headless, job, ricerca e sistemi esterni hanno responsabili nominati. |
| Campioni | I record rappresentativi coprono ogni tipo Product, canale, Customer, Order, contenuto e modello di pacchetto rilevante. |
L’ambito Bagisto è pronto quando ogni record materiale può essere ricondotto al responsabile nella sorgente, alle entità correlate, all’evidenza e alla destinazione prevista o al sistema che continuerà a possederlo.
Conclusione
La preparazione di Bagisto richiede evidenze coordinate su accessi Laravel e database, tipi Product, attributi e family, Categories, canali, fonti di inventario, Customers, Orders, record CMS, URL, pacchetti, API e sistemi esterni. La checklist deve rendere esplicite queste relazioni prima dell’esecuzione, anziché trattare Bagisto come un semplice database Product-Customer-Order.
Un pacchetto di preparazione completo mantiene evidenze di origine recuperabili, separa record core dalle strutture possedute dai pacchetti, distingue transazioni storiche da configurazione operativa e assegna un responsabile a ogni integrazione o dipendenza personalizzata.
Domande frequenti
Cosa deve essere preparato per primo in una migrazione Bagisto?
Confermare accessi ad Admin Bagisto, applicazione Laravel, database, storage, media, download, code, scheduler e pacchetti; creare backup recuperabili; registrare versioni di Bagisto, Laravel, PHP, database, tema e pacchetti.
Perché i tipi Product Bagisto devono essere inventariati separatamente?
Configurable, grouped, bundle, downloadable, virtual e booking Products utilizzano relazioni differenti tra figli, componenti, file, slot, capacità e Orders. Trattarli come simple Products eliminerebbe le strutture che li rendono vendibili.
Come preparare attributi e attribute family?
Documentare codici, tipi, etichette, opzioni, uso nei filtri o confronti, obbligatorietà/univocità, assegnazione alla family, assegnazione Product e se il campo appartiene a Bagisto core o a un pacchetto personalizzato.
Perché canali e fonti di inventario fanno parte della preparazione?
I canali possono definire hostname, lingua, valuta, root Category, tema e ambito delle fonti di inventario. Le quantità Product possono appartenere a fonti specifiche, quindi un totale stock globale non mantiene il significato della sede o del canale.
Quali Orders Bagisto devono essere scelti come campioni rappresentativi?
Includere simple e configurable Products, bundle o booking se usati, sconti, più imposte, fatture, spedizioni, rimborsi, transazioni, Customers Guest e di gruppi differenti, ID esterni e relazioni Order possedute da pacchetti.
Cosa deve comparire nel registro di pacchetti e dati personalizzati Bagisto?
Ogni pacchetto, tabella/modello personalizzato, API, client headless, job, evento, servizio di ricerca, componente marketplace/B2B e connettore esterno che crea o consuma dati aziendali. Ogni elemento deve avere responsabile, record interessati, evidenza e decisione su destinazione o sistema mantenuto.